[IAEP] ANNOUNCE: F11 for the XO-1 build 140py released
dsd at laptop.org
Thu Apr 15 17:55:38 EDT 2010
On 15 April 2010 15:48, Bernie Innocenti <bernie at codewiz.org> wrote:
> I noticed that Stephen Parrish had removed olpc-update from F11-XO1,
> which made /versions also superfluous. Besides the nice saving in space,
> disabling the versioned fs considerably sped up olpc-os-builder.
I'd be surprised if there is any significant saving of space. As for
build time, that would also surprise me but I'm not so familiar with
the technicalities of mkfs.jffs2 - perhaps it does take a lot longer
for lots of links.
> Hmmm... perhaps I should reconsider this decision. We'd first have to do
> some testing to ensure your original work still works well with F11-XO1.
> Last time I looked, the hostname of the update server was hardcoded
> inside olpc-update. Did you create a custom package to point it at the
olpc-update-query is the component in question. You need to point it
at the mothership like was done in the 801 image, not the school
server. If there is an update available, the mothership will ask
olpc-update-query to run olpc-update using rsync from the local school
The new olpc-update-query version will look on the school server
first, then a server configured in /etc. (make sure you're using
olpc-update-2.22 then you can use the oats_cfg module of
olpc-os-builder for this configuration).
There is also the option to make it bypass the school server and use
the other one directly -- thats what I'd suggest for Paraguay.
Regardless of whether you use the updates bit or not, you'll want to
reinstate that server configuration so that the laptops can receive
lease updates before expiration (Raul told me that they have switched
this feature on a while back when school holidays were approaching).
> For a future release cycle, we may want to re-evaluate yum-updatesd as
> an alternative to olpc-updates which provides different trade-offs in
> terms of performance, robustness and distro integration. At the time
> olpc-update was written, yum was still awfully buggy and unreliable.
I agree with the idea of using a more standard system, but I'd say
that yum is not yet a suitable replacement based on a discussion that
I started based on this exact question in the beginning of the XO-1.5
development cycle. It's in the archives.
More information about the Devel