State of Fedora spin

[Jim Gettys]

On Thu, 2008-08-28 at 17:35 -0400, Jeremy Katz wrote:

> There's definitely been a lot of drift between the two kernel spec
> files.  Which is worth resolving in any case.  The ideal, to me at
> least, would be if we can just use one of the same kernels that's
> shipped in Fedora.  That's the only way that we're going to be able to
> have any spin carry the Fedora trademark at present.  And really, that
> doesn't look like it should be that far off -- there's not that much in
> the diff of 2.6.26 to the olpc kernel tree from a glance.  And some may
> even be resolved in 2.6.27.

That's the ideal, but not all OLPC stuff is upstream in kernel.org as
yet (e.g. device tree stuff, where there are several alternatives
differing in not-very-important details currently gumming the works) .
And it is likely/probable we'll continue to do work in power management.
in advance of Linus...  Whether Fedora would want to carry such patches
is far from clear, and .seems unlikely

> 
> > > >  o Note that there is tons of other fat to nuke; some unneeded
> > > > dependencies (e.g. libgweather), icons at a bunch of
> > > > sizes, /usr/share/doc is accumulates to several hundred megabytes
> > > > (uncompressed).  Note that this is several hundred megabytes larger than
> > > > the OLPC Sugar only build.  We'll need lots of help here; some of it is
> > > > very easy; for example, nuking post install (most of) what is
> > > > in /usr/share/doc.
> > > 
> > > libgweather is part of what's needed for the actual desktop -- it's
> > > depended on by the time/date stuff carried by gnome.  it
> > 
> > Actually, it is just the stupid clock applet to show the names of the
> > cities where you may also show the current time and weather.
> 
> Which is also used for the timezone setting bits.  While the current
> stored form of the data has its downsides, it's actually quite good to
> be able to possibly have a better way in the future of timezone
> selection than just dealing with the poor stuff that's in tzdata.  So
> rather than throwing out the baby and the bathwater, it's more likely
> worthwhile to help upstream come up with a better way of representing
> the data with less duplication.

I already complained upstream, and the issue may have already been fixed
upstream in Gnome.

http://bugzilla.gnome.org/show_bug.cgi?id=547961

> 
> > > >  o Once a spin exists, some modifications would be needed to the
> > > > installation program to install the spin onto jffs2.
> > > 
> > > >From what I remember, jffs2 is substantially different in that you don't
> > > do formatting, etc and rather just do imaging.  The live install process
> > > is already somewhat imaging-like in that we just dd over the filesystem
> > > to the final partition and do some resizing tricks, but that's not going
> > > to work as-is.  I'd have to go back and refresh my memory of jffs2
> > > imaging to give any better indication.  It does, at least, look like
> > > jffs2 should have all of the right hooks in the kernel for security
> > > xattrs, though.
> > 
> > No, for olpc-update, we'll just have to put the bits in the right place
> > on the server, and jffs2 /olpc-update will take care of the rest.
> > Similarly, for an "install to disk". Jffs2 can/should be treated as a
> > normal file system.  To coexist with our sugar based load to be able to
> > install via olpc-update, we just put it in a root of its own.  Our
> > firmware is set up to allow booting two different systems in their own
> > roots (which may even be sharing hardlinked files); this is to enable
> > our robust upgrade stuff. On our system, you can have an olpc-upgrade
> > fail in the middle, yet still end up with your old system intact.  So
> > other than putting a prefix on the paths, (and optionally hardlinking
> > identical files) install from a live CD/USB image should be easy.
> 
> Easy-ish, but slow.  Doing a file-based copy took on the order of a heck
> of a lot longer from what I remember.  I'll have to look closer at that,
> but it's a little lower on my todo list
> 

We do an rsync based update for olpc-update; this has lots of advantages
for us.
                           - Jim

-- 
Jim Gettys <jg at laptop.org>
One Laptop Per Child