olpc June 2009

olpc@lists.fedoraproject.org

24 participants
36 discussions

Show Must Go On - SoaS for the XO-1
by Sebastian Dziallas 29 Jul '09

29 Jul '09

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

7 14

olpc-switch-desktop issues
by Alexander Boström 09 Jul '09

09 Jul '09

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

3 7

Tkinter support in sugar builds
by Shawn Willden 29 Jun '09

29 Jun '09

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.

2 1

stalled Fedora reviews
by Peter Robinson 28 Jun '09

28 Jun '09

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

3 6

Broken browse activity for strawberry.
by Luya Tshimbalanga 28 Jun '09

28 Jun '09

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

2 1

Re: Broken browse activity for strawberry
by Mikus Grinbergs 27 Jun '09

27 Jun '09

> 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

1 0

Fedora packages for XO-1.5 distro
by Daniel Drake 26 Jun '09

26 Jun '09

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

2 3

strawberry on XO-1
by Mikus Grinbergs 24 Jun '09

24 Jun '09

[ 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

3 2

rpm vs xo & activity updates
by Daniel Drake 24 Jun '09

24 Jun '09

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

5 6

update mechanism for new releases
by Daniel Drake 24 Jun '09

24 Jun '09

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

5 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

olpc June 2009