From bkearney at redhat.com Wed Jun 3 18:58:41 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 03 Jun 2009 14:58:41 -0400 Subject: Please update your Sugar packages for SoaS! In-Reply-To: <4A216CC4.6000300@when.com> References: <4A216CC4.6000300@when.com> Message-ID: <4A26C7E1.5040305@redhat.com> Sebastian Dziallas wrote: > Hi all, > > as we're quite quickly approaching the next release of SoaS, which is > scheduled for June 24, it would be great if you could update the Sugar > packages you maintain in Fedora to their latest versions. > > The whole roadmap is listed on our wiki, where you can also find the > current version number of your package(s): > > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Packaging > > In case you're unable to do the update, you can drop Steven (listed as > CC) an e-mail, who has kindly agreed to help, if needed. > > Thanks a lot, > --Sebastian Sugar and Moon are updated for F-11. Just awaiting 6 days from now :) -- bk From bkearney at redhat.com Wed Jun 3 18:59:03 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 03 Jun 2009 14:59:03 -0400 Subject: Please update your Sugar packages for SoaS! In-Reply-To: <4A26C7E1.5040305@redhat.com> References: <4A216CC4.6000300@when.com> <4A26C7E1.5040305@redhat.com> Message-ID: <4A26C7F7.8020705@redhat.com> Bryan Kearney wrote: > Sebastian Dziallas wrote: >> Hi all, >> >> as we're quite quickly approaching the next release of SoaS, which is >> scheduled for June 24, it would be great if you could update the Sugar >> packages you maintain in Fedora to their latest versions. >> >> The whole roadmap is listed on our wiki, where you can also find the >> current version number of your package(s): >> >> http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Roadmap#Packaging >> >> In case you're unable to do the update, you can drop Steven (listed as >> CC) an e-mail, who has kindly agreed to help, if needed. >> >> Thanks a lot, >> --Sebastian > Sugar and Moon are updated for F-11. Just awaiting 6 days from now :) > Sorry.. Turtle-Art and Moon :) -- bk From bkearney at redhat.com Wed Jun 3 19:03:12 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 03 Jun 2009 15:03:12 -0400 Subject: Package Honey Activities? Message-ID: <4A26C8F0.3070005@redhat.com> Hopefully this will not get in anyone spam folder.... Are we still trying to package honey activities for Fedora? I have an open-review for paint.. and if the plan is to get them in I am happy to finish it. However, if the plan is to upgrade via .xo I am happy to close it out. -- bk From pgf at laptop.org Wed Jun 3 19:17:53 2009 From: pgf at laptop.org (Paul Fox) Date: Wed, 03 Jun 2009 15:17:53 -0400 Subject: package review needed for olpc-kbdshim In-Reply-To: <28058.1241276663@foxharp.boston.ma.us> References: <28058.1241276663@foxharp.boston.ma.us> Message-ID: <28131.1244056673@foxharp.boston.ma.us> hi -- after a burst of activity, the review for olpc-kbdshim got stalled about a month ago, and i'd really like to get it going again. if anyone has some cycles to spare for this, i'd really appreciate it. i believe i've addressed all of the issues raised to date during the review, so hopefully it's pretty close. paul pgf at laptop.org wrote: > i'd like to get olpc-kbdshim upstreamed so that more people can try it, etc. > > https://bugzilla.redhat.com/show_bug.cgi?id=495902 > > if anyone can do me the honor of taking a look, and gently > telling me all that i've done wrong, or not at all, i'd > appreciate it. > > (i'll be submitting olpc-powerd for review as well, but since > i've surely made the same mistakes in both, and olpc-kbdshim is > independent of olpc-powerd, i'm doing it first...) > > thanks! > > paul > =--------------------- > paul fox, pgf at laptop.org > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list =--------------------- paul fox, pgf at laptop.org From gary at garycmartin.com Wed Jun 3 21:52:12 2009 From: gary at garycmartin.com (Gary C Martin) Date: Wed, 3 Jun 2009 22:52:12 +0100 Subject: Package Honey Activities? In-Reply-To: <4A26C8F0.3070005@redhat.com> References: <4A26C8F0.3070005@redhat.com> Message-ID: Hi Bryan, On 3 Jun 2009, at 20:03, Bryan Kearney wrote: > Hopefully this will not get in anyone spam folder.... Are we still > trying to package honey activities for Fedora? I have an open-review > for paint.. and if the plan is to get them in I am happy to finish > it. However, if the plan is to upgrade via .xo I am happy to close > it out. Thanks Bryan, this is such a good question! As an Activity Team co-co- ordinator ;-) I'd so, so like to be able to have a clear message here for both Activity authors and packagers of Sugar components. Packagers have taken Sugar to so many distros in such a short time, and I know little of the packagers real needs and distro politic, but it does seem that both packagers and Activity authors are currently each doing extra steps. A). If all Activities were distributed as .xo bundles through the Sugar platform (such as access to activities.sugarlabs.org), distro packagers would only have to worry about keeping the core Sugar and it's dependancies up-to date, not all the faster changing stuff. B). If all Activities were distributed through distros, then Activity authors would only need to worry about getting their source bundles to distro packagers in the most friendly way. Sugar core would need some distro agnostic or configurable user interface for yup/rpm/aptitude installing/removing; but would not need to maintain code behind something like activities.sugarlabs.org. We have a foot on each side of this quagmire just now. Regards, --Gary > -- bk > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list From bochecha at fedoraproject.org Wed Jun 3 22:18:31 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 4 Jun 2009 00:18:31 +0200 Subject: Package Honey Activities? In-Reply-To: References: <4A26C8F0.3070005@redhat.com> Message-ID: <2d319b780906031518k5f08f55ah5b2f5eb8e59123ff@mail.gmail.com> > A). If all Activities were distributed as .xo bundles through the Sugar > platform (such as access to activities.sugarlabs.org), distro packagers > would only have to worry about keeping the core Sugar and it's dependancies > up-to date, not all the faster changing stuff. > > B). If all Activities were distributed through distros, then Activity > authors would only need to worry about getting their source bundles to > distro packagers in the most friendly way. Sugar core would need some distro > agnostic or configurable user interface for yup/rpm/aptitude > installing/removing; but would not need to maintain code behind something > like activities.sugarlabs.org. Well, one could see the problem as follows : 1. activities installed via .xo bundles take precedence over activities installed via the OS package manager (yum here), just like config files in your home directory take precedence over the system ones 2. use PackageKit for the distro agnostic part. On Fedora for example, PackageKit comes with a yum backend. On Debian, it would come with an apt backend. You can then have your own graphical package manager in Sugar using the PackageKit APIs, no matter what the underlying OS is (given that there is a PackageKit backend for this OS). 3. as a bonus, it would be nice to see if PackageKit can handle multiple backends on a same system. This way, you could also have a ? .xo ? backend for PackageKit that would simply take .xo bundles from activities.sugarlabs.org (just like yum takes .rpm packages from the repositories). This way, in the same graphical interface, you can both install/update/remove the system packages and the .xo bundles Now, I have no idea if that's even doable with PackageKit (the double backend part), but that could be a lead worth chasing. After that, if a distro chooses to package the activities, that's great, because you have some kind of a ? stable fallback set ? on which the user can fallback if he played too much with the .xo bundles to have newer stuff. But he still can do it if he wants to try out activities not available as RPMs, or if he wants to play with the latest update that didn't make it to the distro repositories yet. And if later on Sugar decides to stop one packaging effort or the other, just disable one of the PackageKit backends and use the other. Regards, ---------- Mathieu Bridon (bochecha) From mikus at bga.com Thu Jun 4 00:23:00 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 03 Jun 2009 20:23:00 -0400 Subject: rsync on F11 on XO-1 is giving me trouble Message-ID: <4A2713E4.6040408@bga.com> Disclaimer: This is "For Your Information" (not for "Action") I have a "permanent" SD card in each of my XOs, and use 'rsync' to keep the contents of these SD cards synchronized between systems. Lately I've been encountering a lot of trouble with using 'rsync' between F11-on-XO systems. Typically, the data transfer stalls (and sometimes leaves the receiving-end SD card corrupted). I'm not sure which end of the rsync data transfer is at fault. The daemon (sending) end is left high and dry, but at least in that machine I can continue (and 'kill -2' the daemon, if need be). The machine at the receiving end typically becomes unresponsive (often the only thing I can do is to power off). My guess is that the receiving end may be running out of memory (though I *do* have a swap partition defined). I'm not writing a bug report, because I cannot deliberately reproduce this (it just happens, sooner or later). I'm seeing this both with recent rawhide-xo builds and with recent SoaS builds. mikus From pgf at laptop.org Thu Jun 4 03:31:38 2009 From: pgf at laptop.org (Paul Fox) Date: Wed, 03 Jun 2009 23:31:38 -0400 Subject: rsync on F11 on XO-1 is giving me trouble In-Reply-To: <4A2713E4.6040408@bga.com> References: <4A2713E4.6040408@bga.com> Message-ID: <16567.1244086298@foxharp.boston.ma.us> mikus wrote: > Disclaimer: This is "For Your Information" (not for "Action") > > I have a "permanent" SD card in each of my XOs, and use 'rsync' to > keep the contents of these SD cards synchronized between systems. > Lately I've been encountering a lot of trouble with using 'rsync' > between F11-on-XO systems. Typically, the data transfer stalls (and > sometimes leaves the receiving-end SD card corrupted). since i know you use ethernet quite a bit, is this with a wired or a wireless connection (or both)? paul > > I'm not sure which end of the rsync data transfer is at fault. The > daemon (sending) end is left high and dry, but at least in that > machine I can continue (and 'kill -2' the daemon, if need be). The > machine at the receiving end typically becomes unresponsive (often > the only thing I can do is to power off). My guess is that the > receiving end may be running out of memory (though I *do* have a > swap partition defined). > > I'm not writing a bug report, because I cannot deliberately > reproduce this (it just happens, sooner or later). I'm seeing this > both with recent rawhide-xo builds and with recent SoaS builds. > > mikus > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list =--------------------- paul fox, pgf at laptop.org From mikus at bga.com Thu Jun 4 03:32:40 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 03 Jun 2009 23:32:40 -0400 Subject: rsync on F11 on XO-1 is giving me trouble Message-ID: <4A274058.3090401@bga.com> > > Lately I've been encountering a lot of trouble with using 'rsync' > > between F11-on-XO systems. > > since i know you use ethernet quite a bit, is this with a wired > or a wireless connection (or both)? I do not have any wireless at home. This is with multiple XOs connected to my home ethernet LAN; the daemon is started on the sending XO; the 'rsync' command is issued from the receiving XO, giving the dotted-decimal IP address of the (passive) sending XO. [Collaborative Activities between XOs, such as Chat or Write, work fine over the wired ethernet.] [As an experiment, I was able to manually configure F10-based Joyride to use mesh instead of the ethernet for 'rsync'. But I've been too lazy to repeat that experiment with F11-based builds.] mikus From rms at 1407.org Thu Jun 4 09:17:48 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 4 Jun 2009 10:17:48 +0100 Subject: Test run of 2009/05/25 image Message-ID: <20090604091748.GA10145@roque.1407.org> Hi, Forewarning: non scientific tests... * "occasional" creating devices hang For me, it was "occasional" boot. Once it took 16 boots, the last 3 of which separated by two hours from the other 13. * wasted memory GNOME just SHOULDN'T be there. A simpler window manager will make it much better. I installed OpenBox but it was very hard because of OOM killer :) * OpenBox launches way too many GNOME daemons. I had to kill a lot of them by hand in order to get some more free memory. * not enough memory for yum 99% of the attempts to install anything resulted in OOM kills * speed of GNOME interface was acceptable really, this was the biggest surprise I had... Conclusion: fedora-olpc, to be a sucess, needs a much slimmer UI than that of GNOME. Rui From bochecha at fedoraproject.org Thu Jun 4 09:24:23 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Thu, 4 Jun 2009 11:24:23 +0200 Subject: Test run of 2009/05/25 image In-Reply-To: <20090604091748.GA10145@roque.1407.org> References: <20090604091748.GA10145@roque.1407.org> Message-ID: <2d319b780906040224u6d9ca037id52735d428d2f82e@mail.gmail.com> > Conclusion: > > ? fedora-olpc, to be a sucess, needs a much slimmer UI than that > ? of GNOME. Isn't there Sugar on those isos too ? ---------- Mathieu Bridon (bochecha) From rms at 1407.org Thu Jun 4 09:35:00 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 4 Jun 2009 10:35:00 +0100 Subject: Test run of 2009/05/25 image In-Reply-To: <2d319b780906040224u6d9ca037id52735d428d2f82e@mail.gmail.com> References: <20090604091748.GA10145@roque.1407.org> <2d319b780906040224u6d9ca037id52735d428d2f82e@mail.gmail.com> Message-ID: <20090604093500.GB10145@roque.1407.org> On Thu, Jun 04, 2009 at 11:24:23AM +0200, Mathieu Bridon (bochecha) wrote: > > Conclusion: > > ? fedora-olpc, to be a sucess, needs a much slimmer UI than that > > ? of GNOME. > > Isn't there Sugar on those isos too ? Sugar isn't exactly slim :) Rui From bkearney at redhat.com Thu Jun 4 12:02:46 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Thu, 04 Jun 2009 08:02:46 -0400 Subject: Package Honey Activities? In-Reply-To: <2d319b780906031518k5f08f55ah5b2f5eb8e59123ff@mail.gmail.com> References: <4A26C8F0.3070005@redhat.com> <2d319b780906031518k5f08f55ah5b2f5eb8e59123ff@mail.gmail.com> Message-ID: <4A27B7E6.5040100@redhat.com> Mathieu Bridon (bochecha) wrote: >> A). If all Activities were distributed as .xo bundles through the Sugar >> platform (such as access to activities.sugarlabs.org), distro packagers >> would only have to worry about keeping the core Sugar and it's dependancies >> up-to date, not all the faster changing stuff. >> Look at the fun I caused :). I will still try to get my review done, if for no reason then it makes the out of the box install a bit nicer. Then we can see how the bits play out. -- bk From dsd at laptop.org Thu Jun 4 12:27:20 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 13:27:20 +0100 Subject: livecd-iso-to-xo for XO-1.5 Message-ID: <1244118440.18256.4.camel@polyethylene> Hi, Here's my initial attempt at an equivalent livecd-iso-to-xo.sh for the XO-1.5. This involves a filesystem change to ext2 as we no longer have raw flash access (right?). Completely untested. Open questions: 1. What should the root= kernel parameter be? 2. How would we distribute this to testers and developers? The resultant file is 4gb, albeit sparse. Maybe rsync can handle sparse files efficiently. 3. How do we use OFW to flash this, including a partition table etc? Daniel -------------- next part -------------- #!/bin/bash cleanup() { [ -d "$DISKMOUNT" ] && { umount $DISKMOUNT; rmdir $DISKMOUNT; } [ -d "$SQUASHMNT" ] && { umount $SQUASHMNT; rmdir $SQUASHMNT; } [ -d "$ISOMNT" ] && { umount $ISOMNT; rmdir $ISOMNT; } [ -d "$ROOT" ] && { umount $ROOT; rmdir $ROOT; } } exitclean() { echo "Cleaning up to exit..." cleanup exit 1 } trap exitclean SIGINT SIGTERM ISO=$(readlink -f "$1") IMG=$(readlink -f "$2") ISOMNT=$(mktemp -d /media/isotmp.XXXXXX) mount -o loop,ro "$ISO" $ISOMNT || exitclean SQUASHMNT=$(mktemp -d /media/squashtmp.XXXXXX) mount -o loop,ro $ISOMNT/LiveOS/squashfs.img $SQUASHMNT || exitclean DISKMOUNT=$(mktemp -d /media/disktmp.XXXXXX) mount -o loop,ro $SQUASHMNT/LiveOS/ext3fs.img $DISKMOUNT || exitclean echo "Create root filesystem..." ROOT=$(mktemp -d /tmp/root.XXXXXX) dd if=/dev/zero of=$IMG bs=1 count=1 seek=4G || exitclean mke2fs -O dir_index -F $IMG || exitclean mount -o loop $IMG $ROOT || exitclean cp -a $DISKMOUNT/* $ROOT cp $ISOMNT/isolinux/initrd0.img $ROOT/boot cp $ISOMNT/isolinux/vmlinuz0 $ROOT/boot if [ ! -e $ROOT/boot/olpc.fth ] ; then echo "no $ROOT/boot/olpc.fth - should have been added by whatever installed $ROOT/boot/vmlinuz*" exit 1; fi sed -i -e 's/rootfstype=jffs2/rootfstype=ext4/' $ROOT/boot/olpc.fth echo "Done." cleanup From martin at martindengler.com Thu Jun 4 12:54:33 2009 From: martin at martindengler.com (Martin Dengler) Date: Thu, 4 Jun 2009 13:54:33 +0100 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <1244118440.18256.4.camel@polyethylene> References: <1244118440.18256.4.camel@polyethylene> Message-ID: <20090604125432.GK29763@ops-13.xades.com> On Thu, Jun 04, 2009 at 01:27:20PM +0100, Daniel Drake wrote: > 3. How do we use OFW to flash this, including a partition table > etc? http://wiki.laptop.org/go/OFW_NAND_FLASH_Updater#Make_a_Partition_Map_and_Fill_Some_Partitions Looks like olpc-image-builder from http://dev.laptop.org/~dsaxena/ubi_test/olpc-image-builder as discussed http://wiki.laptop.org/go/UBIFS_initial_experiments#Image_Building by dsaxena can be used, along with the OFW update-nand word as mentioned http://wiki.laptop.org/go/UBIFS_initial_experiments#Image_Download_and_Installation Should be instructional to do in practice (and then document!). Perhaps it'd be a good time to partition /home and/or implement some of the partitioning layouts that have been batted about. Willing to help test out that if you need. > Daniel Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin.langhoff at gmail.com Thu Jun 4 13:13:35 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 4 Jun 2009 15:13:35 +0200 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <1244118440.18256.4.camel@polyethylene> References: <1244118440.18256.4.camel@polyethylene> Message-ID: <46a038f90906040613tf5984dau99c5e14637a80fcd@mail.gmail.com> On Thu, Jun 4, 2009 at 2:27 PM, Daniel Drake wrote: > ?2. How would we distribute this to testers and developers? > ? ?The resultant file is 4gb, albeit sparse. Maybe rsync can handle > ? ?sparse files efficiently. those images gzip pretty well. And you can do gzip -dc foobar.img.gz | dd of=/dev/something At least that's working well for ext2/3 images for SD cards in the context of XS. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From mikus at bga.com Thu Jun 4 13:21:35 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Thu, 04 Jun 2009 09:21:35 -0400 Subject: Test run of 2009/05/25 image Message-ID: <4A27CA5F.1070903@bga.com> These days I do almost all my running with the most recent F11-based builds available (e.g., 2009/05/25 image and newer). It is only the lack of audio or video in F11-on-XO that keeps me from abandoning my 8.2.1 systems. Most of the items mentioned don't bother me: [Note: My XOs all have a "permanent" SD card, which holds lots of executables (including activities) + gigs of data + swap partition.] > Forewarning: non scientific tests... > > * "occasional" creating devices hang > > For me, it was "occasional" boot. Once it took 16 boots, the last > 3 of which separated by two hours from the other 13. My *average* number of repeats before boot is successful: 5 or so > > * wasted memory > GNOME just SHOULDN'T be there. A simpler window manager will > make it much better. I installed OpenBox but it was very hard > because of OOM killer :) Looking only at what XO-1s I have powered up at this instant: nand occupancy for 2009/05/28+: 516 MB nand occupancy for build 801: 504 MB [Both values are affected by how many Activities installed in nand.] 256 MB of RAM is not much. That's why I have an active swap partition. I'm not sure how much a smaller "resident system" would help. I do experience [particularly when using 'find /'] unwanted system stalls (OOM killer?) after the system has been running for a while. My guess would be that there are memory leaks - which would be a problem even if initially available amount of memory were greater. Here's hoping that eventually enough people will be using F11-on-XO to justify investigating such problems. > > * OpenBox launches way too many GNOME daemons. > I had to kill a lot of them by hand in order to get some more > free memory. I normally run applications with Sugar instead of Gnome as the manager. Haven't tried to overcommit with F11-on-XO builds, but in my experience with F9-based builds, two "monster" applications active simultaneously (e.g., Firefox + Adobe Reader) are as much as the XO-1 can handle. > > * not enough memory for yum > 99% of the attempts to install anything resulted in OOM kills Helps to periodically do 'yum clean all'. Yum normally runs fine. [Did cause a system stall once when trying to update glibc - but that was on a 'yum upgrade' that was pulling in some 40 packages.] > > * speed of GNOME interface was acceptable > really, this was the biggest surprise I had... > > Conclusion: > > fedora-olpc, to be a sucess, needs a much slimmer UI than that > of GNOME. "Success" needs to be defined. Seems to me the OLPC was envisioned mainly for a single-application environment. Except for being slow at processing, I think it succeeds admirably. [GNOME-on-XO has the advantage of clarity and not-very-complicated. Yes, other UIs can be fashioned, but work would have to be put in to make them "do enough to make it easy for users". ] mikus From cjb at laptop.org Thu Jun 4 17:16:45 2009 From: cjb at laptop.org (Chris Ball) Date: Thu, 04 Jun 2009 13:16:45 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <1244118440.18256.4.camel@polyethylene> (Daniel Drake's message of "Thu, 04 Jun 2009 13:27:20 +0100") References: <1244118440.18256.4.camel@polyethylene> Message-ID: Hi, > 1. What should the root= kernel parameter be? LABEL=OLPCRoot, unless there's a good reason not to use LABEL=. We'll want to boot it from NAND (/dev/hda1), USB or SD. > 2. How would we distribute this to testers and developers? Just as with rawhide-xo, I think. I'll set up a cron job and URL for this build. > The resultant file is 4gb, albeit sparse. Maybe rsync can handle > sparse files efficiently. Or we could distribute it as a .bootable.gz, which is what I've been doing for rawhide-xo. > 3. How do we use OFW to flash this, including a partition table > etc? We can just run fdisk on the loop device first, I think? Then, you could flash it to NAND (the XO-1.5 NAND shows up as an IDE device) with "zcat new.bootable.gz >/dev/hda", or to USB with >/dev/sdX. Presumably OFW could be made to do something similar; I'm not sure what "copy-nand" should look like for the 1.5, now that it's IDE. Any problems with this? Thanks, - Chris. -- Chris Ball From dsd at laptop.org Thu Jun 4 17:53:03 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 18:53:03 +0100 Subject: another boot hang (not the jffs2 one) Message-ID: <1244137983.18256.38.camel@polyethylene> I'm seeing a hang during early boot of recent F11-XO images. Right now I have reproduced on freshly-reflashed 20090528 and 20090525, on 2 different XOs. It is not the "Unknown filesystem jffs2" hang or the "Creating devices" hang. It is much earlier, before the kernel has even kicked the framebuffer. At the point of the hang, the output on screen is: Boot device: /nandflash:....... Loading ramdisk image from nand:\boot\initrd0.img ... (this screen is from the OpenFirmware boot process, the screen background is still grey, the Linux kernel does not appear to have become alive at all) It hangs at this point, with no extra output on serial console, and is unresponsive to OFW frame key for interruption. Is anyone else seeing this? (please don't confuse this with other boot hangs, where the screen contents are different) Daniel From pbrobinson at gmail.com Thu Jun 4 18:18:07 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 4 Jun 2009 19:18:07 +0100 Subject: another boot hang (not the jffs2 one) In-Reply-To: <1244137983.18256.38.camel@polyethylene> References: <1244137983.18256.38.camel@polyethylene> Message-ID: <5256d0b0906041118lf0baf38o98b146c4489a4220@mail.gmail.com> > I'm seeing a hang during early boot of recent F11-XO images. Right now I > have reproduced on freshly-reflashed 20090528 and 20090525, on 2 > different XOs. It is not the "Unknown filesystem jffs2" hang or the > "Creating devices" hang. It is much earlier, before the kernel has even > kicked the framebuffer. > > At the point of the hang, the output on screen is: > Boot device: /nandflash:....... > Loading ramdisk image from nand:\boot\initrd0.img ... > > (this screen is from the OpenFirmware boot process, the screen > background is still grey, the Linux kernel does not appear to have > become alive at all) > > It hangs at this point, with no extra output on serial console, and is > unresponsive to OFW frame key for interruption. > > Is anyone else seeing this? (please don't confuse this with other boot > hangs, where the screen contents are different) Not yet, but its been a couple of weeks since I've tried rawhide on my XO because I've been so busy with other stuff. Do you have a serial console or jtag (which ever one the XO supports) to be able to get the output before the framebuffer initiates? Peter From dsd at laptop.org Thu Jun 4 18:22:20 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 19:22:20 +0100 Subject: another boot hang (not the jffs2 one) In-Reply-To: <5256d0b0906041118lf0baf38o98b146c4489a4220@mail.gmail.com> References: <1244137983.18256.38.camel@polyethylene> <5256d0b0906041118lf0baf38o98b146c4489a4220@mail.gmail.com> Message-ID: <1244139740.18256.40.camel@polyethylene> On Thu, 2009-06-04 at 19:18 +0100, Peter Robinson wrote: > Not yet, but its been a couple of weeks since I've tried rawhide on my > XO because I've been so busy with other stuff. Do you have a serial > console or jtag (which ever one the XO supports) to be able to get the > output before the framebuffer initiates? Yes, the entire serial console output is: + Forthmacs Type 'i' to interrupt stand-init sequence USB2 devices: /pci/usb at f,5/wlan at 0,0 USB1 devices: Type the Esc key to interrupt automatic startup Boot device: /nandflash:\boot\olpc.fth Arguments: Boot device: /nandflash:\boot\olpc.fth Arguments: Boot device: /nandflash:\boot\vmlinuz0 Arguments: root=mtd0 rootfstype=jffs2 console=tty0 console=ttyS0,115200 fbcon=font:SUN12x22 Loading ramdisk image from nand:\boot\initrd0.img ... Nothing of interest, unfortunately. Daniel From mikus at bga.com Thu Jun 4 18:10:23 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Thu, 04 Jun 2009 14:10:23 -0400 Subject: another boot hang (not the jffs2 one) Message-ID: <4A280E0F.3050606@bga.com> Console ends with > Loading ramdisk image from nand:\boot\initrd0.img ... The question is - how repeatable is this situation ? I get these from time to time on my XO-1s. My usual response is to repeat the boot sequence from the beginning, *after* having changed my external device configuration (for instance, by pulling some cables from the USB sockets on the XO). [My guess is that the boot software gets "stuck" waiting for something -- and that by changing the external devices I somehow change the internal timings of boot.] ---- For me, booting sometimes also gets "stuck" soon after > Type the Esc key to interrupt automatic startup My response is to just repeat the boot sequence from the beginning. Without me doing anything except glaring at the XO, it appears to alter its internal timings enough to next time get past this point. mikus From dsd at laptop.org Thu Jun 4 19:12:13 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 20:12:13 +0100 Subject: working around boot problems Message-ID: <1244142733.18256.48.camel@polyethylene> It's frustratingly difficult to immediately work on the "unknown filesystem jffs2" problem because more often than not, the same kernel for me fails to even reach that stage (see my "another boot hang" thread). Switching to Deepak's 2.6.30-rc5 kernel for XO, both problems mysteriously go away. Here are the files and the procedure if anyone else wants to try it out. http://dev.laptop.org/~dsd/20090604/ I don't know what else works or fails in Deepak's kernel, or if there are any plans to ship it instead of the Fedora kernel for these XO-1 efforts. Daniel From dsd at laptop.org Thu Jun 4 19:16:18 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 20:16:18 +0100 Subject: jffs2 mounting problem Message-ID: <1244142978.18256.51.camel@polyethylene> Hi, I've been digging into the "unknown filesystem type: jffs2" problem that makes boot fail most of the time on XO-1. First observation, this isn't the message that appears furthest down on the screen, it's about halfway down. The one at the bottom of the screen says "creating devices", making it appear like the hang has happened there, but actually the screen is screwed up at this point and lines being printed are appearing in something like this order: 5 6 7 8 unknown filesystem type jffs2 1 2 3 4 creating devices I added some initrd debug messages and confirmed that jffs2 is not loaded before the "mount" call is made. The mount procedure (on the kernel side) is therefore responsible for loading the module. Turning plymouth off (by commenting out the appropriate lines in the initrd scripts) causes messages to appear on-screen in the right order *and* seems to reliably work around the race bug. At this point I'm having severe difficulty to boot this kernel to add more diagnostics, even after a fresh reflash, even on a 2nd XO, due to an even earlier hang problem (see my "another boot hang" thread). Daniel From pbrobinson at gmail.com Thu Jun 4 19:20:56 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 4 Jun 2009 20:20:56 +0100 Subject: working around boot problems In-Reply-To: <1244142733.18256.48.camel@polyethylene> References: <1244142733.18256.48.camel@polyethylene> Message-ID: <5256d0b0906041220n2aae59aal461e1a01eb5450ad@mail.gmail.com> > It's frustratingly difficult to immediately work on the "unknown > filesystem jffs2" problem because more often than not, the same kernel > for me fails to even reach that stage (see my "another boot hang" > thread). > > Switching to Deepak's 2.6.30-rc5 kernel for XO, both problems > mysteriously go away. Here are the files and the procedure if anyone > else wants to try it out. > > http://dev.laptop.org/~dsd/20090604/ > > I don't know what else works or fails in Deepak's kernel, or if there > are any plans to ship it instead of the Fedora kernel for these XO-1 > efforts. > What about the 2.6.30-rc8 kernel that's sitting in koji waiting for the F-12 rawhide floodgates to open. You can get it directly from koji here http://koji.fedoraproject.org/koji/buildinfo?buildID=104641 Peter From dsd at laptop.org Thu Jun 4 19:51:58 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 04 Jun 2009 20:51:58 +0100 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: References: <1244118440.18256.4.camel@polyethylene> Message-ID: <1244145118.18256.57.camel@polyethylene> On Thu, 2009-06-04 at 13:16 -0400, Chris Ball wrote: > Hi, > > > 1. What should the root= kernel parameter be? > > LABEL=OLPCRoot, unless there's a good reason not to use LABEL=. > We'll want to boot it from NAND (/dev/hda1), USB or SD. Checked in on xo-1.5 branch of projects/fedora-xo Raises some questions for later...in what form are we going to use an initrd (our previous one, or a different one) and will it support LABEL= > > The resultant file is 4gb, albeit sparse. Maybe rsync can handle > > sparse files efficiently. > > Or we could distribute it as a .bootable.gz, which is what I've been > doing for rawhide-xo. OK, the .img file now gets compressed with gzip, and indeed it compresses very well. Checked in on xo-1.5 branch of projects/fedora-xo > We can just run fdisk on the loop device first, I think? Then, you > could flash it to NAND (the XO-1.5 NAND shows up as an IDE device) > with "zcat new.bootable.gz >/dev/hda", or to USB with >/dev/sdX. > Presumably OFW could be made to do something similar; I'm not sure > what "copy-nand" should look like for the 1.5, now that it's IDE. > > Any problems with this? As discussed on IRC, this is a bit tricky and since we don't know what the OFW-level interface is going to look like, I've left this for now. Daniel From cjb at laptop.org Thu Jun 4 20:03:28 2009 From: cjb at laptop.org (Chris Ball) Date: Thu, 04 Jun 2009 16:03:28 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <1244145118.18256.57.camel@polyethylene> (Daniel Drake's message of "Thu, 04 Jun 2009 20:51:58 +0100") References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> Message-ID: Hi Dan, > Raises some questions for later...in what form are we going to > use an initrd (our previous one, or a different one) and will it > support LABEL= We're going to be obliged to ship our security work with XO-1.5. Whether we use the old Debian initrd (which is seeming crufty and hard to maintain) or move up to a more standard F11 initrd as a base is still an open question -- I'd side with upgrading to F11, if we can work out how to get it done. (Part of it may involve converting bootanim to be a plymouth plugin; another open question.) Thanks, - Chris. -- Chris Ball From pgf at laptop.org Thu Jun 4 20:12:36 2009 From: pgf at laptop.org (Paul Fox) Date: Thu, 04 Jun 2009 16:12:36 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> Message-ID: <14256.1244146356@foxharp.boston.ma.us> chris wrote: > Hi Dan, > > > Raises some questions for later...in what form are we going to > > use an initrd (our previous one, or a different one) and will it > > support LABEL= > > We're going to be obliged to ship our security work with XO-1.5. > Whether we use the old Debian initrd (which is seeming crufty and > hard to maintain) or move up to a more standard F11 initrd as a base > is still an open question -- I'd side with upgrading to F11, if we > can work out how to get it done. (Part of it may involve converting > bootanim to be a plymouth plugin; another open question.) which begs another question: if we're already customizing fedora, how much are we going to allow ourselves to customize it? e.g., could we simply remove plymouth, and install bootanim, if that makes sense? i'd think we'd want the path-of-least-resistance solution in most cases. paul =--------------------- paul fox, pgf at laptop.org From cjb at laptop.org Thu Jun 4 20:23:25 2009 From: cjb at laptop.org (Chris Ball) Date: Thu, 04 Jun 2009 16:23:25 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <14256.1244146356@foxharp.boston.ma.us> (Paul Fox's message of "Thu, 04 Jun 2009 16:12:36 -0400") References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> <14256.1244146356@foxharp.boston.ma.us> Message-ID: Hi, > which begs another question: if we're already customizing fedora, > how much are we going to allow ourselves to customize it? e.g., > could we simply remove plymouth, and install bootanim, if that > makes sense? We certainly could. I think plymouth may be more robust than either bootanim implementation, and the plymouth authors have prototyped an olpc theme for us, so it seems worth giving that a serious look rather than planning to maintain bootanim on our own. (Plymouth also allows prettier graphics, in case we decide we'd like a smooth animation.) - Chris. -- Chris Ball From pgf at laptop.org Thu Jun 4 20:28:20 2009 From: pgf at laptop.org (Paul Fox) Date: Thu, 04 Jun 2009 16:28:20 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> <14256.1244146356@foxharp.boston.ma.us> Message-ID: <15973.1244147300@foxharp.boston.ma.us> chris wrote: > Hi, > > > which begs another question: if we're already customizing fedora, > > how much are we going to allow ourselves to customize it? e.g., > > could we simply remove plymouth, and install bootanim, if that > > makes sense? > > We certainly could. I think plymouth may be more robust than either > bootanim implementation, and the plymouth authors have prototyped an > olpc theme for us, so it seems worth giving that a serious look rather > than planning to maintain bootanim on our own. (Plymouth also allows > prettier graphics, in case we decide we'd like a smooth animation.) i certainly never meant we shouldn't consider plymouth. i'm just dipping my toes into the "how much are we allowed to change?" discussion. (i seem to keep getting caught in plymouth threads. my question this time really was intended to have larger scope.) paul =--------------------- paul fox, pgf at laptop.org From sdaly.be at gmail.com Thu Jun 4 20:31:08 2009 From: sdaly.be at gmail.com (Sean DALY) Date: Thu, 4 Jun 2009 22:31:08 +0200 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <15973.1244147300@foxharp.boston.ma.us> References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> <14256.1244146356@foxharp.boston.ma.us> <15973.1244147300@foxharp.boston.ma.us> Message-ID: <378b2b050906041331h6e1d994ewc86cc56b8665dc7a@mail.gmail.com> FWIW, on the Sugar Labs side we are interested in Plymouth especially its potential for use with other distros, we've been doing mockups based on the OLPC prototype: http://wiki.sugarlabs.org/go/Marketing_Team/Boot_Logo Sean On Thu, Jun 4, 2009 at 10:28 PM, Paul Fox wrote: > chris wrote: > ?> Hi, > ?> > ?> ? ?> which begs another question: if we're already customizing fedora, > ?> ? ?> how much are we going to allow ourselves to customize it? ?e.g., > ?> ? ?> could we simply remove plymouth, and install bootanim, if that > ?> ? ?> makes sense? > ?> > ?> We certainly could. ?I think plymouth may be more robust than either > ?> bootanim implementation, and the plymouth authors have prototyped an > ?> olpc theme for us, so it seems worth giving that a serious look rather > ?> than planning to maintain bootanim on our own. ?(Plymouth also allows > ?> prettier graphics, in case we decide we'd like a smooth animation.) > > i certainly never meant we shouldn't consider plymouth. ?i'm just > dipping my toes into the "how much are we allowed to change?" > discussion. ?(i seem to keep getting caught in plymouth threads. > my question this time really was intended to have larger scope.) > > paul > =--------------------- > ?paul fox, pgf at laptop.org > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > From cjb at laptop.org Thu Jun 4 20:48:16 2009 From: cjb at laptop.org (Chris Ball) Date: Thu, 04 Jun 2009 16:48:16 -0400 Subject: livecd-iso-to-xo for XO-1.5 In-Reply-To: <15973.1244147300@foxharp.boston.ma.us> (Paul Fox's message of "Thu, 04 Jun 2009 16:28:20 -0400") References: <1244118440.18256.4.camel@polyethylene> <1244145118.18256.57.camel@polyethylene> <14256.1244146356@foxharp.boston.ma.us> <15973.1244147300@foxharp.boston.ma.us> Message-ID: Hi, > i certainly never meant we shouldn't consider plymouth. i'm just > dipping my toes into the "how much are we allowed to change?" > discussion. (i seem to keep getting caught in plymouth threads. > my question this time really was intended to have larger scope.) Ah, okay. I don't have anything prescriptive to say -- as you hinted at, the broad theme is that we're going to be modifying the initrd anyway, would like to stay close to upstream projects where possible, but are not compelled to avoid making changes if it's a path we feel we need to take. Thanks, - Chris. -- Chris Ball From rms at 1407.org Sun Jun 7 21:10:33 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Sun, 7 Jun 2009 22:10:33 +0100 Subject: Test run of 2009/05/25 image In-Reply-To: <4A27CA5F.1070903@bga.com> References: <4A27CA5F.1070903@bga.com> Message-ID: <20090607211033.GA10883@roque.1407.org> On Thu, Jun 04, 2009 at 09:21:35AM -0400, Mikus Grinbergs wrote: >> * wasted memory >> GNOME just SHOULDN'T be there. A simpler window manager will >> make it much better. I installed OpenBox but it was very hard >> because of OOM killer :) > > Looking only at what XO-1s I have powered up at this instant: > nand occupancy for 2009/05/28+: 516 MB > nand occupancy for build 801: 504 MB > [Both values are affected by how many Activities installed in nand.] > > 256 MB of RAM is not much. That's why I have an active swap partition. > I'm not sure how much a smaller "resident system" > would help. 256 is actually a lot, however the XO-1 is less usable with Fedora than the computers I used years back when having 64MB was at a premium :) >> * OpenBox launches way too many GNOME daemons. >> I had to kill a lot of them by hand in order to get some more >> free memory. > > I normally run applications with Sugar instead of Gnome as the manager. > Haven't tried to overcommit with F11-on-XO builds, but in my experience > with F9-based builds, two "monster" applications active simultaneously > (e.g., Firefox + Adobe Reader) are as much as the XO-1 can handle. Firefox is a DUD on small devices. Don't know about Fennec, but I liked seeing Midori installed by default :) >> * not enough memory for yum >> 99% of the attempts to install anything resulted in OOM kills > > Helps to periodically do 'yum clean all'. Yum normally runs fine. > [Did cause a system stall once when trying to update glibc - but that was > on a 'yum upgrade' that was pulling in some 40 packages.] Periodically? It was on the FIRST run of yum :) >> * speed of GNOME interface was acceptable >> really, this was the biggest surprise I had... >> >> Conclusion: >> >> fedora-olpc, to be a sucess, needs a much slimmer UI than that >> of GNOME. > > "Success" needs to be defined. Seems to me the OLPC was envisioned > mainly for a single-application environment. Except for being slow at > processing, I think it succeeds admirably. I'm not talking about the sugar interface, which is what you're talking about. Non-sugar interface is something I'm also interested. > [GNOME-on-XO has the advantage of clarity and not-very-complicated. Yes, > other UIs can be fashioned, but work would have to be put in to make them > "do enough to make it easy for users". to fashion Sugar.>] GNOME on XO is a total DUD. It's responsive, but there's not much ram for ANYTHING else. It's better to focus on a lightweigth window manager so you can run a terminal emulator or two, a browser, something else. I've definitly gotta try making personalized images. Rui From martin.langhoff at gmail.com Mon Jun 8 08:55:38 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 8 Jun 2009 10:55:38 +0200 Subject: Looking for a ucspi-ipc style tool in Fedora Message-ID: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> In my neverending quest for the School Server, I am looking for a 'unix socket superserver', something akin to xinetd listening on oldstyle unix sockets. Connecting to the right socket triggers the superserver to spawn a (potentially memory-heavy, privileged) process to handle the connection, with the superserver handling rate limiting, etc. xinetd doesn't seem to know how to do this at all. ucspi-unix and its close cousin ucspi-ipc seem to cover the requirements but are not in Fedora. Are there alternatives that I am overlooking? thanks! m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From todd at webpath.net Mon Jun 8 16:34:53 2009 From: todd at webpath.net (Todd Robinson) Date: Mon, 08 Jun 2009 12:34:53 -0400 Subject: Fedora 11 SD Cards for XOs In-Reply-To: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> References: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> Message-ID: <4A2D3DAD.7000608@webpath.net> Is the procedure the same as for F10 where the following can be used to create 4GB SD cards?: bash livecd-iso-to-disk.sh --xo --overlay-size-mb 320 --swap-size-mb 256 F11-i686-Live.iso /dev/$device Also is there a newer livecd-iso-to-disk.sh script I should use, or is the one used to create the F10 SD cards sufficient? Please get back to me so we can begin shipping F11 SD Cards tomorrow. Thank you, Todd From pbrobinson at gmail.com Mon Jun 8 16:34:39 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Mon, 8 Jun 2009 17:34:39 +0100 Subject: Fedora 11 SD Cards for XOs In-Reply-To: <4A2D3DAD.7000608@webpath.net> References: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> <4A2D3DAD.7000608@webpath.net> Message-ID: <5256d0b0906080934y7381700g5ab68025719e3132@mail.gmail.com> Hi Todd, > Is the procedure the same as for F10 where the following can be used to > create 4GB SD cards?: > bash livecd-iso-to-disk.sh --xo --overlay-size-mb 320 --swap-size-mb 256 > F11-i686-Live.iso /dev/$device > > Also is there a newer livecd-iso-to-disk.sh script I should use, or is the > one used to create the F10 SD cards sufficient? > > Please get back to me so we can begin shipping F11 SD Cards tomorrow. I think it should be fine. There's also a version of the script here http://dev.laptop.org/~cjb/rawhide-xo/ but I'm not sure if its changed at all. Peter From pgf at laptop.org Tue Jun 9 02:25:36 2009 From: pgf at laptop.org (Paul Fox) Date: Mon, 08 Jun 2009 22:25:36 -0400 Subject: Reminder: no new Fedora 9 CVS branches In-Reply-To: <200906082053.49739.dennis@ausil.us> References: <200906082053.49739.dennis@ausil.us> Message-ID: <7354.1244514336@foxharp.boston.ma.us> dennis wrote: > As Fedora 11 is released on Tuesday June 9th there will be no > new CVS branches allowed for F-9 > http://fedoraproject.org/wiki/PackageMaintainers/Policy/EOL > lists the policy in effect. This means that F-9 is now in a > maintenance only cycle, with EOL fast approaching, the exact > EOL date will be set at the FESCo meeting this week. so this means, from OLPC's standpoint, that until F11 is available and useful on an XO, no new or revised packages will be available to XO owners. is that right? (i'm not disagreeing or complaining about the fedora policy -- i'm just thinking that since there was no F10, and F11 doesn't yet run fully, the XO is further behind than it otherwise might be.) paul =--------------------- paul fox, pgf at laptop.org From mikus at bga.com Tue Jun 9 13:37:06 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Tue, 09 Jun 2009 09:37:06 -0400 Subject: [OT] Test run of 2009/05/25 image Message-ID: <4A2E6582.8030709@bga.com> Disclaimer: This post contains Off-Topic meta discussion >>> Conclusion: >>> >>> fedora-olpc, to be a sucess, needs a much slimmer UI than that >>> of GNOME. >> >> "Success" needs to be defined. Seems to me the OLPC was envisioned >> mainly for a single-application environment. Except for being slow at >> processing, I think it succeeds admirably. > > I'm not talking about the sugar interface, which is what you're talking > about. > > Non-sugar interface is something I'm also interested. The reason for my enthusiasm: I think the OLPC offers the bringing of technological assistance to economically disadvantaged locations. I think that people who focus on "slimming" the OLPC are missing the point. What they end up with is a slow, small Linux system. But if what they want is a small Linux system, today's 'netbooks' offer more capability (and as netbooks continue to be produced by the millions, I expect tomorrow's models to cost less than the OLPC). For those who are interested in using the OLPC to bring conventional applications to people who already have access to technology - why not work with a netbook instead? For those who think the OLPC *is* suited to the environments in which it is being deployed - let's work on developing OLPC-scale applications to assist 'the things people do' wherever such "computerization" could improve matters. mikus From rms at 1407.org Thu Jun 11 14:09:40 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 11 Jun 2009 15:09:40 +0100 Subject: [OT] Test run of 2009/05/25 image In-Reply-To: <4A2E6582.8030709@bga.com> References: <4A2E6582.8030709@bga.com> Message-ID: <20090611140940.GB29225@roque.1407.org> On Tue, Jun 09, 2009 at 09:37:06AM -0400, Mikus Grinbergs wrote: >>>> Conclusion: >>>> fedora-olpc, to be a sucess, needs a much slimmer UI than that >>>> of GNOME. >>> >>> "Success" needs to be defined. Seems to me the OLPC was envisioned >>> mainly for a single-application environment. Except for being slow at >>> processing, I think it succeeds admirably. >> >> I'm not talking about the sugar interface, which is what you're talking >> about. >> >> Non-sugar interface is something I'm also interested. > > The reason for my enthusiasm: I think the OLPC offers the bringing of > technological assistance to economically disadvantaged locations. > > I think that people who focus on "slimming" the OLPC are missing the > point. What they end up with is a slow, small Linux system. Are you seriously considering the implications of your statement? If slimming ends up on a slow small GNU/Linux system, then *not* slimming ends up with a slower and bloated GNU/Linux system. > But if > what they want is a small Linux system, today's 'netbooks' offer more > capability (and as netbooks continue to be produced by the millions, I > expect tomorrow's models to cost less than the OLPC). No, they don't. I don't know of a netbook which is as resistant or even readable in sunlight as the XO can be. > For those who are interested in using the OLPC to bring conventional > applications to people who already have access to technology - why not > work with a netbook instead? Not conventional, just usable (which it isn't). > For those who think the OLPC *is* suited to > the environments in which it is being deployed - let's work on developing > OLPC-scale applications to assist 'the things people do' wherever such > "computerization" could improve matters. Then what's your problem, man? :) Rui From dsd at laptop.org Thu Jun 11 18:16:00 2009 From: dsd at laptop.org (Daniel Drake) Date: Thu, 11 Jun 2009 19:16:00 +0100 Subject: Fwd: plymouth performance In-Reply-To: <1244744009.2344.56.camel@polyethylene> References: <1244744009.2344.56.camel@polyethylene> Message-ID: <818423da0906111116p2677fc35m62200fc9cddfcd9b@mail.gmail.com> FYI... ---------- Forwarded message ---------- From: Daniel Drake Date: 2009/6/11 Subject: plymouth performance To: plymouth at lists.freedesktop.org Hi, I've done some timings of plymouth vs non-plymouth boots on my XO laptops, to see how much of an impact it has on boot time. I took each measurement 3 times and then averaged. All recorded times were without much variance; these timings were reliable. I measured by pausing OFW during boot, entering "boot", and then starting a stopwatch at the same time as pressing enter to execute the boot command. On the XO-1 I stopped the stopwatch as soon as I saw the mouse cursor (just before gdm comes up). On the XO-1.5 I stopped the stopwatch as soon as I saw the text at the center of the gdm login screen. For the "without" tests, I removed the rhgb kernel parameter parameter and added console=tty0 On the XO-1: Without plymouth: 61.53 seconds bootup time With plymouth: 79.82 seconds bootup time +18.29 seconds increase, or 30% regression On the XO-1.5: Without plymouth: 24.78 seconds bootup time With plymouth: 27.07 seconds bootup time +2.29 seconds increase, or 10% regression We have a similar problem with OLPC's boot animation code on the XO-1. We recently found out that it slows down boot by about 15 seconds with just a simple animation. However, two superheroes came along and implemented an awesome new algorithm which only redraws the parts of the screen that have changed from the last frame. This completely cuts out the 15-second regression to the point where when you measure timings like the above tests, it often appears that it is tiny bit faster to boot *with* the animation... I wonder if that could be implemented in plymouth. The code is here: http://dev.laptop.org/git/users/bobbyp/bootanim/ Daniel From mikus at bga.com Thu Jun 11 17:54:04 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Thu, 11 Jun 2009 13:54:04 -0400 Subject: [OT] Test run of 2009/05/25 image Message-ID: <4A3144BC.7010803@bga.com> >> I think that people who focus on "slimming" the OLPC are missing the >> point. What they end up with is a slow, small Linux system. > > Are you seriously considering the implications of your statement? > > If slimming ends up on a slow small GNU/Linux system, then *not* slimming > ends up with a slower and bloated GNU/Linux system. Yes, I am seriously considering the implications of my statement. My motivation for starting this thread was to go on record as preferring that people "add to" what they believe the OLPC can do well, rather than "subtract from" what has been done so far because aspects of the OLPC's behavior do not meet their expectations. Given that 'netbooks' are already outselling the OLPC, and that in my opinion the development resources available to the producers of netbook systems far exceed the resources of organizations producing the OLPC, I think trying to sell the OLPC in competition with netbook systems will fail. Sooner or later, netbooks will cost less than the OLPC, while outperforming the OLPC, whether slimmed or not. My concern is that, even when offered with a non-Sugar interface, the OLPC __as a GNU/Linux system__ ( or as a Windows system !) will be non-competitive. Therefore I would rather have thought be given by those working on the OLPC to how it can be made to 'stand out' from other small systems, instead of thought being devoted to fit the OLPC into a "me too" mold. Let's not get sidetracked. > >> For those who think the OLPC *is* suited to >> the environments in which it is being deployed - let's work on developing >> OLPC-scale applications to assist 'the things people do' wherever such >> "computerization" could improve matters. > > Then what's your problem, man? :) My problem is that a number of people want to change the OLPC to improve the way it does things __that other systems already do__. If there are other systems that work (better) with "square pegs", why fashion the OLPC to be "square"? Think "round". mikus From rms at 1407.org Thu Jun 11 19:37:58 2009 From: rms at 1407.org (Rui Miguel Silva Seabra) Date: Thu, 11 Jun 2009 20:37:58 +0100 Subject: [OT] Test run of 2009/05/25 image In-Reply-To: <4A3144BC.7010803@bga.com> References: <4A3144BC.7010803@bga.com> Message-ID: <20090611193758.GF29225@roque.1407.org> On Thu, Jun 11, 2009 at 01:54:04PM -0400, Mikus Grinbergs wrote: >> Then what's your problem, man? :) > > My problem is that a number of people want to change the OLPC to improve > the way it does things __that other systems already do__. If there are > other systems that work (better) with "square pegs", why fashion the OLPC > to be "square"? Think "round". Which is why I think having a GNOME desktop on the OLPC XO is pointless. It should be either Sugar or something that allows it to be useful for other purposes. GNOME doesn't make it useful for other purposes. I think I'm definitly not being "square" as you imply, quite the opposite. Rui From echerlin at gmail.com Thu Jun 11 20:17:41 2009 From: echerlin at gmail.com (Edward Cherlin) Date: Thu, 11 Jun 2009 13:17:41 -0700 Subject: [OT] Test run of 2009/05/25 image In-Reply-To: <4A3144BC.7010803@bga.com> References: <4A3144BC.7010803@bga.com> Message-ID: On Thu, Jun 11, 2009 at 10:54 AM, Mikus Grinbergs wrote: >>> I think that people who focus on "slimming" the OLPC are missing the >>> point. ?What they end up with is a slow, small Linux system. >> >> Are you seriously considering the implications of your statement? >> >> If slimming ends up on a slow small GNU/Linux system, then *not* slimming >> ends up with a slower and bloated GNU/Linux system. > > Yes, I am seriously considering the implications of my statement. > > My motivation for starting this thread was to go on record as preferring > that people "add to" what they believe the OLPC can do well, rather than > "subtract from" what has been done so far because aspects of the OLPC's > behavior do not meet their expectations. I believe that you are addressing a different target market than OLPC does. Until we can get electricity and broadband wireless out to the hinterlands of every developing country, we have to go for low cost, low power, and maximum focus on children's needs. Let the rest of the industry satisfy everybody else's needs for now. Sugar runs on nine different Linux distributions, and can be run in emulation on almost any x86 computer running MacOS or Windows. We have the netbooks covered. For next year, we will have the XO-1.5 and XO-2, with much more storage and memory. Then we can have everything you are wishing for. I encourage you to work on getting ready, and I am happy for others to join you if they wish. You will be welcome to make your pitch. Just don't treat it as an exclusive either/or. It isn't. We need both approaches. > Given that 'netbooks' are already outselling the OLPC, Not in the OLPC target market, even including Venezuela and Brazil. > and that in my > opinion the development resources available to the producers of netbook > systems far exceed the resources of organizations producing the OLPC, I > think trying to sell the OLPC in competition with netbook systems will fail. That has never been, and is not now the plan. OLPC created the global 1-to-1 computing market, and the netbook manufacturers are competing with _us_ there. Their other target markets are of no concern to us. > ?Sooner or later, netbooks will cost less than the OLPC, while outperforming > the OLPC, whether slimmed or not. Why would you think so? OLPC can always sell at barely over cost, as a non-profit. No other company can gain a technology advantage worth bothering about. Where are their savings supposed to come from? It is possible that some company will dump product below cost in an attempt to build market share. It is possible that some manufacturer will take the global education market seriously, and develop a sufficiently rugged, sufficiently low-power alternative to the XO. It will still cost them as much to manufacture hardware as it does us. But even if you are right, It's An Education Project, not a laptop project. As long as Sugar is available for every educational laptop, I'm happy. > My concern is that, even when offered with a non-Sugar interface, > the OLPC __as a GNU/Linux system__ ( or as a Windows system !) will be > non-competitive. Why would we want to compete outside our target education market? > Therefore I would rather have thought be given by those > working on the OLPC to how it can be made to 'stand out' from other small > systems, instead of thought being devoted to fit the OLPC into a "me too" > mold. ?Let's not get sidetracked. You are asking the wrong questions. If you ask which is the biggest, fastest netbook, the XO isn't in it. If you ask which netbooks are designed for the target market, nothing but the XO is in it. We stand out far above the noise in our own niche. >>> For those who think the OLPC *is* suited to >>> the environments in which it is being deployed - let's work on developing >>> OLPC-scale applications to assist 'the things people do' wherever such >>> "computerization" could improve matters. Such as? >> Then what's your problem, man? :) > > My problem is that a number of people want to change the OLPC to improve the > way it does things __that other systems already do__. If there are other > systems that work (better) with "square pegs", why fashion the OLPC to be > "square"? ?Think "round". +1 > mikus > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > -- Silent Thunder (??/???????????????/????????????? ?) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) From dsd at laptop.org Fri Jun 12 13:43:36 2009 From: dsd at laptop.org (Daniel Drake) Date: Fri, 12 Jun 2009 14:43:36 +0100 Subject: Development of XO-1.5 software release started Message-ID: <1244814216.2217.34.camel@polyethylene> A small group of us have started working on the software release for the XO-1.5, based on Fedora 11. Some details here: http://wiki.laptop.org/go/F11_for_1.5 We're looking forward to engaging the community as much as possible, especially as we become more and more able to get test hardware out to developers and testers. Daniel From sverma at sfsu.edu Fri Jun 12 16:32:53 2009 From: sverma at sfsu.edu (Sameer Verma) Date: Fri, 12 Jun 2009 09:32:53 -0700 Subject: Development of XO-1.5 software release started In-Reply-To: <1244814216.2217.34.camel@polyethylene> References: <1244814216.2217.34.camel@polyethylene> Message-ID: <5fb387c70906120932j6e50af7cl46bb5f65539364ee@mail.gmail.com> On Fri, Jun 12, 2009 at 6:43 AM, Daniel Drake wrote: > A small group of us have started working on the software release for the > XO-1.5, based on Fedora 11. Some details here: > > http://wiki.laptop.org/go/F11_for_1.5 > > We're looking forward to engaging the community as much as possible, > especially as we become more and more able to get test hardware out to > developers and testers. > > Daniel > > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > We (olpc-sf) would definitely like to get our hands on a test board! Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ From sverma at sfsu.edu Fri Jun 12 16:32:53 2009 From: sverma at sfsu.edu (Sameer Verma) Date: Fri, 12 Jun 2009 09:32:53 -0700 Subject: Development of XO-1.5 software release started In-Reply-To: <1244814216.2217.34.camel@polyethylene> References: <1244814216.2217.34.camel@polyethylene> Message-ID: <5fb387c70906120932j6e50af7cl46bb5f65539364ee@mail.gmail.com> On Fri, Jun 12, 2009 at 6:43 AM, Daniel Drake wrote: > A small group of us have started working on the software release for the > XO-1.5, based on Fedora 11. Some details here: > > http://wiki.laptop.org/go/F11_for_1.5 > > We're looking forward to engaging the community as much as possible, > especially as we become more and more able to get test hardware out to > developers and testers. > > Daniel > > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > We (olpc-sf) would definitely like to get our hands on a test board! Sameer -- Dr. Sameer Verma, Ph.D. Associate Professor of Information Systems San Francisco State University San Francisco CA 94132 USA http://verma.sfsu.edu/ http://opensource.sfsu.edu/ From skierpage at gmail.com Fri Jun 12 23:36:37 2009 From: skierpage at gmail.com (S Page) Date: Fri, 12 Jun 2009 16:36:37 -0700 Subject: Development of XO-1.5 software release started In-Reply-To: <1244814216.2217.34.camel@polyethylene> References: <1244814216.2217.34.camel@polyethylene> Message-ID: <6509bebe0906121636vf9b480emda5cccd2e5ee3486@mail.gmail.com> On Fri, Jun 12, 2009 at 6:43 AM, Daniel Drake wrote: > A small group of us have started working on the software release for the > XO-1.5, based on Fedora 11. Some details here: > > http://wiki.laptop.org/go/F11_for_1.5 Is this the same 8.2.x software release described in http://wiki.laptop.org/go/XO-1.5 ? -- "We also expect the Gen 1.5 machines to ship with an OLPC 8.2.x software release, modified to support Gen 1.5's new hardware but otherwise unchanged from the current production software release and compatible with our current software in the field. " I.e. is "us" "we" ? :-) Bon voyage,, -- =S Page From cjb at laptop.org Fri Jun 12 23:55:48 2009 From: cjb at laptop.org (Chris Ball) Date: Fri, 12 Jun 2009 19:55:48 -0400 Subject: Development of XO-1.5 software release started In-Reply-To: <6509bebe0906121636vf9b480emda5cccd2e5ee3486@mail.gmail.com> (S. Page's message of "Fri, 12 Jun 2009 16:36:37 -0700") References: <1244814216.2217.34.camel@polyethylene> <6509bebe0906121636vf9b480emda5cccd2e5ee3486@mail.gmail.com> Message-ID: Hi, >> A small group of us have started working on the software release >> for the XO-1.5, based on Fedora 11. Some details here: >> >> http://wiki.laptop.org/go/F11_for_1.5 > Is this the same 8.2.x software release described in > http://wiki.laptop.org/go/XO-1.5 ? No, it's a change from that plan. I've updated the XO-1.5 page now, thanks. - Chris. -- Chris Ball From skierpage at gmail.com Sat Jun 13 06:38:55 2009 From: skierpage at gmail.com (S Page) Date: Fri, 12 Jun 2009 23:38:55 -0700 Subject: "Cannot find root file system!" with 2009-06-03 SoaS on XO-1 Message-ID: <6509bebe0906122338x5717ab12kc6db05d161c93bab@mail.gmail.com> I made a live USB for my XO-1 in Kubuntu 9.04. I downloaded http://people.sugarlabs.org/sdz/livecd-iso-to-disk.sh and the current SoaS-2 snapshot. I installed the package dependencies. I synthesized the overlapping instructions in http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Linux and http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC (the latter only documents Fedora) , using commands like sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --home-size-mb 160 --unencrypted-home Soas2-200906031834.iso /dev/sdc1 sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --unencrypted-home --noverify --skipcopy --xo --xo-no-home Soas2-200906031834.iso /dev/sdc1 I inserted this in my unlocked XO-1 running q2e41 firmware, and got: ... starting udev4 creating devices ------------------------ WARNING: cannot find root file system! ------------------------ Create symlink /dev/root and then exit this shell to continue the boot sequence. bash: no job control in this shell bash-4-0# scsi 0:0:0:0: Direct-Access SanDisk Cruzer Pattern 7.01 PQ: 0 ANSI: 0 CCS sd 0:0:0:0: [sda] (disk size stuff...) (... more sda mesages) This rings a bell, I think it happened to me months ago with Rawhide-XO. It sounds like http://dev.sugarlabs.org/ticket/421 , marked Closed. I looked through the comments in there and https://fedorahosted.org/liveusb-creator/ticket/53 and didn't see anything that helped: the overlay UUID matches, reinserting USB and/or exiting shell doesn't help, etc. Also, can anyone point to a reasonable explanation of what goes on during a LiveUSB boot? initrd, syslinux.cfg, squash-fs, overlays... This stuff clearly isn't bulletproof but is cloaked in obscurity-fu. Thanks, -- =S Page From sdaly.be at gmail.com Sat Jun 13 11:41:33 2009 From: sdaly.be at gmail.com (Sean DALY) Date: Sat, 13 Jun 2009 13:41:33 +0200 Subject: "Cannot find root file system!" with 2009-06-03 SoaS on XO-1 In-Reply-To: <6509bebe0906122338x5717ab12kc6db05d161c93bab@mail.gmail.com> References: <6509bebe0906122338x5717ab12kc6db05d161c93bab@mail.gmail.com> Message-ID: <378b2b050906130441v558041fet5ca40f0f1f9f0672@mail.gmail.com> identical message when trying to boot a Mac Mini: http://lists.sugarlabs.org/archive/sugar-devel/2009-May/014519.html a friend counselled me recently to "create a symlink to the ramdisk", but I'm not sure how to do that. Sean On Sat, Jun 13, 2009 at 8:38 AM, S Page wrote: > I made a live USB for my XO-1 in Kubuntu 9.04. ?I downloaded > http://people.sugarlabs.org/sdz/livecd-iso-to-disk.sh and the current > SoaS-2 snapshot. I installed the package dependencies. ?I synthesized > the overlapping instructions in > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Linux and > http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC (the > latter only documents Fedora) , using commands like > > sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 --home-size-mb 160 > --unencrypted-home Soas2-200906031834.iso /dev/sdc1 > sudo ./livecd-iso-to-disk.sh --overlay-size-mb 300 ?--unencrypted-home > --noverify --skipcopy --xo --xo-no-home Soas2-200906031834.iso > /dev/sdc1 > > I inserted this in my unlocked XO-1 running q2e41 firmware, and got: > > ... > starting udev4 > creating devices > > ------------------------ > WARNING: cannot find root file system! > ------------------------ > > Create symlink /dev/root and then exit this shell to continue > the boot sequence. > > bash: no job control in this shell > bash-4-0# > > scsi 0:0:0:0: Direct-Access ? SanDisk ? Cruzer Pattern 7.01 PQ: 0 ANSI: 0 CCS > sd 0:0:0:0: [sda] (disk size stuff...) > (... more sda mesages) > > This rings a bell, I think it happened to me months ago with Rawhide-XO. > It sounds like http://dev.sugarlabs.org/ticket/421 , marked Closed. ?I > looked through the comments in there and > https://fedorahosted.org/liveusb-creator/ticket/53 and didn't see > anything that helped: the overlay UUID matches, reinserting USB and/or > exiting shell doesn't help, etc. > > > Also, can anyone point to a reasonable explanation of what goes on > during a LiveUSB boot? ?initrd, syslinux.cfg, squash-fs, overlays... > This stuff clearly isn't bulletproof but is cloaked in obscurity-fu. > > Thanks, > -- > =S Page > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > From todd at webpath.net Sat Jun 13 13:41:54 2009 From: todd at webpath.net (Todd Robinson) Date: Sat, 13 Jun 2009 09:41:54 -0400 Subject: usb-creator = live F11 for the XO? In-Reply-To: <4A2D3DAD.7000608@webpath.net> References: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> <4A2D3DAD.7000608@webpath.net> Message-ID: <4A33ACA2.3000907@webpath.net> Just a heads-up (or maybe everyone already knows but me?) Although I didn't mention it in the article (http://on-disk.com/cms/index.php?wiki=Review-Fedora_11_page1) because I haven't had a chance to test it, the live usb-creator also creates the olpc.fth file in a boot directory on the USB flash drive. I'm hoping to get some time early this coming week to see if it creates a usable SD card for the OLPC using a USB SDHC card reader. Thank you, Todd From skierpage at gmail.com Sat Jun 13 22:58:59 2009 From: skierpage at gmail.com (S Page) Date: Sat, 13 Jun 2009 15:58:59 -0700 Subject: usb-creator = live F11 for the XO? In-Reply-To: <4A33ACA2.3000907@webpath.net> References: <46a038f90906080155i2863c368taae90c5a4e1fa4f2@mail.gmail.com> <4A2D3DAD.7000608@webpath.net> <4A33ACA2.3000907@webpath.net> Message-ID: <6509bebe0906131558i7bc1f1f9ga150bf78d915589f@mail.gmail.com> On Sat, Jun 13, 2009 at 6:41 AM, Todd Robinson wrote: > Although I didn't mention it in the article > (http://on-disk.com/cms/index.php?wiki=Review-Fedora_11_page1) because I > haven't had a chance to test it, the live usb-creator also creates the > olpc.fth file in a boot directory on the USB flash drive. > > I'm hoping to get some time early this coming week to see if it creates a > usable SD card for the OLPC using a USB SDHC card reader. It worked for me under Windows a month ago with an 8GB SD card, so I added it to http://wiki.laptop.org/go/Rawhide-XO I also assume that the http://people.sugarlabs.org/sdz/livecd-iso-to-disk.sh script and some combination of the instructions in http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Linux and http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC would work for F11 builds. I think LiveUSB/livecd is a much better way to get a bootable flash drive than the `zcat 20090217.bootable.gz > /dev/sdX` that http://dev.laptop.org/~cjb/rawhide-xo/ still recommends , which * Leaves the following GBs of space on your card inaccessible. * Degrades the flash device (see wmb comment on Rawhide-XO page). * And if you get the device letter wrong, trashes your partition table and turns your Windows NTFS partition into an unbootable mess that TestDisk can read fine but any filesystem that pays attention to ACLs thinks is inaccessible by every user in the known universe, thus forcing you into Kubuntu full-time despite its quirks. [*] -- =S Page [*] Not that I'd be so stupid as to type the wrong letter or anything like that 8-) From stickster at gmail.com Mon Jun 15 23:19:10 2009 From: stickster at gmail.com (Paul W. Frields) Date: Mon, 15 Jun 2009 19:19:10 -0400 Subject: Default 32-bit x86 arch for Fedora 12 Message-ID: <20090615231910.GC9780@localhost.localdomain> I thought this might be of interest to builders/developers here: http://www.redhat.com/archives/fedora-devel-list/2009-June/msg01199.html Of note: Proposed change for F12 would mean the CPU in the OLPC-1.0 hardware would explicitly not be supported beyond F11. After talking to a few folks, my understanding is this isn't a big surprise, but I wanted to make sure we were explicitly calling it out for this group's information and, if needed, input. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug From martin.langhoff at gmail.com Tue Jun 16 01:06:19 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 16 Jun 2009 03:06:19 +0200 Subject: Development of XO-1.5 software release started In-Reply-To: <1244814216.2217.34.camel@polyethylene> References: <1244814216.2217.34.camel@polyethylene> Message-ID: <46a038f90906151806y3a0e5dddi5a709f3263a43b79@mail.gmail.com> On Fri, Jun 12, 2009 at 3:43 PM, Daniel Drake wrote: > A small group of us have started working on the software release for the > XO-1.5, based on Fedora 11. Some details here: > > http://wiki.laptop.org/go/F11_for_1.5 Interesting about dracut. Will that be for both 'normal / jailbroken' and 'secure' machines? Does it mean the next major OS release will bring sanity to the deep and narrow ring of hell that is our initrd? cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From cjb at laptop.org Tue Jun 16 01:07:39 2009 From: cjb at laptop.org (Chris Ball) Date: Mon, 15 Jun 2009 21:07:39 -0400 Subject: Development of XO-1.5 software release started In-Reply-To: <46a038f90906151806y3a0e5dddi5a709f3263a43b79@mail.gmail.com> (Martin Langhoff's message of "Tue, 16 Jun 2009 03:06:19 +0200") References: <1244814216.2217.34.camel@polyethylene> <46a038f90906151806y3a0e5dddi5a709f3263a43b79@mail.gmail.com> Message-ID: Hi, > Interesting about dracut. Will that be for both 'normal / > jailbroken' and 'secure' machines? Does it mean the next major > OS release will bring sanity to the deep and narrow ring of > hell that is our initrd? Yup. -- Chris Ball From martin.langhoff at gmail.com Tue Jun 16 07:52:28 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 16 Jun 2009 09:52:28 +0200 Subject: Development of XO-1.5 software release started In-Reply-To: References: <1244814216.2217.34.camel@polyethylene> <46a038f90906151806y3a0e5dddi5a709f3263a43b79@mail.gmail.com> Message-ID: <46a038f90906160052g748aedf8p11bcefc00e7c1a82@mail.gmail.com> On Tue, Jun 16, 2009 at 3:07 AM, Chris Ball wrote: > Yup. Niiiiice. m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From sebastian at when.com Wed Jun 17 07:37:19 2009 From: sebastian at when.com (Sebastian Dziallas) Date: Wed, 17 Jun 2009 09:37:19 +0200 Subject: Show Must Go On - SoaS for the XO-1 Message-ID: <4A389D2F.4010100@when.com> Hi everybody, I'm very pleased to announce the first early preview of a new generation of SoaS XO-1 images. Those consist not only of the latest and greatest Sugar bits, but also a F11 base system and a special OLPC kernel based on 2.6.30. This means now that even power management actually works out of the box. There are some other points, for example the mostly working keyboard keys. But this is really just a preview! You'll notice only very few activities in your home view, which is due to a mistake in our config files. You'd be able to symlink the folders from /usr/share/sugar/honey to ~/Activities, though. This is a known issue, but if you come across others, please let us know! Finally, I'd like to take the chance to thank all the people for their tremendous work, especially Martin Dengler and all the folks at OLPC! Now how can you get that? Just download the following two files: http://download.sugarlabs.org/soas/xoimages/devxo-1.crc http://download.sugarlabs.org/soas/xoimages/devxo-1.img Put them on a USB key or a SD card, plug them into your XO and execute: copy-nand u:\devxo-1.img or copy-nand sd:\devxo-1.img Note that you'll need to have an unlocked XO and the latest firmware! So. Happy hacking and let us know what you think! :) --Sebastian From skierpage at gmail.com Wed Jun 17 08:28:58 2009 From: skierpage at gmail.com (S Page) Date: Wed, 17 Jun 2009 01:28:58 -0700 Subject: [Sugar-devel] Show Must Go On - SoaS for the XO-1 In-Reply-To: <4A389D2F.4010100@when.com> References: <4A389D2F.4010100@when.com> Message-ID: <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> On Wed, Jun 17, 2009 at 12:37 AM, Sebastian Dziallas wrote: > I'm very pleased to announce the first early preview of a new generation > of SoaS XO-1 images. Excellent news, thanks! > Put them on a USB key or a SD card, plug them into your XO ... Yes! > ... and execute: > > copy-nand u:\devxo-1.img or copy-nand sd:\devxo-1.img Nooo, I want to keep my working 8.2.1 in NAND. Can I simply boot my XO from the USB or SD card? I've got an 8GB SD card, I would think that a 2 GB root, 1 GB additional storage, 1 GB swap would perform well. Is there an xo-to-disk.sh script similar to the various transformation scripts described in http://dev.laptop.org/~cjb/rawhide-xo/ ? If not, is http://wiki.laptop.org/go/How_to_backup_your_XO the best way to save my precious 8.2.1 image? It seems build engineers go to a a lot of effort to create multiple ginormous downloads in .img/.usb/.iso/.bootable.gz formats when they're 99% the same files laid out in different file system(s) with appropriate boot, config, and partition info. Could some day a tool like LiveUSB Creator download only updated files from the net and create whatever image,read-only CD, or bootable/writable USB the user wants? That may be ambitious, but it seems much like what Linux graphical installers do. -- =S Page From martin at martindengler.com Wed Jun 17 09:12:10 2009 From: martin at martindengler.com (Martin Dengler) Date: Wed, 17 Jun 2009 10:12:10 +0100 Subject: [Sugar-devel] Show Must Go On - SoaS for the XO-1 In-Reply-To: <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> References: <4A389D2F.4010100@when.com> <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> Message-ID: <20090617091210.GU28624@ops-13.xades.com> On Wed, Jun 17, 2009 at 01:28:58AM -0700, S Page wrote: > On Wed, Jun 17, 2009 at 12:37 AM, Sebastian Dziallas wrote: > > > I'm very pleased to announce the first early preview of a new generation > > of SoaS XO-1 images. > Excellent news, thanks! > > > Put them on a USB key or a SD card, plug them into your XO ... > Yes! > > > ... and execute: > > > > copy-nand u:\devxo-1.img or copy-nand sd:\devxo-1.img > > Nooo, I want to keep my working 8.2.1 in NAND. Can I simply boot my > XO from the USB or SD card? We're working on creating a bootable image, but in the meantime you're describing what livecd-iso-to-disk has always been for. You just don't like the .iso you're being given, because it isn't configured for the XO-1. I'd suggest you ask sdz to make the .iso that he used to create the .img file. > Is there an xo-to-disk.sh script similar to the various transformation > scripts described in http://dev.laptop.org/~cjb/rawhide-xo/ ? http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/Installation/OLPC > If not, is http://wiki.laptop.org/go/How_to_backup_your_XO the best > way to save my precious 8.2.1 image? Yes. Man, that's a lot of preamble for: 1. Get to "ok" 2. Type "save-nand u:\my-nand.img" or "save-nand sd:\my-nand.img". > It seems build engineers go to a a lot of effort to create multiple > ginormous downloads in .img/.usb/.iso/.bootable.gz formats when > they're 99% the same files laid out in different file system(s) with > appropriate boot, config, and partition info. Could some day a tool > like LiveUSB Creator download only updated files from the net and > create whatever image,read-only CD, or bootable/writable USB the user > wants? That may be ambitious, but it seems much like what Linux > graphical installers do. It's because those engineers have been whined at about because many people lack experience typing text at a prompt, or the messages that result from mistakes there. I've seen questions on this list that result from people not understanding that a virtual machine is, err, like another machine (without have the same file system as the host machine). So you can see the definiciencies of both sides, which is an admirable position to be in. But yeah, there's a reason we want to build bootable images like fedora-xo for the XO-1, so that we can just tell people: 1. Download ginormous .bootable.gz file in its 1G, 2G, 4G size appropriate to your removable drive 2. Type "dd if= of=" 3. Stick the removable drive in the appropriate XO orifice and reboot Spend a few seconds contemplating how easy those steps can be. Now contemplate how many ways people might screw up each step (mis-type the removable device letter? assume that dd just adds some stuff to their USB stick and get upset when it overwrites their thesis?). > =S Page Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin.langhoff at gmail.com Wed Jun 17 10:24:51 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 17 Jun 2009 12:24:51 +0200 Subject: [IAEP] [Sugar-devel] Show Must Go On - SoaS for the XO-1 In-Reply-To: <20090617091210.GU28624@ops-13.xades.com> References: <4A389D2F.4010100@when.com> <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> <20090617091210.GU28624@ops-13.xades.com> Message-ID: <46a038f90906170324g47d18ddcy66e2a37b17f234d0@mail.gmail.com> On Wed, Jun 17, 2009 at 11:12 AM, Martin Dengler wrote: >> It seems build engineers go to a a lot of effort to create multiple >> ginormous downloads in .img/.usb/.iso/.bootable.gz formats when >> they're 99% the same files laid out in different file system(s) with >> appropriate boot, config, and partition info. ?Could some day a tool >> like LiveUSB Creator download only updated files from the net ... > It's because those engineers have been whined at about because many Actually, a tool that's most of this smartly, it's called jigdo, and _nobody uses it_. Even projects that do all the setup work and document how end users can use it see little or no usage. It has a commandline. A GUI. Works on Windows. Fetches only the updates. Delivers fluffy bunnies. And almost nobody uses it :-p m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin at martindengler.com Wed Jun 17 10:47:38 2009 From: martin at martindengler.com (Martin Dengler) Date: Wed, 17 Jun 2009 11:47:38 +0100 Subject: [IAEP] [Sugar-devel] Show Must Go On - SoaS for the XO-1 In-Reply-To: <46a038f90906170324g47d18ddcy66e2a37b17f234d0@mail.gmail.com> References: <4A389D2F.4010100@when.com> <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> <20090617091210.GU28624@ops-13.xades.com> <46a038f90906170324g47d18ddcy66e2a37b17f234d0@mail.gmail.com> Message-ID: <20090617104738.GA28624@ops-13.xades.com> On Wed, Jun 17, 2009 at 12:24:51PM +0200, Martin Langhoff wrote: > On Wed, Jun 17, 2009 at 11:12 AM, Martin > Dengler wrote: > >> It seems build engineers go to a a lot of effort to create multiple > >> ginormous downloads in .img/.usb/.iso/.bootable.gz formats when > >> they're 99% the same files laid out in different file system(s) with > >> appropriate boot, config, and partition info. ?Could some day a tool > >> like LiveUSB Creator download only updated files from the net > ... > > It's because those engineers have been whined at about because many > > Actually, a tool that's most of this smartly, it's called jigdo, and > _nobody uses it_. Even projects that do all the setup work and > document how end users can use it see little or no usage. Reading the docs, I think that jidgo will allow the user to download (say) a .iso and a .img (NAND) file by downloading the files that are contained in them and then re-assembling the .iso and .img files? In this case it's something we/anyone can implement, though I'm not sure it's going to serve a large portion of the target audience (I imagine they'll want only one of the options). > m -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From martin.langhoff at gmail.com Wed Jun 17 11:42:31 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 17 Jun 2009 13:42:31 +0200 Subject: [IAEP] [Sugar-devel] Show Must Go On - SoaS for the XO-1 In-Reply-To: <20090617104738.GA28624@ops-13.xades.com> References: <4A389D2F.4010100@when.com> <6509bebe0906170128w6d1987ffu58ac65e6205a8248@mail.gmail.com> <20090617091210.GU28624@ops-13.xades.com> <46a038f90906170324g47d18ddcy66e2a37b17f234d0@mail.gmail.com> <20090617104738.GA28624@ops-13.xades.com> Message-ID: <46a038f90906170442n54fa6cedv3532f87b279c612e@mail.gmail.com> On Wed, Jun 17, 2009 at 12:47 PM, Martin Dengler wrote: > Reading the docs, I think that jidgo will allow the user to download > (say) a .iso and a .img (NAND) file by downloading the files that are > contained in them and then re-assembling the .iso and .img files? You might need to track the iso and img as separate things. But updates to the newer iso or img are just a delta. If iso or NAND-formatted img files were rsync-friendly, this wouldn't be needed. In any case, we can do the technical part alright. We're good at this. The social part is more of a puzzle. Jigdo adds a step and a tool to the process and for some reason that puts people off. The snarky analysis would be: - repeated large downloads are annoying enough to complain - but not enough to use a new tool which is blatantly incomplete. The real thing is that using jigdo depends on jigdo being part of the everyday geek arsenal. It's not, and that's a huge barrier. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From sdaly.be at gmail.com Wed Jun 17 14:13:56 2009 From: sdaly.be at gmail.com (Sean DALY) Date: Wed, 17 Jun 2009 16:13:56 +0200 Subject: [OT] Test run of 2009/05/25 image In-Reply-To: References: <4A3144BC.7010803@bga.com> Message-ID: <378b2b050906170713l2c2c9616kdbbc16251a7adce7@mail.gmail.com> >> Therefore I would rather have thought be given by those >> working on the OLPC to how it can be made to 'stand out' from other small >> systems, instead of thought being devoted to fit the OLPC into a "me too" >> mold. Let's not get sidetracked. > You are asking the wrong questions. If you ask which is the biggest, > fastest netbook, the XO isn't in it. If you ask which netbooks are > designed for the target market, nothing but the XO is in it. We stand > out far above the noise in our own niche. The OLPC XO-1 is far and away the standout in small systems for kids. I mean, my four-year-old saw it and said "Look - a computer for children!". No other machine available matches the XO's sunlight-readable screen and native mesh networking. None are as rugged as the XO-1, nor as easy to repair, nor as inexpensive (with the possible exception of the EeePC 701 which is lacking in the other departments especially screen size). However, there are indeed netbooks designed for the K-6 education 1:1 target market: * The Intel Classmate series (Gen1/Gen2 "Clamshell" with 7" and 8.9" screens, Gen3 "Convertible" with 8.9" swivel touchscreen). Usually runs with locked-down Easybits Magic Desktop over Windows XP, however Canonical has just announced Ubuntu Remix support for the series and is with Intel and Microsoft in Miami today and Cairo next week (http://lists.sugarlabs.org/archive/marketing/2009-June/001489.html). Intel licenses to local builders on favorable terms, who rebrand the machines; there are two dozen such partners worldwide now, the latest being Archos in France (http://lists.sugarlabs.org/archive/marketing/2009-June/001452.html). Intel positions the Classmate for all markets and relies on the local partners to find the sweet spot for governments and education ministries. Microsoft follows Intel into local deals and tacks Office on where it can. * The Dell Latitude 2100 education netbook (http://lists.sugarlabs.org/archive/marketing/2009-May/001026.html), with Ubuntu standard (WinXP optional) and backed by a specific education support structure. Rollout is in the USA with a $4000 classroom rack charger/router which can update/backup the netbooks while they are charging at night. The netbook has a tattletale LED bar in the lid to inform teachers what's happening (student network activity, or has completed a task - it's programmable). Also, education solutions designed to leverage existing PC infrastructure in school computer labs (slightly older student positioning): * NComputing (http://lists.sugarlabs.org/archive/marketing/2009-June/001243.html) * Microsoft Multipoint (http://lists.sugarlabs.org/archive/marketing/2009-May/001169.html) Finally, netbooks designed for the age group at home, with an emphasis on parental controls and filters: * The Disney Asus Netpal netbook (http://lists.sugarlabs.org/archive/marketing/2009-June/001486.html) runs a locked-down kids' Disney-themed desktop over Windows XP and will be widely distributed at Toys 'R' Us and the Disney Store. I boot Sugar on a Stick on a Gen1 7" Classmate, a pair of Asus EeePCs, an Acer Aspire One, a Dell Inspiron Mini 10, a Dell Latitude 2100 education netbook, and under VirtualBox, on a Mac Mini in fullscreen. Sugar has the potential to leverage the hardware offers above, and given the lack of interest by governments in an Windows XP-equipped XO to date, could potentially displace Microsoft in the K-6 education markets of developed countries too, which would be great for education (and great for Fedora). In this space, it's Sugar versus Magic Desktop and other proprietary products, and in my view Sugar is far superior. Ideas I've encountered for non-education uses of XOs are usually NGOs needing rugged hardware for e.g. surveying or medical applications. Sean Sugar Labs Marketing Coordinator From echerlin at gmail.com Wed Jun 17 14:27:14 2009 From: echerlin at gmail.com (Edward Cherlin) Date: Wed, 17 Jun 2009 07:27:14 -0700 Subject: [OT] Test run of 2009/05/25 image In-Reply-To: <378b2b050906170713l2c2c9616kdbbc16251a7adce7@mail.gmail.com> References: <4A3144BC.7010803@bga.com> <378b2b050906170713l2c2c9616kdbbc16251a7adce7@mail.gmail.com> Message-ID: On Wed, Jun 17, 2009 at 7:13 AM, Sean DALY wrote: >>> Therefore I would rather have thought be given by those >>> working on the OLPC to how it can be made to 'stand out' from other small >>> systems, instead of thought being devoted to fit the OLPC into a "me too" >>> mold. ?Let's not get sidetracked. > >> You are asking the wrong questions. If you ask which is the biggest, >> fastest netbook, the XO isn't in it. If you ask which netbooks are >> designed for the target market, nothing but the XO is in it. We stand >> out far above the noise in our own niche. Sorry, Britishism. (I lived there for a year.) "Nothing else is in it" doesn't mean that there are no competitors, but that they are not actually competitive. > The OLPC XO-1 is far and away the standout in small systems for kids. > I mean, my four-year-old saw it and said "Look - a computer for > children!". No other machine available matches the XO's > sunlight-readable screen and native mesh networking. None are as > rugged as the XO-1, nor as easy to repair, nor as inexpensive (with > the possible exception of the EeePC 701 which is lacking in the other > departments especially screen size). > > However, there are indeed netbooks designed for the K-6 education 1:1 > target market: They fail in comparison with the XO on power, ruggedness, appropriate software, and other measures. > * The Intel Classmate series (Gen1/Gen2 "Clamshell" with 7" and 8.9" > screens, Gen3 "Convertible" with 8.9" swivel touchscreen). Usually > runs with locked-down Easybits Magic Desktop over Windows XP, however > Canonical has just announced Ubuntu Remix support for the series and > is with Intel and Microsoft in Miami today and Cairo next week > (http://lists.sugarlabs.org/archive/marketing/2009-June/001489.html). > Intel licenses to local builders on favorable terms, who rebrand the > machines; there are two dozen such partners worldwide now, the latest > being Archos in France > (http://lists.sugarlabs.org/archive/marketing/2009-June/001452.html). > Intel positions the Classmate for all markets and relies on the local > partners to find the sweet spot for governments and education > ministries. Microsoft follows Intel into local deals and tacks Office > on where it can. > > * The Dell Latitude 2100 education netbook > (http://lists.sugarlabs.org/archive/marketing/2009-May/001026.html), > with Ubuntu standard (WinXP optional) and backed by a specific > education support structure. Rollout is in the USA with a $4000 > classroom rack charger/router which can update/backup the netbooks > while they are charging at night. The netbook has a tattletale LED bar > in the lid to inform teachers what's happening (student network > activity, or has completed a task - it's programmable). > > > Also, education solutions designed to leverage existing PC > infrastructure in school computer labs (slightly older student > positioning): > > * NComputing (http://lists.sugarlabs.org/archive/marketing/2009-June/001243.html) > > * Microsoft Multipoint > (http://lists.sugarlabs.org/archive/marketing/2009-May/001169.html) > > > Finally, netbooks designed for the age group at home, with an emphasis > on parental controls and filters: > > * The Disney Asus Netpal netbook > (http://lists.sugarlabs.org/archive/marketing/2009-June/001486.html) > runs a locked-down kids' Disney-themed desktop over Windows XP and > will be widely distributed at Toys 'R' Us and the Disney Store. > > > > I boot Sugar on a Stick on a Gen1 7" Classmate, a pair of Asus EeePCs, > an Acer Aspire One, a Dell Inspiron Mini 10, a Dell Latitude 2100 > education netbook, and under VirtualBox, on a Mac Mini in fullscreen. > > Sugar has the potential to leverage the hardware offers above, and > given the lack of interest by governments in an Windows XP-equipped XO > to date, could potentially displace Microsoft in the K-6 education > markets of developed countries too, which would be great for education > (and great for Fedora). In this space, it's Sugar versus Magic Desktop > and other proprietary products, and in my view Sugar is far superior. > > Ideas I've encountered for non-education uses of XOs are usually NGOs > needing rugged hardware for e.g. surveying or medical applications. > > Sean > Sugar Labs Marketing Coordinator > -- Silent Thunder (??/???????????????/????????????? ?) is my name And Children are my nation. The Cosmos is my dwelling place, The Truth my destination. http://earthtreasury.org/worknet (Edward Mokurai Cherlin) From mikus at bga.com Wed Jun 17 15:03:25 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 17 Jun 2009 11:03:25 -0400 Subject: Show Must Go On - SoaS for the XO-1 Message-ID: <4A3905BD.4070804@bga.com> Thank you very much, Sebastian and everyone. Because my Ubuntu kernel is not "new" enough, the 'livecd-iso-to-xo' script fails on me - so I had to run previous Soas2 builds from an USB stick. Now I can run a current SoaS build from the XO-1 nand itself. Thanks. - It is nice to have olpc-kbdshim and olpc-powerd in this build. Both my ethernet and my SD card were accessed correctly after I allowed the XO-1 to suspend (my testing was limited). And the screen went dark after I let the XO sit -- now I don't have to "shut the lid" when I leave the XO powered on overnight (and I don't want the XO to be lighting up the otherwise dark room). [By the way, I need olpc-kbdshim to let me to scroll the screen (e.g., in Terminal) incrementally. All too often, if I click within the scrollbar, the effect is "multiplied" - instead of scrolling one page, the screen happens to scroll *many* pages.] - The default fonts used by this build are really *tiny*. I knew how to change to a bigger font in Terminal - but I did not know how to change to a bigger font for the Sugar labels, etc. - The "list of installed rpms" that comes with this build lists a couple of packages as having a back level (e.g., libabiword). The result is that when I ran 'yum upgrade', yum fetched those packages for updating, then told me those updated versions were already installed. Now a request -- would someone please look at the system problems that affect multimedia -- I can launch 'Speak' but I can not hear any of its sound output; I can launch 'Record' but I can't see on the screen what the XO-1 camera is picking up. Thanks for a nice build, mikus From mikus at bga.com Wed Jun 17 21:38:53 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 17 Jun 2009 17:38:53 -0400 Subject: browse on devxo-1 Message-ID: <4A39626D.9010900@bga.com> Tried launching Browse (108) on devxo-1. Failed. The error message (on webactivity.py line 35) - "ImportError: No module named gnome". I compared Soas2-20090614 (on which Browse launched) against devxo-1 (on which Browse did not launch). No difference in the source files in the Browse.activity subtree. In neither build version could I find a separate module named 'gnome.py' -- my guess is that this is a 'built-in' somewhere (kernel?). The 'import gnome' line was added by sugarlabs/ticket/456. I have no idea why that line worked on Soas-20090624, but not on devxo-1. mikus From mikus at bga.com Wed Jun 17 21:56:54 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 17 Jun 2009 17:56:54 -0400 Subject: olpc-powerd on soas devxo-1 Message-ID: <4A3966A6.6060007@bga.com> This is the first F11-based build to come with this module included. I'm going to have to play with the thresholds -- it acts too soon for my liking. Was doing a 100MB+ rsync to my XO-1. The screen dimmed, but the data transfer continued; then the 'power' light started blinking, but the data transfer stopped (though unlike how 'suspend' worked in Joyride, here the external ethernet adapter did not get powered off). When I awakened the XO (by pressing the key), it took quite a bit of cogitation by the XO before the data transfer resumed -- but resume it did. Still, would be nice to inhibit (even if manually) 'suspending' while lengthy data transfers take place. mikus From pgf at laptop.org Thu Jun 18 00:45:32 2009 From: pgf at laptop.org (Paul Fox) Date: Wed, 17 Jun 2009 20:45:32 -0400 Subject: olpc-powerd on soas devxo-1 In-Reply-To: <4A3966A6.6060007@bga.com> (sfid-20090617_185705_993741_93F00876) References: <4A3966A6.6060007@bga.com> (sfid-20090617_185705_993741_93F00876) Message-ID: <16408.1245285932@foxharp.boston.ma.us> hi mikus -- mikus wrote: > This is the first F11-based build to come with this module included. to be honest, i'm almost as surprised to see it in a release as you are. no one tells me anything. :-) > I'm going to have to play with the thresholds -- it acts too soon > for my liking. be sure to read the section entitled "Configuration:" near the top of /usr/sbin/powerd. that's the sole documentation. online here: http://dev.laptop.org/git/users/pgf/powerd/tree/powerd > Was doing a 100MB+ rsync to my XO-1. The screen dimmed, but the > data transfer continued; then the 'power' light started blinking, > but the data transfer stopped (though unlike how 'suspend' worked in > Joyride, here the external ethernet adapter did not get powered > off). i was with you until you got to the "though unlike..." part: it's physically impossible for power to be maintained to an external USB device when the XO is suspended. > When I awakened the XO (by pressing the key), it took > quite a bit of cogitation by the XO before the data transfer resumed > -- but resume it did. the other end of your transfer was busy setting longer and longer timeouts while trying to get your XO to start responding again. it takes a bit for the two sides to get back in sync, much the same as if you'd pulled the cable for a while, then plugged it back in. > > Still, would be nice to inhibit (even if > manually) 'suspending' while lengthy data transfers take place. see the section (again, in /usr/sbin/powerd) called "Inhibiting sleep". you can either a) create a new file named after a running process (which will disable suspend for as long as both the file and the process exist) or b) touch a "special" file periodically (more frequently than you've configured the XO to go to sleep), and when you stop touching the file, sleep will no longer be inhibited. the two methods are equivalent, but one may be more convenient than the other for some programs. for manual inhibit, i'd recommend: touch /var/run/powerd-inhibit-suspend/1 then remove it when suspending is okay again. if you're doing it in a shell script, try: touch /var/run/powerd-inhibit-suspend/$$ and the inhibit will end when your script exits. btw, if you want the latest versions of olpc-kbdshim and olpc-powerd, use "yum update olpc-kbdshim" for the former, and until powerd gets reviewed and hopefully accepted, fetch the latest from http://dev.laptop.org/~pgf/rpms .) paul =--------------------- paul fox, pgf at laptop.org From martin at martindengler.com Fri Jun 19 00:56:53 2009 From: martin at martindengler.com (Martin Dengler) Date: Fri, 19 Jun 2009 01:56:53 +0100 Subject: Show Must Go On - SoaS for the XO-1 In-Reply-To: <4A3905BD.4070804@bga.com> References: <4A3905BD.4070804@bga.com> Message-ID: <20090619005653.GC25785@ops-13.xades.com> On Wed, Jun 17, 2009 at 11:03:25AM -0400, Mikus Grinbergs wrote: > [By the way, I need olpc-kbdshim to let me to scroll the screen > (e.g., in Terminal) incrementally. All too often, if I click > within the scrollbar, the effect is "multiplied" - instead of > scrolling one page, the screen happens to scroll *many* pages.] Has this always happened on F11 builds? > - The default fonts used by this build are really *tiny*. I knew > how to change to a bigger font in Terminal - but I did not know > how to change to a bigger font for the Sugar labels, etc. dsd's done a lot of research into this, and there has been some discussion today on IRC. It should be fixable soon. > - The "list of installed rpms" that comes with this build lists a > couple of packages as having a back level (e.g., libabiword). > The result is that when I ran 'yum upgrade', yum fetched those > packages for updating, then told me those updated versions were > already installed. Anybody know how this can happen? > Now a request -- would someone please look at the system problems that > affect multimedia -- I can launch 'Speak' but I can not hear any of its > sound output; I can launch 'Record' but I can't see on the screen what > the XO-1 camera is picking up. These are really important bugs to look into. > Thanks for a nice build, mikus Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mikus at bga.com Mon Jun 22 06:12:20 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Mon, 22 Jun 2009 02:12:20 -0400 Subject: breakthrough - got sound on XO-1 with F11 Message-ID: <4A3F20C4.9060805@bga.com> FYI - Had an XO-1 with build rawhide-xo 20090528 (and F12? kernel). Ran a giant 'yum upgrade' to bring it up to current system level. When I checked it out, I was able to hear sound from an application that used the fluendo mp3 driver. [Speak also produced sound - but other applications I have did not. Am currently tied up elsewhere - don't have time to look into why some have sound and others don't.] I do *not* know how come sound started working. I checked, and now I have sound (with those two applications, but not with others) on an XO-1 with build soas devxo-1 (it also has been upgraded to current F11 system level). I'm positive that several days ago sound was not working for me. It might have been the system upgrades I did -- or it might have been my own customizations (which I'm continuously tinkering with). I also checked against the Soas2 builds (including 20090621) - they are up-to-current-F11 level (and have my current customization), but they don't produce sound for me. Thank you, developers for F11 on XO. mikus From dsd at laptop.org Tue Jun 23 18:01:43 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 23 Jun 2009 19:01:43 +0100 Subject: update mechanism for new releases Message-ID: <1245780103.2190.72.camel@polyethylene> Hi, We have a bug open here which is a difficult question, in my opinion: http://dev.laptop.org/ticket/9349 For the upcoming XO-1.5 software build (which will hopefully make it onto XO-1 in the near future), do we want to ship olpc-update or use standard Fedora technologies? My unconclusive thoughts and questions: olpc-update has some features which aren't available elsewhere, such as the ability to switch between 2 OS builds installed on the same disk. However, I've never seen or heard of this being used in the field. olpc-update is a "deployment quality" system in that it has covered everything - not only from being an updater, it has olpc-update-query which implements logic to figure out when to ask for updates and where to ask for them. It's accompanied by the theft deterrence protocol and 3 different server-side implementations of that. It's been implemented in OLPC deployments. olpc-update creates a huge mass of hardlinks on disk, one for every file on the main OS. It then rsyncs in the updated files on a copy-on-write basis. Therefore you end up with a hell of a lot of hardlinks, and 2 complete copies of every file that has changed. (this means it is not great for situations when a lot of files have changed, e.g. changing between major Fedora releases) olpc-update presents challenges for deployments that customise their images. Namely, to produce a build that it is possible to olpc-update to involves quite a bit of hassle (inserting security keys into the firmware of each XO, setting up an OATS server, etc). We did manage to figure this out in Paraguay (thanks to the internet connection, since it wouldn't be safe to put the OATS server in the schools) and I improved some tools accordingly. We've switched to dracut for our initramfs, meaning that the initramfs-level stuff for the olpc-update system needs to be reimplemented. Basically we have to wrangle with the strange /versions filesystem layout and "frob" the /versions/current symlink if the user is switching between versions. I have reimplemented this logic in a dracut module but it is completely untested. The option for using "Standard Fedora technologies" as far as I am aware is to basically use "yum update" in a fashion somehow suited for deployments. Before F11, this would have meant a lot of downloading as each RPM update was downloaded in full even if only a little bit changed. As of F11, Fedora is now joining the "only download the bits that change" movement with yum-presto and deltarpms: http://lwn.net/Articles/329484/ The deltarpm description on that lwn article leaves a little to be desired -- it wouldn't work with big packages (is the quoted 200mb the compressed or uncompressed size?), the reconstruction from deltas is a CPU intensive task and we have a slow CPU, and it's all done in memory and we don't have a huge amount of memory especially on XO-1. olpc-update has an overhead of about 5 minutes of checksumming files. Even though olpc-update isn't great for doing big distro updates (because of storing 2 copies of changed files, in this case almost all of them), it worked in those situations. I've never attempted an RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that work out for regular Fedora users? "yum update" always seems to use a surprising amount of bandwidth, redownloading entire package databases just to see if anything new is available. olpc-update was much more efficient in this respect, sending only a 128-byte hash of the filesystem contents file to the OATS server. For rpms, is there a more efficient alternative for updates-checking in situations where there is only going to be e.g. 1 update per month? "yum update" has historically not worked very well on the XO. It hits OOM, it fills up yum's cache and then aborts, it gets confused between i586 and i686, etc. We would have to tweak yum's behaviour quite heavily.. I don't think we want an rpm cache, or for it to keep the .rpm files at all. It introduces new questions of security, signing, etc. Deployments will want to sign their rpm updates that they push out, so we now need a mechanism for getting that specific RPM signing public key onto all the laptops in a deployment so that they can trust the updates server. We had this nailed down for olpc-update: deployments can insert "local" public keys into the manufacturing through keyjector firmwares for existing laptops, and Quanta can now manufacture laptops with these keys already in place for future orders. olpc-update and the bitfrost code used these keys to verify updates. For the XO-1 possibility it raises the question of how existing laptops could be migrated to this new system, without losing their user data. Using "yum update" would be a large benefit of sharing technologies with other communities and not having to maintain our own systems and tools. However olpc-update would be easier in the short term because all the components have been implemented and deployed, and there aren't really any open questions. Any other thoughts/opinions one way or the other? Daniel From dsd at laptop.org Tue Jun 23 18:48:26 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 23 Jun 2009 19:48:26 +0100 Subject: rpm vs xo & activity updates Message-ID: <1245782906.2190.100.camel@polyethylene> Just a quick summary of a discussion and a decision that we reached on IRC, which will hold at least for now with our XO-1.5 software builds. Further input is welcome, although this is at risk of starting another huge discussion... Question: In the early XO-1.5 OS builds right now, we have a mix of RPM-based sugar activity packages, and .xo files unzipped in /home/olpc/Activities. Do we want to change? - It would be a little unfortunate to ignore the hard work of those who have been actively packaging the activities within Fedora. - rpm-based packages cannot be updated with Sugar's updater utility, which is the primary way for updating activities right now. There is no upgrade path for activities installed by rpms (without updating the whole OS, which is another open question) - We could somehow hack the updater to work with rpms, i.e. if it found a newer .xo bundle it could unzip it over the top of the rpm-installed files in /usr/share/sugar/activities, but this is nasty and would raise many issues - One flaw in the existing OLPC OS releases for XO-1 is that there's no way for deployments to push automatic activity updates, because olpc-update doesn't touch /home and the activity updater always has to be invoked by the user. - This flaw would go away with rpm-based updates, because whatever "global" OS updater we choose would include these updates. - Which leads onto the possibility that *all* activities could be shipped as RPMs, the sugar control panel activity updater could be deleted, and then this problem is solved -- but that's quite a change - The easy option is to do what we've done before: ship activities entirely as .xo bundles in /home/olpc/Activities - We're going to go with this option for now, because it's quick and easy and it's what we're already doing. - There is certainly room for improvement in future, but finding development time in the short term may be a bit tricky... or perhaps we will be able to raise community interest in making or implementing a plan for improvement... :) Daniel From bochecha at fedoraproject.org Tue Jun 23 19:10:10 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 23 Jun 2009 21:10:10 +0200 Subject: Fwd: update mechanism for new releases In-Reply-To: <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> Message-ID: <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> Oops... My reply went only to Daniel, not to the lists :-/ ---------- Forwarded message ---------- From: Mathieu Bridon (bochecha) Date: Tue, Jun 23, 2009 at 20:33 Subject: Re: update mechanism for new releases To: Daniel Drake > Even though olpc-update isn't great for doing big distro updates > (because of storing 2 copies of changed files, in this case almost all > of them), it worked in those situations. I've never attempted an > RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that > work out for regular Fedora users? Lot's of people will tell you that it works fine. However, this is not a supported path for upgrade. Users should use Pre-Upgrade instead. See: => http://fedoraproject.org/wiki/Category:PreUpgrade => http://fedoraproject.org/wiki/Interviews/PreUpgrade > "yum update" always seems to use a surprising amount of bandwidth, > redownloading entire package databases just to see if anything new is > available. olpc-update was much more efficient in this respect, sending > only a 128-byte hash of the filesystem contents file to the OATS server. > For rpms, is there a more efficient alternative for updates-checking in > situations where there is only going to be e.g. 1 update per month? You can configure yum to not update its cache that often with the ? metadata_expire ? directive in /etc/yum.conf > "yum update" has historically not worked very well on the XO. It hits > OOM, it fills up yum's cache and then aborts, it gets confused between > i586 and i686, etc. RPM has seen a lot of improvements in speed and memory consumption lately. My XO (a build from the latest G1G1 in Europe that I never updated yet) has RPM 4.4.2. Panu Matilain has just posted about that, comparing the performances of RPM from 4.4.2 (Fedora 9) to 4.7 (Fedora 11). Perfect timing :) => http://laiskiainen.org/blog/?p=19 Yum has also been improved. Not sure those improvements would be enough, but I bet the situation in Fedora 11 is already much better than it was in the previous OLPC builds from Fedora 9. > We would have to tweak yum's behaviour quite heavily.. I don't think we > want an rpm cache, or for it to keep the .rpm files at all. You can use the ? keepcache ? directive in /etc/yum.conf which AFAIU aims exactly at that. From ? man yum.conf ? : ? ? ?keepcache ? ? ? ? ? ? ?Either ?1? or ?0?. Determines whether or not yum keeps the cache ? ? ? ? ? ? ?of ?headers and packages after successful installation. ?Default ? ? ? ? ? ? ?is ?1? (keep files) What other customizations are you expecting ? > It introduces new questions of security, signing, etc. Deployments will > want to sign their rpm updates that they push out, so we now need a > mechanism for getting that specific RPM signing public key onto all the > laptops in a deployment so that they can trust the updates server. > We had this nailed down for olpc-update: deployments can insert "local" > public keys into the manufacturing through keyjector firmwares for > existing laptops, and Quanta can now manufacture laptops with these keys > already in place for future orders. olpc-update and the bitfrost code > used these keys to verify updates. Yum will ask the user if he wants to import the key and trust it on first use. Wouldn't that be enough for signing keys ? Couldn't Quanta manufacture the laptops with those GPG keys bundled too ? > For the XO-1 possibility it raises the question of how existing laptops > could be migrated to this new system, without losing their user data. Backup with a School Server ? Best regards, ---------- Mathieu Bridon (bochecha) From bochecha at fedoraproject.org Tue Jun 23 19:52:02 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 23 Jun 2009 21:52:02 +0200 Subject: rpm vs xo & activity updates In-Reply-To: <1245782906.2190.100.camel@polyethylene> References: <1245782906.2190.100.camel@polyethylene> Message-ID: <2d319b780906231252q35f6422lbc79ebcb9e343269@mail.gmail.com> > - rpm-based packages cannot be updated with Sugar's updater utility, > which is the primary way for updating activities right now. There is no > upgrade path for activities installed by rpms (without updating the > whole OS, which is another open question) You can update only one activity with: # yum update sugar- > - There is certainly room for improvement in future, but finding > development time in the short term may be a bit tricky... or perhaps we > will be able to raise community interest in making or implementing a > plan for improvement... :) I proposed the following some times ago [1], but no one responded. I would have loved for someone actually knowledgeable (i.e. not some random guy like me throwing out ideas he can't even implement) to explain how this would be a terribly bad idea :) Here it is again. ======================================== > A). If all Activities were distributed as .xo bundles through the Sugar > platform (such as access to activities.sugarlabs.org), distro packagers > would only have to worry about keeping the core Sugar and it's dependancies > up-to date, not all the faster changing stuff. > > B). If all Activities were distributed through distros, then Activity > authors would only need to worry about getting their source bundles to > distro packagers in the most friendly way. Sugar core would need some distro > agnostic or configurable user interface for yup/rpm/aptitude > installing/removing; but would not need to maintain code behind something > like activities.sugarlabs.org. Well, one could see the problem as follows : 1. activities installed via .xo bundles take precedence over activities installed via the OS package manager (yum here), just like config files in your home directory take precedence over the system ones 2. use PackageKit for the distro agnostic part. On Fedora for example, PackageKit comes with a yum backend. On Debian, it would come with an apt backend. You can then have your own graphical package manager in Sugar using the PackageKit APIs, no matter what the underlying OS is (given that there is a PackageKit backend for this OS). 3. as a bonus, it would be nice to see if PackageKit can handle multiple backends on a same system. This way, you could also have a ? .xo ? backend for PackageKit that would simply take .xo bundles from activities.sugarlabs.org (just like yum takes .rpm packages from the repositories). This way, in the same graphical interface, you can both install/update/remove the system packages and the .xo bundles Now, I have no idea if that's even doable with PackageKit (the double backend part), but that could be a lead worth chasing. After that, if a distro chooses to package the activities, that's great, because you have some kind of a ? stable fallback set ? on which the user can fallback if he played too much with the .xo bundles to have newer stuff. But he still can do it if he wants to try out activities not available as RPMs, or if he wants to play with the latest update that didn't make it to the distro repositories yet. And if later on Sugar decides to stop one packaging effort or the other, just disable one of the PackageKit backends and use the other. ======================================== Regards, [1] https://www.redhat.com/archives/fedora-olpc-list/2009-June/msg00005.html ---------- Mathieu Bridon (bochecha) From martin.langhoff at gmail.com Tue Jun 23 20:07:42 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 23 Jun 2009 22:07:42 +0200 Subject: update mechanism for new releases In-Reply-To: <1245780103.2190.72.camel@polyethylene> References: <1245780103.2190.72.camel@polyethylene> Message-ID: <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> On Tue, Jun 23, 2009 at 8:01 PM, Daniel Drake wrote: > Any other thoughts/opinions one way or the other? My (also inconclusive) thoughts on this. I dislike using a bespoke update method profoundly and discussed this topic at length with Scott. The main point, where olpc-update wins without a shadow of a doubt, is failure-friendliness. Assuming a fail-safe filesystem, olpc-update can be interrupted (hard) at any point, might take N runs to complete. And will only switch to the 'new' image once it's completed in an atomic operation. RPM is unfortunately a disaster in this space. If an rpm transaction fails, there are no sane ways to recover it. On XO-1 a full OS update transaction with rpm will take a very long time, so it's highly likely that it will be interrupted. RPM and yum hackers treat this as an intractable problem. There may be ways to make it a bit less bad (dpkg seems to handle recovery quite a bit better, but surely will have unrecoverable scenarios too) but it is a long hard road, and the shadow of a significant % of failed upgrades remains. This is, IMO, the actual showstopper. If we had a fs that could handle snapshotting, then we could snapshot the system before starting the RPM transaction, and have recovery hooks in the boot partition or in initrd. There's been discussion on fedora-devel about hooking up yum with btrfs transactions A few other notes -- for completeness: - Upstream has not historically supported yum-based upgrades, only anaconda upgrades. Yum OS upgrades are a relatively new (and risky) thing. We could have an 'anaconda boot' partition to handle upgrades without external media. - Disk space requirements for olpc-update vs yum/rpm are probably similar, and I suspect that during the upgrade rpm transaction the footprint is larger for the rpm methods. We could teach olpc-update to jettison the old image as soon as the new one boots successfully... - olpc-update completely sidesteps %pre and %post scripts -- this is potentially a problem. - olpc-update offers downgrades, but our software at higher layers doesn't support this. The Journal format upgrade broke downgrades in the last OS upgrade. Sugar 0.84 has another Journal format change, probably with a similar upgrade-only path. - deltarpm-style tools are of little benefit for a whole OS upgrade. as there is little or no overlap between releases. Where there is overlap, then olpc-update's hardlinking strategy is also a win of similar proportions. Deltarpm-style tools usually force you to keep around the original rpm as well. - olpc-update-query needs to be changed to retry more aggressively once it has received an "upgrade now" message from the OATS. It's in my TODO list... hth, martin -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From dsd at laptop.org Tue Jun 23 20:09:14 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 23 Jun 2009 21:09:14 +0100 Subject: Fwd: update mechanism for new releases In-Reply-To: <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> Message-ID: <1245787754.2190.115.camel@polyethylene> On Tue, 2009-06-23 at 21:10 +0200, Mathieu Bridon (bochecha) wrote: > > Even though olpc-update isn't great for doing big distro updates > > (because of storing 2 copies of changed files, in this case almost all > > of them), it worked in those situations. I've never attempted an > > RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that > > work out for regular Fedora users? > > Lot's of people will tell you that it works fine. However, this is not > a supported path for upgrade. Users should use Pre-Upgrade instead. > See: > => http://fedoraproject.org/wiki/Category:PreUpgrade > => http://fedoraproject.org/wiki/Interviews/PreUpgrade Interesting. So "yum update" does not sound like an advisable method for making large changes. I don't know enough about anaconda to say whether preupgrade would fit into our design. It's not something we're using in our builds at the moment. > You can configure yum to not update its cache that often with the ? > metadata_expire ? directive in /etc/yum.conf So, if the cache has not expired, yum will not even go online and check for new packages? > RPM has seen a lot of improvements in speed and memory consumption > lately. My XO (a build from the latest G1G1 in Europe that I never > updated yet) has RPM 4.4.2. Panu Matilain has just posted about that, > comparing the performances of RPM from 4.4.2 (Fedora 9) to 4.7 (Fedora > 11). Perfect timing :) > => http://laiskiainen.org/blog/?p=19 > > Yum has also been improved. Not sure those improvements would be > enough, but I bet the situation in Fedora 11 is already much better > than it was in the previous OLPC builds from Fedora 9. Good to hear, I hope you're right :) > > We would have to tweak yum's behaviour quite heavily.. I don't think we > > want an rpm cache, or for it to keep the .rpm files at all. > > You can use the ? keepcache ? directive in /etc/yum.conf which AFAIU > aims exactly at that. From ? man yum.conf ? : > keepcache > Either ?1? or ?0?. Determines whether or not yum keeps the cache > of headers and packages after successful installation. Default > is ?1? (keep files) Great, thanks for the pointer. > What other customizations are you expecting ? I'm not really sure. > Yum will ask the user if he wants to import the key and trust it on > first use. Wouldn't that be enough for signing keys ? Couldn't Quanta > manufacture the laptops with those GPG keys bundled too ? >From my experience in the field, it's totally inappropriate to present those kinds of questions to our users (young children). The child's response will be random. We'd have to make that "yes" response for that particular key be part of the build. As for Quanta, they can tweak the manufacturing data very heavily but they don't customise the image -- they need it provided as-is. In the past, OLPC has made software images for deployments. Now we're moving towards a model where the deployments build them using OLPC's tools, or at least they customise "base" images that OLPC have made. But it's tricky as the tools are young, the processes are a bit tricky, and deployments don't usually have a huge amount of technical resources. It's possible, but is an additional complication that needs consideration. > > For the XO-1 possibility it raises the question of how existing laptops > > could be migrated to this new system, without losing their user data. > > Backup with a School Server ? It's a possibility, but also leaves a lot of work to be done. Neither XS or sugar has a full-journal restore interface. Not all deployments have XSes either. It seems like that we should be able to do the upgrade entirely locally if enough disk space is available. Daniel From martin.langhoff at gmail.com Tue Jun 23 20:12:29 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 23 Jun 2009 22:12:29 +0200 Subject: update mechanism for new releases In-Reply-To: <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> Message-ID: <46a038f90906231312p5f57c41fs2bf7a8d54fcdbfcc@mail.gmail.com> On Tue, Jun 23, 2009 at 9:10 PM, Mathieu Bridon (bochecha) wrote: > RPM has seen a lot of improvements in speed and memory consumption Are there any improvements on recovery of unexpectedly failed transactions, such as OOM, kernel oops or hard power-off? >> For the XO-1 possibility it raises the question of how existing laptops >> could be migrated to this new system, without losing their user data. > > Backup with a School Server ? For an RPM-driven upgrade, that wouldn't be needed as it's "in place". The rest of my reply, well, was exactly what dsd posted a few seconds ago -- there's a bit of work to do to complete the "backup->upgrade->restore" cycle perfectly, and it doesn't help XS-less environments. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From dsd at laptop.org Tue Jun 23 20:13:18 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 23 Jun 2009 21:13:18 +0100 Subject: rpm vs xo & activity updates In-Reply-To: <2d319b780906231252q35f6422lbc79ebcb9e343269@mail.gmail.com> References: <1245782906.2190.100.camel@polyethylene> <2d319b780906231252q35f6422lbc79ebcb9e343269@mail.gmail.com> Message-ID: <1245787998.2190.119.camel@polyethylene> On Tue, 2009-06-23 at 21:52 +0200, Mathieu Bridon (bochecha) wrote: > > - rpm-based packages cannot be updated with Sugar's updater utility, > > which is the primary way for updating activities right now. There is no > > upgrade path for activities installed by rpms (without updating the > > whole OS, which is another open question) > > You can update only one activity with: > # yum update sugar- This is not a suitable interface for our users. We need something easier, or something automatic. And any work in this direction would probably be bolting onto the sugar activity updater, making it really confusing with 2 backends or something, and sort-of calls out for a rethink of the system as a whole. Speaking of which... > I proposed the following some times ago [1], but no one responded. I > would have loved for someone actually knowledgeable (i.e. not some > random guy like me throwing out ideas he can't even implement) to > explain how this would be a terribly bad idea :) snip.. I love these ideas. I would even go as far as to remove .xo support altogether as there are a number of flaws in that format now that sugar is hugely increasing in scope. Daniel From bochecha at fedoraproject.org Tue Jun 23 20:19:02 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 23 Jun 2009 22:19:02 +0200 Subject: update mechanism for new releases In-Reply-To: <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> Message-ID: <2d319b780906231319nc84a89fma37b2ef02ecaada5@mail.gmail.com> > The main point, where olpc-update wins without a shadow of a doubt, is > failure-friendliness. Assuming a fail-safe filesystem, olpc-update can > be interrupted (hard) at any point, might take N runs to complete. And > will only switch to the 'new' image once it's completed in an atomic > operation. > > RPM is unfortunately a disaster in this space. If an rpm transaction > fails, there are no sane ways to recover it. On XO-1 a full OS update > transaction with rpm ?will take a very long time, so it's highly > likely that it will be interrupted. RPM and yum hackers treat this as > an intractable problem. Have you tried the ? yum-complete-transaction ? tool ? It comes from the yum-utils package and might interest you :) > This is, IMO, the actual showstopper. If we had a fs that could handle > snapshotting, then we could snapshot the system before starting the > RPM transaction, and have recovery hooks in the boot partition or in > initrd. There's been discussion on fedora-devel about hooking up yum > with btrfs transactions I probably am way over my knowledge, but what about LVM snapshots ? > ?- olpc-update offers downgrades, but our software at higher layers > doesn't support this. The Journal format upgrade broke downgrades in > the last OS upgrade. Sugar 0.84 has another Journal format change, > probably with a similar upgrade-only path. Yum/RPM also have downgrades. See the ? yum-allow-downgrade ? plugin and the ? --oldpackage ? RPM option. I'm don't know if those cover all the use cases you might have for downgrades though. ---------- Mathieu Bridon (bochecha) From martin.langhoff at gmail.com Tue Jun 23 20:26:06 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 23 Jun 2009 22:26:06 +0200 Subject: update mechanism for new releases In-Reply-To: <2d319b780906231319nc84a89fma37b2ef02ecaada5@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> <2d319b780906231319nc84a89fma37b2ef02ecaada5@mail.gmail.com> Message-ID: <46a038f90906231326w42bfcfbcr8b72477ba25d015b@mail.gmail.com> On Tue, Jun 23, 2009 at 10:19 PM, Mathieu Bridon (bochecha) wrote: > Have you tried the ? yum-complete-transaction ? tool ? It comes from > the yum-utils package and might interest you :) Discussed it a bit in fedora-devel. I didn't get the impression that it's a very deep fix, but I might be wrong. How comprehensive is it? > Yum/RPM also have downgrades. See the ? yum-allow-downgrade ? plugin > and the ? --oldpackage ? RPM option. it's not exactly the same. olpc-update will let you have 2 full OSs in the same partition and pick one at boot time. You could ping-pong between F9 and F11 at wish, as long as they work with the same kernel. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From martin.langhoff at gmail.com Tue Jun 23 20:31:49 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 23 Jun 2009 22:31:49 +0200 Subject: update mechanism for new releases In-Reply-To: <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> Message-ID: <46a038f90906231331u64f30e85o867a825cca59fd96@mail.gmail.com> On Tue, Jun 23, 2009 at 10:07 PM, Martin Langhoff wrote: > A few other notes ?-- for completeness: - olpc-update depends on a tricky bit of code at boot time that keeps "OS install" 2 trees in different subdirs, and picks which one to run. The OS install is kept pristine with hardlinks and various mountpoints are layered on top, making it a jury-rigged COW setup. This has various interesting aspects, one of them is that we could use rpm's --root option to run a similar "shadow" OS install for resilient upgrades. %pre and %post scripts could be tricky to handle. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From sundaram at fedoraproject.org Tue Jun 23 20:31:25 2009 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 24 Jun 2009 02:01:25 +0530 Subject: update mechanism for new releases In-Reply-To: <46a038f90906231312p5f57c41fs2bf7a8d54fcdbfcc@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> <46a038f90906231312p5f57c41fs2bf7a8d54fcdbfcc@mail.gmail.com> Message-ID: <4A413B9D.1050409@fedoraproject.org> On 06/24/2009 01:42 AM, Martin Langhoff wrote: > On Tue, Jun 23, 2009 at 9:10 PM, Mathieu Bridon > (bochecha) wrote: >> RPM has seen a lot of improvements in speed and memory consumption > > Are there any improvements on recovery of unexpectedly failed > transactions, such as OOM, kernel oops or hard power-off? I think such questions can be better answered in the RPM upstream mailing list. It would be good for you to bring your concerns there. http://lists.rpm.org/mailman/listinfo/rpm-maint I am sure the RPM developers would be very interested in them. It is not true that RPM/Yum developers treat mid transaction failures as insolvable problems. Rahul From abo at stacken.kth.se Tue Jun 23 20:35:31 2009 From: abo at stacken.kth.se (=?ISO-8859-1?Q?Alexander_Bostr=F6m?=) Date: Tue, 23 Jun 2009 22:35:31 +0200 Subject: update mechanism for new releases In-Reply-To: <1245780103.2190.72.camel@polyethylene> References: <1245780103.2190.72.camel@polyethylene> Message-ID: <4A413C93.2090109@stacken.kth.se> Den 2009-06-23 20:01, Daniel Drake skrev: > Even though olpc-update isn't great for doing big distro updates > (because of storing 2 copies of changed files, in this case almost all > of them), it worked in those situations. I've never attempted an > RPM-based update from e.g. Fedora 10 to Fedora 11. Preupgrade+Anaconda would be better. The big question with yum updates and Anaconda upgrades is how to do it safely. The system must remain bootable at all times. It would be neat (perhaps required?) if Anaconda upgrades would do a transaction-type upgrade, where you have the option to roll back if something goes wrong in the middle. People keep asking for that for regular yum updates, but that's not really possible since you can't roll back a generic running system. (How do you roll back the OS without also rolling back /var/lib/mysql and /home at the same time? No thanks.) With Anaconda, you know nothing else is running alongside the upgrade so if you have a snapshot mechanism for the filesystem or block device then maybe it would be possible... > "yum update" has historically not worked very well on the XO. It hits > OOM, it fills up yum's cache and then aborts, it gets confused between > i586 and i686, etc. This option would certainly requires lots of testing to make sure it works well. > It introduces new questions of security, signing, etc. Deployments will > want to sign their rpm updates that they push out, so we now need a Maybe olpc-update can be extended to manage /etc/pki/rpm-gpg/ and rpm --import? > For the XO-1 possibility it raises the question of how existing laptops > could be migrated to this new system, without losing their user data. Use olpc-update to push a new image that contains preupgrade? /abo From martin.langhoff at gmail.com Tue Jun 23 20:41:43 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Tue, 23 Jun 2009 22:41:43 +0200 Subject: update mechanism for new releases In-Reply-To: References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> <46a038f90906231312p5f57c41fs2bf7a8d54fcdbfcc@mail.gmail.com> <4A413B9D.1050409@fedoraproject.org> Message-ID: <46a038f90906231341w397c7eabwb0cb44f19a142d32@mail.gmail.com> On Tue, Jun 23, 2009 at 10:33 PM, Seth Vidal wrote: > they're not insolvable - they are just very very very hard. :-) At the end of the day, if the OS doesn't give you atomic multi-file transactions, and your %pre/%post scripts aren't also written perfectly atomically, I would say that it _is_ impossible. In any case, are there reasons to believe that behaviour in rpm has improved (in F11) in the face of a powerloss in the middle of a transaction? If we start doing OS upgrades and removing power at random points, what chance does rpm of recover/resume? It is an admittedly hard question. cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From gary at garycmartin.com Tue Jun 23 21:10:02 2009 From: gary at garycmartin.com (Gary C Martin) Date: Tue, 23 Jun 2009 22:10:02 +0100 Subject: rpm vs xo & activity updates In-Reply-To: <1245787998.2190.119.camel@polyethylene> References: <1245782906.2190.100.camel@polyethylene> <2d319b780906231252q35f6422lbc79ebcb9e343269@mail.gmail.com> <1245787998.2190.119.camel@polyethylene> Message-ID: <79A1D05A-67E2-4C1F-8EA7-5E943124A298@garycmartin.com> Hi Daniel, On 23 Jun 2009, at 21:13, Daniel Drake wrote: >> I proposed the following some times ago [1], but no one responded. I >> would have loved for someone actually knowledgeable (i.e. not some >> random guy like me throwing out ideas he can't even implement) to >> explain how this would be a terribly bad idea :) > > snip.. > I love these ideas. I would even go as far as to remove .xo support > altogether as there are a number of flaws in that format now that > sugar > is hugely increasing in scope. Can you expand on this idea? My main complaint with what I've seen from previous non-OLPC mechanisms is that root/super-user privileges are required. We can wrap any old CLI in a shiny, pretty, GUI. But it needs to work in a sane, safe way without passwords for small human beings. Regards, --Gary From bochecha at fedoraproject.org Tue Jun 23 21:17:42 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Tue, 23 Jun 2009 23:17:42 +0200 Subject: rpm vs xo & activity updates In-Reply-To: <79A1D05A-67E2-4C1F-8EA7-5E943124A298@garycmartin.com> References: <1245782906.2190.100.camel@polyethylene> <2d319b780906231252q35f6422lbc79ebcb9e343269@mail.gmail.com> <1245787998.2190.119.camel@polyethylene> <79A1D05A-67E2-4C1F-8EA7-5E943124A298@garycmartin.com> Message-ID: <2d319b780906231417g50224ac5ka73ea296fe53c85@mail.gmail.com> > Can you expand on this idea? My main complaint with what I've seen from > previous non-OLPC mechanisms is that root/super-user privileges are > required. We can wrap any old CLI in a shiny, pretty, GUI. But it needs to > work in a sane, safe way without passwords for small human beings. If I'm not mistaken, PackageKit uses PolicyKit. And PolicyKit can be configured to either: - ask for the root password each time - ask for the root password and keep permission for the active session - ask for the root password and keep permission indefinitely - same 3 above cases but with the user's own password instead - always grants permission to the user - always deny permission to the user All those possibilities can be configured for a lot of different actions needing administration permissions, among which is ? update my system ? or ? install new software ?. :-) You can look at how it works by running the ? /usr/bin/polkit-gnome-authorization ? tool on a Gnome desktop. ---------- Mathieu Bridon (bochecha) From martin.langhoff at gmail.com Wed Jun 24 06:17:07 2009 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 24 Jun 2009 08:17:07 +0200 Subject: update mechanism for new releases In-Reply-To: <1245780103.2190.72.camel@polyethylene> References: <1245780103.2190.72.camel@polyethylene> Message-ID: <46a038f90906232317r5d3f7e7ap839962f195519e0b@mail.gmail.com> On Tue, Jun 23, 2009 at 8:01 PM, Daniel Drake wrote: > For the upcoming XO-1.5 software build (which will hopefully make it > onto XO-1 in the near future), do we want to ship olpc-update or use > standard Fedora technologies? Due to the fedora lists' draconian 'reply-to' settings, the thread has now moved to fedora-devel. Just mentioning it so that people (who may not be in both lists) can follow it. (And cross your fingers, maybe one day fedora lists get their reply-to fixed ;-) ) cheers, m -- martin.langhoff at gmail.com martin at laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff From bochecha at fedoraproject.org Wed Jun 24 08:44:44 2009 From: bochecha at fedoraproject.org (Mathieu Bridon (bochecha)) Date: Wed, 24 Jun 2009 10:44:44 +0200 Subject: update mechanism for new releases In-Reply-To: <46a038f90906232317r5d3f7e7ap839962f195519e0b@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <46a038f90906232317r5d3f7e7ap839962f195519e0b@mail.gmail.com> Message-ID: <2d319b780906240144s22ded358vc8833e02c5627b5@mail.gmail.com> >> For the upcoming XO-1.5 software build (which will hopefully make it >> onto XO-1 in the near future), do we want to ship olpc-update or use >> standard Fedora technologies? > > Due to the fedora lists' draconian 'reply-to' settings, the thread has > now moved to fedora-devel. > > Just mentioning it so that people (who may not be in both lists) can follow it. > > (And cross your fingers, maybe one day fedora lists get their reply-to > fixed ;-) ) Well, actually, that's *my* fault... I first replied only to Daniel, letting the lists out. Then I wanted to correct my mistakes and transferred my answer to the lists. I saw "devel" and so I sent to fedora-devel instead of devel at laptop.org :-/ So there might be issues in the "reply-to" settings of the Fedora lists, but the problem actually came from "reply-to" issues in my GMail :) Sorry about that (even though this actuallly lead to some interesting talk) ---------- Mathieu Bridon (bochecha) From pbrobinson at gmail.com Wed Jun 24 09:30:52 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 10:30:52 +0100 Subject: rpm vs xo & activity updates In-Reply-To: <1245782906.2190.100.camel@polyethylene> References: <1245782906.2190.100.camel@polyethylene> Message-ID: <5256d0b0906240230n26adf10fgf393f4f50fc017bd@mail.gmail.com> > Just a quick summary of a discussion and a decision that we reached on > IRC, which will hold at least for now with our XO-1.5 software builds. > Further input is welcome, although this is at risk of starting another > huge discussion... > > Question: In the early XO-1.5 OS builds right now, we have a mix of > RPM-based sugar activity packages, and .xo files unzipped > in /home/olpc/Activities. Do we want to change? > > - It would be a little unfortunate to ignore the hard work of those who > have been actively packaging the activities within Fedora. > > - rpm-based packages cannot be updated with Sugar's updater utility, > which is the primary way for updating activities right now. There is no > upgrade path for activities installed by rpms (without updating the > whole OS, which is another open question) > - We could somehow hack the updater to work with rpms, i.e. if it found > a newer .xo bundle it could unzip it over the top of the rpm-installed > files in /usr/share/sugar/activities, but this is nasty and would raise > many issues > > - One flaw in the existing OLPC OS releases for XO-1 is that there's no > way for deployments to push automatic activity updates, because > olpc-update doesn't touch /home and the activity updater always has to > be invoked by the user. > - This flaw would go away with rpm-based updates, because whatever > "global" OS updater we choose would include these updates. > - Which leads onto the possibility that *all* activities could be > shipped as RPMs, the sugar control panel activity updater could be > deleted, and then this problem is solved -- but that's quite a change > > - The easy option is to do what we've done before: ship activities > entirely as .xo bundles in /home/olpc/Activities > - We're going to go with this option for now, because it's quick and > easy and it's what we're already doing. > - There is certainly room for improvement in future, but finding > development time in the short term may be a bit tricky... or perhaps we > will be able to raise community interest in making or implementing a > plan for improvement... :) If you moved to rpms you have a sugar repo for activites. Then using PackageKit you could explicitly just update using that repo hence not having to update the whole OS. You can then also weight the repos dependent on whether you wanted OS Activities or the other repo to take precedence, add in local school repos for local content updates etc. The other advantage of that would be for the likes of debxo where they can use the apt beckend for package kit so each distro doesn't need to reinvent the wheel. RPM has also seen some massive improvements in both speed and memory usage in the F-9 -> F-11 timeframe [2] as well which would help. >From the development perspective PackageKit has all the python bindings etc so that should help speed things over doing it from the ground up. >From the global update side of things you could then use spacewalk [1] on the school server which can be used to manage both OS and Activities updates. It would also solve the issue if various Activities need binary components which I believe some have had. Peter [1] http://www.redhat.com/spacewalk/ [2] http://laiskiainen.org/blog/?p=19 From pbrobinson at gmail.com Wed Jun 24 10:05:20 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 11:05:20 +0100 Subject: update mechanism for new releases In-Reply-To: <1245780103.2190.72.camel@polyethylene> References: <1245780103.2190.72.camel@polyethylene> Message-ID: <5256d0b0906240305m5058b8eeu984d22cd7e890864@mail.gmail.com> > We have a bug open here which is a difficult question, in my opinion: > http://dev.laptop.org/ticket/9349 > > For the upcoming XO-1.5 software build (which will hopefully make it > onto XO-1 in the near future), do we want to ship olpc-update or use > standard Fedora technologies? > > > My unconclusive thoughts and questions: > > > olpc-update has some features which aren't available elsewhere, such as > the ability to switch between 2 OS builds installed on the same disk. > However, I've never seen or heard of this being used in the field. > > olpc-update is a "deployment quality" system in that it has covered > everything - not only from being an updater, it has olpc-update-query > which implements logic to figure out when to ask for updates and where > to ask for them. It's accompanied by the theft deterrence protocol and 3 > different server-side implementations of that. It's been implemented in > OLPC deployments. > > olpc-update creates a huge mass of hardlinks on disk, one for every file > on the main OS. It then rsyncs in the updated files on a copy-on-write > basis. Therefore you end up with a hell of a lot of hardlinks, and 2 > complete copies of every file that has changed. (this means it is not > great for situations when a lot of files have changed, e.g. changing > between major Fedora releases) > > olpc-update presents challenges for deployments that customise their > images. Namely, to produce a build that it is possible to olpc-update to > involves quite a bit of hassle (inserting security keys into the > firmware of each XO, setting up an OATS server, etc). We did manage to > figure this out in Paraguay (thanks to the internet connection, since it > wouldn't be safe to put the OATS server in the schools) and I improved > some tools accordingly. > > We've switched to dracut for our initramfs, meaning that the > initramfs-level stuff for the olpc-update system needs to be > reimplemented. Basically we have to wrangle with the strange /versions > filesystem layout and "frob" the /versions/current symlink if the user > is switching between versions. I have reimplemented this logic in a > dracut module but it is completely untested. > > > > The option for using "Standard Fedora technologies" as far as I am aware > is to basically use "yum update" in a fashion somehow suited for > deployments. > > Before F11, this would have meant a lot of downloading as each RPM > update was downloaded in full even if only a little bit changed. As of > F11, Fedora is now joining the "only download the bits that change" > movement with yum-presto and deltarpms: http://lwn.net/Articles/329484/ > > The deltarpm description on that lwn article leaves a little to be > desired -- it wouldn't work with big packages (is the quoted 200mb the > compressed or uncompressed size?), the reconstruction from deltas is a > CPU intensive task and we have a slow CPU, and it's all done in memory > and we don't have a huge amount of memory especially on XO-1. > olpc-update has an overhead of about 5 minutes of checksumming files. Well it works fine for OpenOffice and that's probably about the biggest package I have on my F-11 system. The file size might be a restriction to keep the memory usage in check. The thing with deltarpm is ultimately its a decision between bandwidth usage and memory usage. If all the updates are coming from a local school server and there's only a few updates a month its probably better going with the complete rpms. If bandwidth is an issue then drpms might well be the way to go. Fortunately its easy to enforce from the server side so you could include the deltrarpm support on the client side and if its not wanted just don't make the drpms available from the server. > Even though olpc-update isn't great for doing big distro updates > (because of storing 2 copies of changed files, in this case almost all > of them), it worked in those situations. I've never attempted an > RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that > work out for regular Fedora users? I've never had a problem with it. I've used it to remotely update my australian server from F-7 -> F-11 (not at once), and never had an issue with it. I've done it without issue on my local London firewall as well (a Fit-PC which runs the same style Geode a the XO). The main issue is that Fedora only tests upgrades between supported versions. So they "support" yum upgrades to F-11 from F-9 and F-10. > "yum update" always seems to use a surprising amount of bandwidth, > redownloading entire package databases just to see if anything new is > available. olpc-update was much more efficient in this respect, sending > only a 128-byte hash of the filesystem contents file to the OATS server. > For rpms, is there a more efficient alternative for updates-checking in > situations where there is only going to be e.g. 1 update per month? This should have improved greatly from F-9 to F-11. As for more efficient, not that I'm aware of but if there's only one update a month why does it matter? > "yum update" has historically not worked very well on the XO. It hits > OOM, it fills up yum's cache and then aborts, it gets confused between > i586 and i686, etc. That should be a thing of the past with F-11. Also its a simple change to a rpm config file to change the geode from being a i586 to i686 as far as rpm is concerned. With F-11 being i586 this also shouldn't really be an issue either and the problem will be gone entirely with F-12. rpm and yum memory usage has improved alot in recent releases so hopefully the overall situation should be improved. http://laiskiainen.org/blog/?p=19 > We would have to tweak yum's behaviour quite heavily.. I don't think we > want an rpm cache, or for it to keep the .rpm files at all. It only keeps the rpms until its installed them. Most of that should be easily tunable through a olpc-relase package similar to or that depends on the generic-release or fedora-release package. > It introduces new questions of security, signing, etc. Deployments will > want to sign their rpm updates that they push out, so we now need a > mechanism for getting that specific RPM signing public key onto all the > laptops in a deployment so that they can trust the updates server. > We had this nailed down for olpc-update: deployments can insert "local" > public keys into the manufacturing through keyjector firmwares for > existing laptops, and Quanta can now manufacture laptops with these keys > already in place for future orders. olpc-update and the bitfrost code > used these keys to verify updates. The way to get the signing key onto them would be through or in the equivalent of the fedora-release file. > For the XO-1 possibility it raises the question of how existing laptops > could be migrated to this new system, without losing their user data. I think It would be possible but obviously something that needs testing, and obviously would be dependant partially on the deployment as well. > Using "yum update" would be a large benefit of sharing technologies with > other communities and not having to maintain our own systems and tools. > However olpc-update would be easier in the short term because all the > components have been implemented and deployed, and there aren't really > any open questions. Agreed. > Any other thoughts/opinions one way or the other? None either way, obviously using yum has the advantage of being upstream and having mainstream testing and development. The advantage of olpc-update is that it has specific features, some which are used, some aren't and was designed with olpc deployments in mind. Maybe some of that functionality can be implemented through the yum plugin system. Peter From pbrobinson at gmail.com Wed Jun 24 10:05:30 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 11:05:30 +0100 Subject: update mechanism for new releases In-Reply-To: <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <2d319b780906231133v50436f39qa69068efd7a46cf7@mail.gmail.com> <2d319b780906231210x11115e49qac3afcdbddd60975@mail.gmail.com> Message-ID: <5256d0b0906240305n14a4ce78sa8875ca6f1764874@mail.gmail.com> >> Even though olpc-update isn't great for doing big distro updates >> (because of storing 2 copies of changed files, in this case almost all >> of them), it worked in those situations. I've never attempted an >> RPM-based update from e.g. Fedora 10 to Fedora 11. How well does that >> work out for regular Fedora users? > > Lot's of people will tell you that it works fine. However, this is not > a supported path for upgrade. Users should use Pre-Upgrade instead. > See: > => http://fedoraproject.org/wiki/Category:PreUpgrade > => http://fedoraproject.org/wiki/Interviews/PreUpgrade Well its not supported completely, the simple fact that a lot of people use it means that its supported within certain constraints. The problem with preupgrade is that it needs user interaction and a lot of space. It downloads the distro update locally, reboots the machine and then runs anaconda. >> "yum update" always seems to use a surprising amount of bandwidth, >> redownloading entire package databases just to see if anything new is >> available. olpc-update was much more efficient in this respect, sending >> only a 128-byte hash of the filesystem contents file to the OATS server. >> For rpms, is there a more efficient alternative for updates-checking in >> situations where there is only going to be e.g. 1 update per month? > > You can configure yum to not update its cache that often with the ? > metadata_expire ? directive in /etc/yum.conf > >> "yum update" has historically not worked very well on the XO. It hits >> OOM, it fills up yum's cache and then aborts, it gets confused between >> i586 and i686, etc. > > RPM has seen a lot of improvements in speed and memory consumption > lately. My XO (a build from the latest G1G1 in Europe that I never > updated yet) has RPM 4.4.2. Panu Matilain has just posted about that, > comparing the performances of RPM from 4.4.2 (Fedora 9) to 4.7 (Fedora > 11). Perfect timing :) > => http://laiskiainen.org/blog/?p=19 > > Yum has also been improved. Not sure those improvements would be > enough, but I bet the situation in Fedora 11 is already much better > than it was in the previous OLPC builds from Fedora 9. > >> We would have to tweak yum's behaviour quite heavily.. I don't think we >> want an rpm cache, or for it to keep the .rpm files at all. > > You can use the ? keepcache ? directive in /etc/yum.conf which AFAIU > aims exactly at that. From ? man yum.conf ? : > ? ? ?keepcache > ? ? ? ? ? ? ?Either ?1? or ?0?. Determines whether or not yum keeps the cache > ? ? ? ? ? ? ?of ?headers and packages after successful installation. ?Default > ? ? ? ? ? ? ?is ?1? (keep files) > > What other customizations are you expecting ? > >> It introduces new questions of security, signing, etc. Deployments will >> want to sign their rpm updates that they push out, so we now need a >> mechanism for getting that specific RPM signing public key onto all the >> laptops in a deployment so that they can trust the updates server. >> We had this nailed down for olpc-update: deployments can insert "local" >> public keys into the manufacturing through keyjector firmwares for >> existing laptops, and Quanta can now manufacture laptops with these keys >> already in place for future orders. olpc-update and the bitfrost code >> used these keys to verify updates. > > Yum will ask the user if he wants to import the key and trust it on > first use. Wouldn't that be enough for signing keys ? Couldn't Quanta > manufacture the laptops with those GPG keys bundled too ? Or it can be done like a standard Fedora release key which is pre imported which would mean that there's not need for confirmation. Peter From pbrobinson at gmail.com Wed Jun 24 10:12:00 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 11:12:00 +0100 Subject: update mechanism for new releases In-Reply-To: <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> References: <1245780103.2190.72.camel@polyethylene> <46a038f90906231307l4b6efe6ataa1c3d6dfd95c965@mail.gmail.com> Message-ID: <5256d0b0906240312r481734dewe658de7401f25c7b@mail.gmail.com> > RPM is unfortunately a disaster in this space. If an rpm transaction > fails, there are no sane ways to recover it. On XO-1 a full OS update > transaction with rpm ?will take a very long time, so it's highly > likely that it will be interrupted. RPM and yum hackers treat this as > an intractable problem. yum has a feature now that allows you to complete 'transactions' I discovered the hard way that this actually works quite well :-) > This is, IMO, the actual showstopper. If we had a fs that could handle > snapshotting, then we could snapshot the system before starting the > RPM transaction, and have recovery hooks in the boot partition or in > initrd. There's been discussion on fedora-devel about hooking up yum > with btrfs transactions We do this at work on our SANs for major upgrades "snap restore backup-x" reboot :-) > ?- Upstream has not historically supported yum-based upgrades, only > anaconda upgrades. Yum OS upgrades are a relatively new (and risky) > thing. We could have an 'anaconda boot' partition to handle upgrades > without external media. Sounds like preupgrade. But in specific deployments where you know exactly the current software versions and the hardware it would be fairly easy to test and verify a 'yum upgrade'. > ?- Disk space requirements for olpc-update vs yum/rpm are probably > similar, and I suspect that during the upgrade rpm transaction the > footprint is larger for the rpm methods. We could teach olpc-update to > jettison the old image as soon as the new one boots successfully... > > ?- olpc-update completely sidesteps %pre and %post scripts -- this is > potentially a problem. > > ?- olpc-update offers downgrades, but our software at higher layers > doesn't support this. The Journal format upgrade broke downgrades in > the last OS upgrade. Sugar 0.84 has another Journal format change, > probably with a similar upgrade-only path. > > ?- deltarpm-style tools are of little benefit for a whole OS upgrade. > as there is little or no overlap between releases. Where there is > overlap, then olpc-update's hardlinking strategy is also a win of > similar proportions. Deltarpm-style tools usually force you to keep > around the original rpm as well. I think it uses the actual installed files so there's no need to keep the actual rpms around. Peter From bkearney at redhat.com Wed Jun 24 12:03:39 2009 From: bkearney at redhat.com (Bryan Kearney) Date: Wed, 24 Jun 2009 08:03:39 -0400 Subject: rpm vs xo & activity updates In-Reply-To: <1245782906.2190.100.camel@polyethylene> References: <1245782906.2190.100.camel@polyethylene> Message-ID: <4A42161B.4010103@redhat.com> Daniel Drake wrote: > - There is certainly room for improvement in future, but finding > development time in the short term may be a bit tricky... or perhaps we > will be able to raise community interest in making or implementing a > plan for improvement... :) > > Daniel > Have you looked at how ruby gems and rpms interact? I do not have a tremendous amount of experience, but it seems like the user can select either rpms or gems to update, and it "just works". -- bk From mikus at bga.com Wed Jun 24 11:30:27 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Wed, 24 Jun 2009 07:30:27 -0400 Subject: strawberry on XO-1 Message-ID: <4A420E53.1010901@bga.com> [ FYI. I am _not_ asking for help; I'm sharing my experiences. ] Booted my XO-1 from an USB stick with build soas strawberry on it. [Because I do not have any system on which mounting of a squashfs filesystem works, I have to use the rawhide version of the livecd-iso-to-disk script; neither does livecd-iso-to-xo work, so I am unable to install builds distributed as .iso onto my XO's nand.] Strawberry (F11-based) works; but it is reproducibly stalling when doing a huge 'rsync'. [Since the system then is unresponsive, I can't examine it. My suspicion is that the system ran out of memory, despite having a swap partition active.] The interesting thing is that on my XO-1, Soas2-20090622 (on which strawberry is supposedly based) runs the same 'rsync' without trouble. mikus From pbrobinson at gmail.com Wed Jun 24 12:47:54 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 13:47:54 +0100 Subject: strawberry on XO-1 In-Reply-To: <4A420E53.1010901@bga.com> References: <4A420E53.1010901@bga.com> Message-ID: <5256d0b0906240547n6a9438ffo5f11a2fbcc6873a8@mail.gmail.com> Hi Mikus, I think you should be about to use the XO image from http://download.sugarlabs.org/soas/xoimages/ using the nand-copy command to install it. Peter On Wed, Jun 24, 2009 at 12:30 PM, Mikus Grinbergs wrote: > [ FYI. ?I am _not_ asking for help; ?I'm sharing my experiences. ] > > Booted my XO-1 from an USB stick with build soas strawberry on it. > > [Because I do not have any system on which mounting of a squashfs filesystem > works, I have to use the rawhide version of the livecd-iso-to-disk script; > ?neither does livecd-iso-to-xo work, so I am unable to install builds > distributed as .iso onto my XO's nand.] > > Strawberry (F11-based) works; ?but it is reproducibly stalling when doing a > huge 'rsync'. ?[Since the system then is unresponsive, I can't examine it. > ?My suspicion is that the system ran out of memory, despite having a swap > partition active.] ?The interesting thing is that on my XO-1, Soas2-20090622 > (on which strawberry is supposedly based) runs the same 'rsync' without > trouble. > > mikus > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > From martin at martindengler.com Wed Jun 24 13:14:25 2009 From: martin at martindengler.com (Martin Dengler) Date: Wed, 24 Jun 2009 14:14:25 +0100 Subject: strawberry on XO-1 In-Reply-To: <4A420E53.1010901@bga.com> References: <4A420E53.1010901@bga.com> Message-ID: <20090624131425.GF9324@ops-13.xades.com> On Wed, Jun 24, 2009 at 07:30:27AM -0400, Mikus Grinbergs wrote: > [Because I do not have any system on which mounting of a squashfs > filesystem works, I have to use the rawhide version of the > livecd-iso-to-disk script; neither does livecd-iso-to-xo work, so I > am unable to install builds distributed as .iso onto my XO's nand.] I have this same issue, and it's terribly annoying. FYI, I hope we can get filesystem lzma'd tarballs up (as dsd/OLPC are doing to XO 1.5 builds) somewhere soon to help with this type of thing. As well we can get pre-partitioned streams of bits that can be cat'ed to a USB block device of 1, 2, or 4G so that the whole livecd-iso-to-disk.sh / decide on drive partitions / etc. can be skipped for the XO build[1]. > Strawberry (F11-based) works; but it is reproducibly stalling when > doing a huge 'rsync'. [...] Soas2-20090622 runs the same 'rsync' > without trouble. There isn't perhaps a kernel difference or significant memory pressure difference, is there? /me wonders aloud about the utility of cgroups to limit the rsync's memory / cpu usage for diagnosis purposes. > > mikus Martin 1. For the XO build. Only. livecd-iso-to-disk.sh has a lot of functionality for the non-XO build (home/root overlays, MBRs/bootable-ness for a variety of BIOS/EFT targets, etc.) that I don't think we want to decide for our learners/testers/deployers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pbrobinson at gmail.com Wed Jun 24 21:28:45 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 24 Jun 2009 22:28:45 +0100 Subject: stalled Fedora reviews Message-ID: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> Hi All Just going through the package reviews in Fedora related to olpc/sugar. The following are either stalled or closed due to lack of response from the reporter. Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 I'm not really sure of the exact reasons for the stall. I know I was watching the first 3 and haven't seen a response for a while. Is someone able to take them over (I can assist or review if necessary) or if they're no longer wanted let me know and I'll close them. Cheers, Peter From smparrish at gmail.com Wed Jun 24 22:15:46 2009 From: smparrish at gmail.com (Steven M. Parrish) Date: Wed, 24 Jun 2009 18:15:46 -0400 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> Message-ID: <200906241815.46502.smparrish@gmail.com> I'll take a look at some of these tomorrow and see what needs to be done with them. > Hi All > > Just going through the package reviews in Fedora related to > olpc/sugar. The following are either stalled or closed due to lack of > response from the reporter. > > Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 > Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 > sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 > sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 > sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 > sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 > > I'm not really sure of the exact reasons for the stall. I know I was > watching the first 3 and haven't seen a response for a while. Is > someone able to take them over (I can assist or review if necessary) > or if they're no longer wanted let me know and I'll close them. > > Cheers, > Peter > _______________________________________________ > Sugar-devel mailing list > Sugar-devel at lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel From dsd at laptop.org Fri Jun 26 11:00:15 2009 From: dsd at laptop.org (Daniel Drake) Date: Fri, 26 Jun 2009 12:00:15 +0100 Subject: Fedora packages for XO-1.5 distro Message-ID: <1246014015.2790.52.camel@polyethylene> Hi, Just wanted to point out the slowly-growing list of custom packages that we're including in the XO-1.5 F11 build: http://wiki.laptop.org/go/F11_for_1.5#Modifications_to_Fedora I'm hoping to spearhead some efforts to get these included in the Fedora package tree (specifically dracut, dracut-modules-olpc, olpc-bootanim, olpc-library, olpc-switch-desktop and olpc-utils) but I have not found the time yet. If anyone wants to contribute and has some time on their hands, getting a head start on a couple of these would be a huge help. cheers Daniel From pbrobinson at gmail.com Fri Jun 26 11:00:40 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 26 Jun 2009 12:00:40 +0100 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <200906241815.46502.smparrish@gmail.com> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> <200906241815.46502.smparrish@gmail.com> Message-ID: <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> Thanks Steven, Let me know if I can be of some help. Regards, Peter On Wed, Jun 24, 2009 at 11:15 PM, Steven M. Parrish wrote: > I'll take a look at some of these tomorrow and see what needs to be done with > them. > > > >> Hi All >> >> Just going through the package reviews in Fedora related to >> olpc/sugar. The following are either stalled or closed due to lack of >> response from the reporter. >> >> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 >> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 >> sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 >> sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 >> sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 >> sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 >> >> I'm not really sure of the exact reasons for the stall. I know I was >> watching the first 3 and haven't seen a response for a while. Is >> someone able to take them over (I can assist or review if necessary) >> or if they're no longer wanted let me know and I'll close them. >> >> Cheers, >> Peter >> _______________________________________________ >> Sugar-devel mailing list >> Sugar-devel at lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/sugar-devel > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list > From pbrobinson at gmail.com Fri Jun 26 11:07:30 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 26 Jun 2009 12:07:30 +0100 Subject: Fedora packages for XO-1.5 distro In-Reply-To: <1246014015.2790.52.camel@polyethylene> References: <1246014015.2790.52.camel@polyethylene> Message-ID: <5256d0b0906260407q79f37a58t6966af0aa376ea7@mail.gmail.com> Hi Daniel, > Just wanted to point out the slowly-growing list of custom packages that > we're including in the XO-1.5 F11 build: > > http://wiki.laptop.org/go/F11_for_1.5#Modifications_to_Fedora > > I'm hoping to spearhead some efforts to get these included in the Fedora > package tree (specifically dracut, dracut-modules-olpc, olpc-bootanim, > olpc-library, olpc-switch-desktop and olpc-utils) but I have not found > the time yet. If anyone wants to contribute and has some time on their > hands, getting a head start on a couple of these would be a huge help. A couple of things. There's already an olpc-utils package in Fedora. I'm the current maintainer of the package. Let me know how I can help, or you can request to be added to the ACL here https://admin.fedoraproject.org/pkgdb/packages/name/olpc-utils and do it yourself. Also can you add any RH BZ stuff you do as a blocker to the tracker bug to make it easier to track https://bugzilla.redhat.com/show_bug.cgi?id=462625 I would be surprised if dracut doesn't make it to rawhide soon as its on the Feature list for F12. I'll poke some people here at FudCon to try and find out the status. I also noticed an updated openchrome driver hit F11 testing in the last day or so, not sure if that has the changes you mention. Cheers, Peter From dsd at laptop.org Fri Jun 26 11:23:57 2009 From: dsd at laptop.org (Daniel Drake) Date: Fri, 26 Jun 2009 12:23:57 +0100 Subject: Fedora packages for XO-1.5 distro In-Reply-To: <5256d0b0906260407q79f37a58t6966af0aa376ea7@mail.gmail.com> References: <1246014015.2790.52.camel@polyethylene> <5256d0b0906260407q79f37a58t6966af0aa376ea7@mail.gmail.com> Message-ID: <1246015437.2790.56.camel@polyethylene> On Fri, 2009-06-26 at 12:07 +0100, Peter Robinson wrote: > There's already an olpc-utils package in Fedora. I'm the current > maintainer of the package. Let me know how I can help, or you can > request to be added to the ACL here > https://admin.fedoraproject.org/pkgdb/packages/name/olpc-utils and do > it yourself. Looks like that would be a good package to start with, I've requested the access. > Also can you add any RH BZ stuff you do as a blocker to the tracker > bug to make it easier to track > https://bugzilla.redhat.com/show_bug.cgi?id=462625 OK. We don't have any yet. > I would be surprised if dracut doesn't make it to rawhide soon as its > on the Feature list for F12. I'll poke some people here at FudCon to > try and find out the status. Yeah, but they probably don't plan to include it in F11. If you find them, please explain OLPC's plans to deploy this with the F11 XO-1.5 build and hence our desires to see it in the F11 tree. When they add it to F12, they will be making it a replacement for mkinitrd, integrating it into the kernel RPM, and so on. They obviously won't do that for F11 and that's not what we want either. We'd just like it as a standard Fedora package which does nothing until someone executes /usr/bin/dracut from the command line to build an initramfs. > I also noticed an updated openchrome driver hit F11 testing in the > last day or so, not sure if that has the changes you mention. Wow..Xavier rocks. It looks like it should work. Thanks for pointing this out! Daniel From pbrobinson at gmail.com Fri Jun 26 11:26:33 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Fri, 26 Jun 2009 12:26:33 +0100 Subject: Fedora packages for XO-1.5 distro In-Reply-To: <1246015437.2790.56.camel@polyethylene> References: <1246014015.2790.52.camel@polyethylene> <5256d0b0906260407q79f37a58t6966af0aa376ea7@mail.gmail.com> <1246015437.2790.56.camel@polyethylene> Message-ID: <5256d0b0906260426v77c1a44bk37db8afb07901bcb@mail.gmail.com> >> There's already an olpc-utils package in Fedora. I'm the current >> maintainer of the package. Let me know how I can help, or you can >> request to be added to the ACL here >> https://admin.fedoraproject.org/pkgdb/packages/name/olpc-utils and do >> it yourself. > > Looks like that would be a good package to start with, I've requested > the access. Done. >> Also can you add any RH BZ stuff you do as a blocker to the tracker >> bug to make it easier to track >> https://bugzilla.redhat.com/show_bug.cgi?id=462625 > > OK. We don't have any yet. Just a reminder ;-) >> I would be surprised if dracut doesn't make it to rawhide soon as its >> on the Feature list for F12. I'll poke some people here at FudCon to >> try and find out the status. > > Yeah, but they probably don't plan to include it in F11. If you find > them, please explain OLPC's plans to deploy this with the F11 XO-1.5 > build and hence our desires to see it in the F11 tree. > > When they add it to F12, they will be making it a replacement for > mkinitrd, integrating it into the kernel RPM, and so on. They obviously > won't do that for F11 and that's not what we want either. We'd just like > it as a standard Fedora package which does nothing until someone > executes /usr/bin/dracut from the command line to build an initramfs. OK >> I also noticed an updated openchrome driver hit F11 testing in the >> last day or so, not sure if that has the changes you mention. > > Wow..Xavier rocks. It looks like it should work. Thanks for pointing > this out! Its worth enabling the updates-testing repo as it gets those sort of fixes quite quickly, and is pretty stable. I enable it on all my machines. Peter From smparrish at gmail.com Sat Jun 27 00:32:01 2009 From: smparrish at gmail.com (Steven M. Parrish) Date: Fri, 26 Jun 2009 20:32:01 -0400 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> <200906241815.46502.smparrish@gmail.com> <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> Message-ID: <200906262032.02179.smparrish@gmail.com> Peter, The 2 font reviews have been closed. I will work on getting new reviews up this week. Sugar-Stopwatch was already approved and is in F11 so I closed this one. For the remaining 3 I pinged the person who submitted the review to get an update and see what help if any they need to wrap them up. Will keep you posted. Steven > Thanks Steven, > > Let me know if I can be of some help. > > Regards, > Peter > > On Wed, Jun 24, 2009 at 11:15 PM, Steven M. Parrish wrote: > > I'll take a look at some of these tomorrow and see what needs to be done > > with them. > > > >> Hi All > >> > >> Just going through the package reviews in Fedora related to > >> olpc/sugar. The following are either stalled or closed due to lack of > >> response from the reporter. > >> > >> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 > >> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 > >> sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 > >> sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 > >> sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 > >> sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 > >> > >> I'm not really sure of the exact reasons for the stall. I know I was > >> watching the first 3 and haven't seen a response for a while. Is > >> someone able to take them over (I can assist or review if necessary) > >> or if they're no longer wanted let me know and I'll close them. > >> > >> Cheers, > >> Peter > >> _______________________________________________ > >> Sugar-devel mailing list > >> Sugar-devel at lists.sugarlabs.org > >> http://lists.sugarlabs.org/listinfo/sugar-devel > > > > _______________________________________________ > > Fedora-olpc-list mailing list > > Fedora-olpc-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-olpc-list From luya at fedoraproject.org Sun Jun 28 01:46:20 2009 From: luya at fedoraproject.org (Luya Tshimbalanga) Date: Sat, 27 Jun 2009 18:46:20 -0700 Subject: Broken browse activity for strawberry. Message-ID: <4A46CB6C.3030307@fedoraproject.org> Hello, With a lot of help of OLPC team, my XO-1 got repaired and I am able to test strawberry from Sugarlabs. While the power management is not quite optimized, the wireless connection has definitively improved. I have a problem running browse active in XO-1 because it traceback somewhat? Has any with XO-1 got the same issue? Luya From mikus at bga.com Sun Jun 28 03:56:28 2009 From: mikus at bga.com (Mikus Grinbergs) Date: Sat, 27 Jun 2009 23:56:28 -0400 Subject: Broken browse activity for strawberry Message-ID: <4A46E9EC.8070009@bga.com> > I have a problem running browse active in XO-1 because it traceback > somewhat? Has any with XO-1 got the same issue? I'm booting strawberry on my XO-1 from an USB stick. I'm not really an user of Browse (I prefer Firefox or Opera, both of which launch ok on strawberry on my XO-1), but *all* the instances in which I've used Browse (108) on strawberry on XO-1 have worked ok for me. [Yes, there are some tracebacks in Browse's output log (e.g., for xpcom using xulrunner), but those did not appear to affect Browse showing/downloading the things I told it to do.] I would not say "broken" for Browse Activity on strawberry. mikus From pbrobinson at gmail.com Sun Jun 28 08:06:22 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 28 Jun 2009 09:06:22 +0100 Subject: Broken browse activity for strawberry. In-Reply-To: <4A46CB6C.3030307@fedoraproject.org> References: <4A46CB6C.3030307@fedoraproject.org> Message-ID: <5256d0b0906280106i69f1c733if59cd1105cea0917@mail.gmail.com> > With a lot of help of OLPC team, my XO-1 got repaired and I am able to test > strawberry from Sugarlabs. While the power management is not quite > optimized, the wireless connection has definitively improved. > > I have a problem running browse active in XO-1 because it traceback > somewhat? Has any with XO-1 got the same issue? Yes, I'm seeing the same issue on the XO-1 but I haven't had time to look any further at it, Peter From fab at fedoraproject.org Sun Jun 28 14:25:18 2009 From: fab at fedoraproject.org (Fabian Affolter) Date: Sun, 28 Jun 2009 16:25:18 +0200 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <200906262032.02179.smparrish@gmail.com> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> <200906241815.46502.smparrish@gmail.com> <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> <200906262032.02179.smparrish@gmail.com> Message-ID: <4A477D4E.6030107@fedoraproject.org> Am 27.06.2009 02:32, schrieb Steven M. Parrish: >>>> Just going through the package reviews in Fedora related to >>>> olpc/sugar. The following are either stalled or closed due to lack of >>>> response from the reporter. >>>> >>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 >>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 >>>> sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 >>>> sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 >>>> sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 >>>> sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 Some of those review requests belong to me. >>>> I'm not really sure of the exact reasons for the stall. I know I was >>>> watching the first 3 and haven't seen a response for a while. Is >>>> someone able to take them over (I can assist or review if necessary) >>>> or if they're no longer wanted let me know and I'll close them. One reason is that some of those packages need python-olpcgames to work. This packages is missing for a long time. The person who made this package is not answering mails and there is no build. So python-olpcgames needs a review again, but first we need to pack it. It would help if there is a release tarball of olpcgames. But I guess that the only way to do at the moment is to work with a vcs checkout. Kind regards, Fabian From pbrobinson at gmail.com Sun Jun 28 18:57:11 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 28 Jun 2009 19:57:11 +0100 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <4A477D4E.6030107@fedoraproject.org> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> <200906241815.46502.smparrish@gmail.com> <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> <200906262032.02179.smparrish@gmail.com> <4A477D4E.6030107@fedoraproject.org> Message-ID: <5256d0b0906281157k4ca2a4d4g32c313cbbd73e0e7@mail.gmail.com> Hi Fabian, >>>>> Just going through the package reviews in Fedora related to >>>>> olpc/sugar. The following are either stalled or closed due to lack of >>>>> response from the reporter. >>>>> >>>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 >>>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 >>>>> sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 >>>>> sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 >>>>> sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 >>>>> sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 > > Some of those review requests belong to me. > >>>>> I'm not really sure of the exact reasons for the stall. I know I was >>>>> watching the first 3 and haven't seen a response for a while. Is >>>>> someone able to take them over (I can assist or review if necessary) >>>>> or if they're no longer wanted let me know and I'll close them. > > One reason is that some of those packages need python-olpcgames to work. > This packages is missing for a long time. The person who made this package > is not answering mails and there is no build. ?So python-olpcgames needs a > review again, but first we need to pack it. > > It would help if there is a release tarball of olpcgames. ?But I guess that > the only way to do at the moment is to work with a vcs checkout. Thanks for the update. Have you filed a bug report against the python-olpcgames package? If so what is the bug number? The python-olpcgames is in Fedora as can be seen in the package cvs [1]. I'll have a look at it this week to see what need to be resurrected to get it back into the main builds. Cheers, Peter [1] http://cvs.fedoraproject.org/viewvc/rpms/python-olpcgames/ From abo at stacken.kth.se Sun Jun 28 19:52:25 2009 From: abo at stacken.kth.se (=?ISO-8859-1?Q?Alexander_Bostr=F6m?=) Date: Sun, 28 Jun 2009 21:52:25 +0200 Subject: olpc-switch-desktop issues Message-ID: <4A47C9F9.3010202@stacken.kth.se> Hello, I'm working on submitting olpc-switch-desktop for inclusion in Fedora. I (or rather rpmlint) found these issues: The .spec from the repo, the GNOME .desktop and the Sugar control panel references a couple of SVG files, but those aren't in the repo. Are there any suitable icons to use or do someone need to create them? The .spec creates /etc/skel/Desktop (for the GNOME .desktop file). I think that breaks the feature that a name from the user's locale is used when creating the desktop directory (xdg-user-dirs), so that needs to be done some other way. Is there a way to place an icon on every user's desktop without poking around in their ~/Desktop? If not, perhaps the Sugar part can install the GNOME .desktop file for the user when the user first switches from Sugar to GNOME? Then it is only done for GNOME users who actually ran Sugar in the first place (call that a feature or a bug) and by then the locale is hopefully set correctly so that the desktop directory can be created the proper way. Also, the GNOME app should probably have a license declaration at the top of the source file, or the license should be stated explicitly in the README. /abo From pbrobinson at gmail.com Sun Jun 28 21:23:56 2009 From: pbrobinson at gmail.com (Peter Robinson) Date: Sun, 28 Jun 2009 22:23:56 +0100 Subject: [Sugar-devel] stalled Fedora reviews In-Reply-To: <5256d0b0906281157k4ca2a4d4g32c313cbbd73e0e7@mail.gmail.com> References: <5256d0b0906241428t7100164es47dd8b6001ebd4a7@mail.gmail.com> <200906241815.46502.smparrish@gmail.com> <5256d0b0906260400m21da772did3add36e96486769@mail.gmail.com> <200906262032.02179.smparrish@gmail.com> <4A477D4E.6030107@fedoraproject.org> <5256d0b0906281157k4ca2a4d4g32c313cbbd73e0e7@mail.gmail.com> Message-ID: <5256d0b0906281423i7f3e1fa6y5bc638da29aa8c63@mail.gmail.com> >>>>>> Just going through the package reviews in Fedora related to >>>>>> olpc/sugar. The following are either stalled or closed due to lack of >>>>>> response from the reporter. >>>>>> >>>>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=462711 >>>>>> Thabit-fonts https://bugzilla.redhat.com/show_bug.cgi?id=461139 >>>>>> sugar-record https://bugzilla.redhat.com/show_bug.cgi?id=476435 >>>>>> sugar-stopwatch https://bugzilla.redhat.com/show_bug.cgi?id=481516 >>>>>> sugar-paint https://bugzilla.redhat.com/show_bug.cgi?id=472071 >>>>>> sugar-maze https://bugzilla.redhat.com/show_bug.cgi?id=467641 >> >> Some of those review requests belong to me. >> >>>>>> I'm not really sure of the exact reasons for the stall. I know I was >>>>>> watching the first 3 and haven't seen a response for a while. Is >>>>>> someone able to take them over (I can assist or review if necessary) >>>>>> or if they're no longer wanted let me know and I'll close them. >> >> One reason is that some of those packages need python-olpcgames to work. >> This packages is missing for a long time. The person who made this package >> is not answering mails and there is no build. ?So python-olpcgames needs a >> review again, but first we need to pack it. >> >> It would help if there is a release tarball of olpcgames. ?But I guess that >> the only way to do at the moment is to work with a vcs checkout. > > Thanks for the update. Have you filed a bug report against the > python-olpcgames package? If so what is the bug number? The > python-olpcgames is in Fedora as can be seen in the package cvs [1]. > I'll have a look at it this week to see what need to be resurrected to > get it back into the main builds. OK, looking at the cvs for the package there was never a build committed. Looking through the old Package Review bugs I found the associated bug (below). The srpm is still at the original location. Is it still the current release? The question I have to ask is, if it was never committed and built was it ever used? What are the packages that depend on it? https://bugzilla.redhat.com/show_bug.cgi?id=250533 I also submitted the srpm to koji as a scratch build to see if it would still build but in the very least the package is going to need to be fixed so it builds with python 2.6 Peter From shawn-olpc at willden.org Mon Jun 29 17:41:20 2009 From: shawn-olpc at willden.org (Shawn Willden) Date: Mon, 29 Jun 2009 11:41:20 -0600 Subject: Tkinter support in sugar builds Message-ID: <200906291141.21128.shawn-olpc@willden.org> Is there any plan for it? A friend of mine is interested in porting some math ed apps to the OLPC, but they're written with pytkinter. He's trying to decide if he needs to port to pygtk. Assuming it's reasonable to install tkinter on the XO in order to support his apps, any idea how difficult it would be to "sugarize" a tkinter app, so that it can run as an activity? I have basically zero knowledge of what's involved in sugarization, so please excuse me if this is a dumb question. All comments/suggestions/flames appreciated, Shawn. From cjb at laptop.org Mon Jun 29 17:42:41 2009 From: cjb at laptop.org (Chris Ball) Date: Mon, 29 Jun 2009 13:42:41 -0400 Subject: Tkinter support in sugar builds In-Reply-To: <200906291141.21128.shawn-olpc@willden.org> (Shawn Willden's message of "Mon, 29 Jun 2009 11:41:20 -0600") References: <200906291141.21128.shawn-olpc@willden.org> Message-ID: Hi Shawn, > Is there any plan for it? A friend of mine is interested in > porting some math ed apps to the OLPC, but they're written with > pytkinter. He's trying to decide if he needs to port to pygtk. > > Assuming it's reasonable to install tkinter on the XO in order to > support his apps, any idea how difficult it would be to > "sugarize" a tkinter app, so that it can run as an activity? I > have basically zero knowledge of what's involved in sugarization, > so please excuse me if this is a dumb question. It's a fine question. I don't think it's possible/realistic to sugarize a tkinter app (and there's no plan for supporting tkinter), so I think moving to pygtk is justified. Thanks, - Chris. -- Chris Ball From dsd at laptop.org Tue Jun 30 09:22:25 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 30 Jun 2009 10:22:25 +0100 Subject: olpc-switch-desktop issues In-Reply-To: <4A47C9F9.3010202@stacken.kth.se> References: <4A47C9F9.3010202@stacken.kth.se> Message-ID: <1246353745.2216.2.camel@polyethylene> On Sun, 2009-06-28 at 21:52 +0200, Alexander Bostr?m wrote: > I'm working on submitting olpc-switch-desktop for inclusion in Fedora. I > (or rather rpmlint) found these issues: > > The .spec from the repo, the GNOME .desktop and the Sugar control panel > references a couple of SVG files, but those aren't in the repo. Are > there any suitable icons to use or do someone need to create them? Oops, added now. Thanks for pointing this out. > The .spec creates /etc/skel/Desktop (for the GNOME .desktop file). I > think that breaks the feature that a name from the user's locale is used > when creating the desktop directory (xdg-user-dirs), so that needs to be > done some other way. Even when I clear /home/olpc completely, open Sugar, change to spanish and switch to GNOME, the directory that gets created is /home/olpc/Desktop - it does not seem to be localized. I do not know of any other way of adding other icons to the desktop. > Also, the GNOME app should probably have a license declaration at the > top of the source file, or the license should be stated explicitly in > the README. OK will add... Thanks! Daniel From abo at stacken.kth.se Tue Jun 30 10:16:11 2009 From: abo at stacken.kth.se (=?UTF-8?B?QWxleGFuZGVyIEJvc3Ryw7Zt?=) Date: Tue, 30 Jun 2009 12:16:11 +0200 Subject: olpc-switch-desktop issues In-Reply-To: <1246353745.2216.2.camel@polyethylene> References: <4A47C9F9.3010202@stacken.kth.se> <1246353745.2216.2.camel@polyethylene> Message-ID: <4A49E5EB.2030500@stacken.kth.se> Den 2009-06-30 11:22, Daniel Drake skrev: > Even when I clear /home/olpc completely, open Sugar, change to spanish > and switch to GNOME, the directory that gets created > is /home/olpc/Desktop - it does not seem to be localized. Hmm. I installed F10 on some machine a while back, with sv_SE as the default locale, created a fresh user account and got ~/Skrivbord instead of Desktop. Are you sure you also cleared out ~/.config/user-dirs.* ? > I do not know of any other way of adding other icons to the desktop. Me neither. But the approach of creating the .desktop when first switching from Sugar to GNOME should be ok. As I'm sure Sugar will be the default wherever this package is relevant this shouldn't break anything. Btw, maybe olpc-switch-desktop should really just be writing to ~/.dmrc ? /abo From dsd at laptop.org Tue Jun 30 11:13:40 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 30 Jun 2009 12:13:40 +0100 Subject: olpc-switch-desktop issues In-Reply-To: <4A49E5EB.2030500@stacken.kth.se> References: <4A47C9F9.3010202@stacken.kth.se> <1246353745.2216.2.camel@polyethylene> <4A49E5EB.2030500@stacken.kth.se> Message-ID: <1246360421.2216.14.camel@polyethylene> On Tue, 2009-06-30 at 12:16 +0200, Alexander Bostr?m wrote: > Hmm. I installed F10 on some machine a while back, with sv_SE as the > default locale, created a fresh user account and got ~/Skrivbord instead > of Desktop. > > Are you sure you also cleared out ~/.config/user-dirs.* ? Yes. Maybe the problem is that the xdg-user-dirs component is not being included in our session. Mind you, at least it works at the moment ;) > Btw, maybe olpc-switch-desktop should really just be writing to ~/.dmrc ? Which system component reads from that? Daniel From dsd at laptop.org Tue Jun 30 12:59:49 2009 From: dsd at laptop.org (Daniel Drake) Date: Tue, 30 Jun 2009 13:59:49 +0100 Subject: olpc-switch-desktop issues In-Reply-To: <4A49E5EB.2030500@stacken.kth.se> References: <4A47C9F9.3010202@stacken.kth.se> <1246353745.2216.2.camel@polyethylene> <4A49E5EB.2030500@stacken.kth.se> Message-ID: <1246366789.2216.15.camel@polyethylene> On Tue, 2009-06-30 at 12:16 +0200, Alexander Bostr?m wrote: > Hmm. I installed F10 on some machine a while back, with sv_SE as the > default locale, created a fresh user account and got ~/Skrivbord instead > of Desktop. > > Are you sure you also cleared out ~/.config/user-dirs.* ? OK, I changed olpc-session to better integrate with xinitrc.d and now it creates and uses those localized directories, and puts the icon in the right polace. The /etc/skel installation from olpc-switch-desktop can now be dropped. Thanks, Daniel