State of Fedora spin

[Jeremy Katz]

On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote:
>  o a 520 megabyte spin was pretty easy to make; but that is using
> Squashfs, which is more efficient than JFFS2, so it is still not small
> enough to fit allowing olpc-update to be used for an in-place upgrade.
> Said spin booted fine on conventional systems, though since it lacked a
> kernel for OLPC, could not be booted on the XO.

Note that the config as it currently stands is missing some pretty
important things.  Like, say, X drivers :)  It also ends up with a lot
of duplication from the "base" config and thus will in the long run be a
little more painful to maintain.

Unfortunately, with the older kernel, there's not a great way around
this at the moment.  I'll try to add a fixup so that overriding repos
works properly in a little bit.  

>  o the olpc kernel lacks the squashfs patch; we created a RPM adding it,
> which would be necessary to use the Fedora live-cd-tools.

There are a couple of other quirks of the olpc kernel that break using
it as-is for a live image:
1) squashfs as mentioned
2) dm_snapshot isn't being built
3) The %post of the kernel package doesn't call new-kernel-pkg, instead
doing things by hand.  But not including mkinitrd.  This led to no
initrd and the error that was later seen.  Given that the XO is always
using an initrd, is there a reason new-kernel-pkg isn't just being
called?

But with those taken care of, I can get an image built based on rawhide
+ that kernel that boots.  I then have to drop an xorg.conf in as the
driver is busted and doesn't manage to auto-config, but that too should
be fairly straight-forward to get fixed (bz#460581).

> Problems right now:
>  o live-cd-tools doesn't seem to find the initrd, when Sebastian tries
> to build a spin with an OLPC kernel.  We don't understand this. Anyone
> familiar with the live-cd-tools who can help is greatly appreciated...

This is because the initrd isn't being built.  See 3 above.

>  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.  Also, just nuking
docs willy-nilly isn't the wisest of ideas.  For one thing, in some
cases, the license file is required to be included.  Also, if they're
just nuked with an rm, then a later update by the user will bring them
back.  So I have been very cautious about doing anything along those
lines for "general purpose" use -- and since it seems one of the goals
here is to have the XO generally running Fedora, it may be something to
avoid.

>  o what the manifest of the system should be is something well worth
> serious discussion: there are questions such as claws versus
> thunderbird, versus other mail possibilities.

That depends to some extent what the goal is -- do we want to be able to
be running "stock" Fedora or a special spin?  The former seems like it's
more valuable in a lot of ways because a user who is used to Fedora has
the _exact_ same applications, etc available.

>  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.

> We hope that by the time this all is ready to go, conventional packages
> for Sugar for Fedora will make it possible for a simple sugar
> installation as well; but only time will tell.

Yeah, a couple of separate things need following up on there.  Marco's
proposed bundlebuilder changes should take care of one set of them.
Then it should at least be easier to get packages being built and
through the review process, at which point, I'll return to that

Jeremy