From tomeu at tomeuvizoso.net Fri Aug 1 10:19:56 2008 From: tomeu at tomeuvizoso.net (Tomeu Vizoso) Date: Fri, 1 Aug 2008 11:19:56 +0100 Subject: [Fedora-olpc-list] Re: Looking for Testers: Sugar Appliance In-Reply-To: References: <488DF2B1.1080403@redhat.com> <488E2934.2000807@redhat.com> <468D48CDA71F4FAFB83728A3DFFE2102@Q9450> <488F4BB6.2080603@redhat.com> <4891E97A.9050901@redhat.com> Message-ID: <242851610808010319k227c12f5mf628f761adec095d@mail.gmail.com> On Thu, Jul 31, 2008 at 10:32 PM, Jerry Williams wrote: > Looks like browser is old need version 94. > > I am seeing an error in WebActivity log: TypeError: promptForSaveToFile() > takes exactly 5 arguments (6 given) Yeah, Browse and xulrunner mismatch. > Installed Browser-94 and now it won't run, browser.py line 30, in > from hulahop.webview import lookup_view > ImportError: cannot import name lookup_view Looks like we have a too old hulahop in F9. Can somebody update the F9 branch? Not sure if there will be any problem with the xulrunner in there. > Also in JournalActivity log; > File "/usr/share/sugar/activities/Journal.activity/volumestoolbar.py", line > 123, in __init__ volume.icon_color) > TypeError: __init__() takes exactly 1 argument (4 given) That sounds like a too old sugar-journal to me, there's a newer one already built in F9, but maybe is still in testing. Do we have a volunteer for making sure that the set of Sugar packages in stable are coherent and more or less updated? Thanks, Tomeu From gdk at redhat.com Fri Aug 1 21:23:00 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 1 Aug 2008 17:23:00 -0400 (EDT) Subject: I'm at OLPC offices next week -- meet next Friday? Message-ID: Hi all. Sorry I've been a bit absent from the list. Trying to lay aside other responsibilities to "clear the decks" for OLPC work. I know I proposed Friday meetings, and then disappeared -- but my goal is to have a meeting on IRC next Friday. More on this next week. Thanks to everyone who has pitched in so far. --g From martin.langhoff at gmail.com Sun Aug 3 09:40:26 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sun, 3 Aug 2008 21:40:26 +1200 Subject: Fwd: Old fakeroot bug on F7 onwards - where to download from In-Reply-To: <46a038f90808030235t22337f64u721538809ad473ec@mail.gmail.com> References: <46a038f90808030235t22337f64u721538809ad473ec@mail.gmail.com> Message-ID: <46a038f90808030240g507890d7kaea7143e0a307be@mail.gmail.com> Hi! This is a trivial package that is rather outdated, and the old version has a bug that is affecting me on the XS. I am not sure how responsive Axel Thimm ( the current packager of fakeroot) is - not much wrt fakeroot anyway :-) - see the email below... If an updated version gets into F9 ( thanks to magic fairies :-) ) I can rebuild it for F7. It is a bit awkward that Clint is not publishing the tagged tarballs (AFAICS!). Makes it hard to package an updated version. There is the tla sources :-/ ---------- Forwarded message ---------- From: Martin Langhoff Date: Sun, Aug 3, 2008 at 9:35 PM Subject: Old fakeroot bug on F7 onwards - where to download from To: Development discussions related to Fedora , Clint Adams , Axel.Thimm at atrpms.net Hi! Fedora 7, 8 and 9 are shipping a version of fakeroot that is affected by a somewhat nasty race condition. The bug was characterised here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381016 , and with trivial repo steps here http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=446351 . This bug was fixed in 1.8.2 - F7,8,9 ship 1.6.4. Hopefully, F9/F8 can get an updated version of the package included. Help and pointers welcome :-) If that's not possible, I will prepare a package for the school server and offer it here. To Clint - looking for a link to the latest version to grace this email, I cannot find a source package or a tagged package anywhere. The most recent release I can see on Debian is 1.9.5 on Lenny and 1.9.6 on Sid, but there are no upstream tarballs on Alioth. Fakeroot is useful on many platforms - is it possible to arrange for publishing the tarballs somewhere? 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 rnorwood at redhat.com Mon Aug 4 20:30:18 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 4 Aug 2008 16:30:18 -0400 Subject: Release tarballs for OLPC software? In-Reply-To: <20080730113848.4b6297f1@solitude.devel.redhat.com> References: <20080730113848.4b6297f1@solitude.devel.redhat.com> Message-ID: <20080804163018.4ed6ceaa@solitude.devel.redhat.com> On Wed, 30 Jul 2008 11:38:48 -0400 Robin Norwood wrote: > Hi, > > So after working on this list: > > https://fedoraproject.org/wiki/PackageMaintainers/WishList#Easy > > It turns out there simply aren't tarball releases easily available for > some of the packages (I noted the ones I couldn't find above). I > talked to Scott, and he says: > > """ > You can download tarballs directly from our gitweb instance > with a URL like: > http://dev.laptop.org/git?p=users/cscott/olpc-contents;a=snapshot;h=olpccontents-2.0 > > ...but the aforementioned git issue with submodules means you'd need > two source lines, one for the main git module and one for the > submodule. Hrm. I can make sure the submodule uses the same tag as > the parent, so both of the source lines can be constant (using the > %{version} macro)... > > Maybe I should just suck it up and post tarballs somewhere. > """ > > So, my question is, do we need to ask Scott to put tarballs online > somewhere for these packages, or can the SRPMS at > http://xs-dev.laptop.org/~cscott/repos/joyride/ count as the upstream > sources, since they contain the tarballs we'd build from anyway? > > Does anyone know the answer to this? I found a partial answer here: http://fedoraproject.org/wiki/Packaging/SourceURL A checkout from source control is acceptable if needed, though tarballs are preferred. Next time I take a pass at packaging some of the things from the wishlist I'll look to see if I can find the SCM and a tag to build from instead of a tarball. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From martin.langhoff at gmail.com Thu Aug 7 06:37:40 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 7 Aug 2008 18:37:40 +1200 Subject: Need help: mounting usb devices on headless machines Message-ID: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> Fedoristas in the crowd, I am trying to find a tool that allows me to - automount usb devices when they are plugged in (via udev/hal) - would be nice to support removable devices - trigger an associated script on mount - all on a headless server! There is no udev/hal automounter that works on headless servers currently shipping on Fedora. Ivman is packaged, but not shipping currently (dead upstream, very cumbersome config). Working with the lvman config files is _not_ fun, and not modular at all - if several school server pacakges want different things, it'll be a mess. I have found an alternative that I like more, usbmount, which seems to work, is trivial to configure, provides the subset of Ivman that I need, and makes it simple for other packages to drop hook scripts into place via /etc/usbmount/mount.d . It doesn't have an active maintainer though. So I need some help :-) and it's not too complex. Option one - point me to something that works and is maintained -- if you know of a good reliable tool that I missed, I want to know. Can you help me configure it for this task? Option two - help me package & tweak usbmount for F7 and F9. The codebase is *tiny*, we can carry it. Option three - you are very keen on wrangling ivman's complexity and baroque xml. Grand! Let's teach it to do /etc/ivman/conf.d/ :-) Option four: anyone with a better plan? I'll probably start chipping away at #2 tomorrow... 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 Thu Aug 7 07:04:48 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 7 Aug 2008 19:04:48 +1200 Subject: [Server-devel] Need help: mounting usb devices on headless machines In-Reply-To: <20080807065242.GC11502@us.netrek.org> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <20080807065242.GC11502@us.netrek.org> Message-ID: <46a038f90808070004j7ce95fb4kb8a9069e32da22fd@mail.gmail.com> On Thu, Aug 7, 2008 at 6:52 PM, James Cameron wrote: > Don't know about Fedoristas, but on Debian and derivatives this is what usbmount is a slightly longer and nicer version of that, which will - mount various partitions if various partitions are available - run scripts from a foo.d directory using run-parts - various options including logging See for yourself here - http://svn.debian.org/wsvn/usbmount/trunk/usbmount/usbmount?op=file&rev=0&sc=0 Having it as a middle-tier does a couple of things - insulates the other packages from HAL/udev changes. Is it udev_volume_id or vol_id? - each FS get mounted once and but N scripts from different packages can be listening for that mount event my plan is to add beeps too, with a special beeping pattern if something goes wrong. Time for a "learn morse-code" activity on the XO? 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 Thu Aug 7 09:19:51 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 7 Aug 2008 21:19:51 +1200 Subject: Need help: mounting usb devices on headless machines In-Reply-To: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> Message-ID: <46a038f90808070219k605b0716q12eeb8cdc8dd5e8f@mail.gmail.com> On Thu, Aug 7, 2008 at 6:37 PM, Martin Langhoff wrote: > Option two - help me package & tweak usbmount for F7 and F9. The > codebase is *tiny*, we can carry it. ... > I'll probably start chipping away at #2 tomorrow... FWIW, I've imported the history into git, made some minor changes and it installs and works on F7. git git://dev.laptop.org/users/martin/usbmount.git gitweb http://dev.laptop.org/git?p=users/martin/usbmount.git;a=summary Now, about those beeps... 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 mpgritti at gmail.com Thu Aug 7 17:38:05 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Thu, 07 Aug 2008 19:38:05 +0200 Subject: Help with admin tasks Message-ID: <489B32FD.9000707@gmail.com> Hello, we need to tag the following package for dist-olpc3: sugar-base-0.82.1-1.fc9 sugar-datastore-0.82.0-1.fc9 sugar-toolkit-0.82.0-1.fc9 sugar-artwork-0.82.0-1.fc9 sugar-0.82.0-1.fc9 Dennis has been doing it for us, but he is not working for OLPC anymore. Suggestions on how to handle it in the future? It would be nice if either one of us could get permissions to tag these, or if a Fedora admin would make himself available to do it... Also I'm trying to build a package depending on the above sugar-toolkit, but the old version is pulled (the new one was built a couple of hours ago). http://koji.fedoraproject.org/koji/taskinfo?taskID=765163 Any idea why it's not in the buildroot yet? Thanks! Marco From rnorwood at redhat.com Thu Aug 7 19:03:05 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Thu, 7 Aug 2008 15:03:05 -0400 Subject: Help with admin tasks In-Reply-To: <489B32FD.9000707@gmail.com> References: <489B32FD.9000707@gmail.com> Message-ID: <20080807150305.43827bd6@solitude.devel.redhat.com> On Thu, 07 Aug 2008 19:38:05 +0200 Marco Pesenti Gritti wrote: > Hello, > > we need to tag the following package for dist-olpc3: > > sugar-base-0.82.1-1.fc9 > sugar-datastore-0.82.0-1.fc9 > sugar-toolkit-0.82.0-1.fc9 > sugar-artwork-0.82.0-1.fc9 > sugar-0.82.0-1.fc9 > > Dennis has been doing it for us, but he is not working for OLPC > anymore. Suggestions on how to handle it in the future? It would be > nice if either one of us could get permissions to tag these, or if a > Fedora admin would make himself available to do it... If you can hop on #fedora-admin on freenode and talk to Jesse Keating (f13) and/or Mike McGrath (mmcgrath), they are probably the right people to talk to to work this out. There's also a ticketing system: https://fedorahosted.org/fedora-infrastructure/report To submit requests like this, but I think some discussion is probably warranted first. I'm also on that channel (rnorwood), but those are the guys who know koji and have the authority to fix things up for you. Once you have permissions, it's as easy as: koji tag-pkg [options] [...] > Also I'm trying to build a package depending on the above > sugar-toolkit, but the old version is pulled (the new one was built a > couple of hours ago). > > http://koji.fedoraproject.org/koji/taskinfo?taskID=765163 > > Any idea why it's not in the buildroot yet? If this is the one you mean: http://koji.fedoraproject.org/koji/buildinfo?buildID=58912 then it looks like it's in 'dist-f9-updates-candidate', which is not used to build new things against. You can either get the above package tagged in dist-f9-updates (I think), or use a chain build: http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained_builds -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From dennis at ausil.us Thu Aug 7 19:56:13 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Thu, 7 Aug 2008 14:56:13 -0500 Subject: Help with admin tasks In-Reply-To: <489B32FD.9000707@gmail.com> References: <489B32FD.9000707@gmail.com> Message-ID: <200808071456.15756.dennis@ausil.us> On Thursday 07 August 2008 12:38:05 pm Marco Pesenti Gritti wrote: > Hello, > > we need to tag the following package for dist-olpc3: > > sugar-base-0.82.1-1.fc9 > sugar-datastore-0.82.0-1.fc9 > sugar-toolkit-0.82.0-1.fc9 > sugar-artwork-0.82.0-1.fc9 > sugar-0.82.0-1.fc9 all tagged From mpgritti at gmail.com Thu Aug 7 21:30:49 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Thu, 07 Aug 2008 23:30:49 +0200 Subject: Help with admin tasks In-Reply-To: <20080807150305.43827bd6@solitude.devel.redhat.com> References: <489B32FD.9000707@gmail.com> <20080807150305.43827bd6@solitude.devel.redhat.com> Message-ID: <489B6989.6030006@gmail.com> Robin Norwood wrote: > On Thu, 07 Aug 2008 19:38:05 +0200 > Marco Pesenti Gritti wrote: > > >> Hello, >> >> we need to tag the following package for dist-olpc3: >> >> sugar-base-0.82.1-1.fc9 >> sugar-datastore-0.82.0-1.fc9 >> sugar-toolkit-0.82.0-1.fc9 >> sugar-artwork-0.82.0-1.fc9 >> sugar-0.82.0-1.fc9 >> >> Dennis has been doing it for us, but he is not working for OLPC >> anymore. Suggestions on how to handle it in the future? It would be >> nice if either one of us could get permissions to tag these, or if a >> Fedora admin would make himself available to do it... >> > > If you can hop on #fedora-admin on freenode and talk to Jesse Keating > (f13) and/or Mike McGrath (mmcgrath), they are probably the right > people to talk to to work this out. There's also a ticketing system: > > https://fedorahosted.org/fedora-infrastructure/report > > To submit requests like this, but I think some discussion is probably > warranted first. I'm also on that channel (rnorwood), but those are > the guys who know koji and have the authority to fix things up for > you. Once you have permissions, it's as easy as: > > koji tag-pkg [options] [...] > > Will do, thanks. >> Also I'm trying to build a package depending on the above >> sugar-toolkit, but the old version is pulled (the new one was built a >> couple of hours ago). >> >> http://koji.fedoraproject.org/koji/taskinfo?taskID=765163 >> >> Any idea why it's not in the buildroot yet? >> > > If this is the one you mean: > > http://koji.fedoraproject.org/koji/buildinfo?buildID=58912 > > then it looks like it's in 'dist-f9-updates-candidate', which is not > used to build new things against. > > You can either get the above package tagged in dist-f9-updates (I > think), or use a chain build: > > http://fedoraproject.org/wiki/PackageMaintainers/UsingKoji#Chained_builds > > Any idea what this error is about? Perhaps I'm doing something stupid... [marco at localhost F-9]$ make chain-build CHAIN="sugar-toolkit" Packages in destination tag dist-f9-updates-candidate are not inherited by build tag dist-f9-build Target dist-f9-updates-candidate is not usable for a chain-build make: *** [chain-build] Error 1 (I resorted to a little hack to build sugar-journal since I needed it urgently, but I'd still like to learn how to do this properly) Cheers, Marco From jwilliam at xmission.com Thu Aug 7 22:15:12 2008 From: jwilliam at xmission.com (Jerry Williams) Date: Thu, 7 Aug 2008 16:15:12 -0600 Subject: Sugar on Fedora 10 Alpha - how to I run it? Message-ID: <28FFE5E2034D440580AA911F4DA13402@Q9450> I noticed that there is a sugar-desktop group on Fedora 10 Alpha. How do I run it? I tried running sugar-shell and it kind of works, but not like it is suppose to. Any help would be appreciated, Jerry Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpgritti at gmail.com Thu Aug 7 22:20:59 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Fri, 08 Aug 2008 00:20:59 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <28FFE5E2034D440580AA911F4DA13402@Q9450> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> Message-ID: <489B754B.5040409@gmail.com> Jerry Williams wrote: > > I noticed that there is a sugar-desktop group on Fedora 10 Alpha. > > How do I run it? > > I tried running sugar-shell and it kind of works, but not like it is > suppose to. > Hello, the packages we have currently in Fedora are only sort of functional. We are going to release Sugar 0.82 this week and I really want to get it working well, both in Fedora 9 and rawhide. The big chunk of work will be to package activities... if someone on this list is interested to help packaging them, it would be a great help! Marco From rodrigopadula at projetofedora.org Thu Aug 7 23:13:59 2008 From: rodrigopadula at projetofedora.org (Rodrigo Padula de Oliveira) Date: Thu, 07 Aug 2008 20:13:59 -0300 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489B754B.5040409@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> Message-ID: <489B81B7.9040308@projetofedora.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marco Pesenti Gritti escreveu: | Jerry Williams wrote: |> |> I noticed that there is a sugar-desktop group on Fedora 10 Alpha. |> |> How do I run it? |> |> I tried running sugar-shell and it kind of works, but not like it is |> suppose to. |> | | Hello, | | the packages we have currently in Fedora are only sort of functional. We | are going to release Sugar 0.82 this week and I really want to get it | working well, both in Fedora 9 and rawhide. The big chunk of work will | be to package activities... if someone on this list is interested to | help packaging them, it would be a great help! | | Marco | | _______________________________________________ | Fedora-olpc-list mailing list | Fedora-olpc-list at redhat.com | https://www.redhat.com/mailman/listinfo/fedora-olpc-list | Can i help with the activities packages ?? How can i do that ? One activity per package or one package with many activities ? - -- Rodrigo Padula de Oliveira M.Sc. Student - COPPE/UFRJ Fedora Community Manager - Latin America http://www.proyectofedora.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkibgbIACgkQ024P1ALZT55wcQCfYbx6rErAd26xwYZArxqteCJE EAgAn3d4P9qPONE/pDZKNsf8/jUha+wy =3Jmr -----END PGP SIGNATURE----- From martin.langhoff at gmail.com Fri Aug 8 00:13:11 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 8 Aug 2008 12:13:11 +1200 Subject: Need help: mounting usb devices on headless machines In-Reply-To: <46a038f90808070219k605b0716q12eeb8cdc8dd5e8f@mail.gmail.com> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <46a038f90808070219k605b0716q12eeb8cdc8dd5e8f@mail.gmail.com> Message-ID: <46a038f90808071713t7123500q92d554ce60cfb972@mail.gmail.com> On Thu, Aug 7, 2008 at 9:19 PM, Martin Langhoff wrote: > FWIW, I've imported the history into git, made some minor changes and > it installs and works on F7. > > git > git://dev.laptop.org/users/martin/usbmount.git > > gitweb > http://dev.laptop.org/git?p=users/martin/usbmount.git;a=summary Right, Makefile and spec file in the repo linked above, initial SRPM right here. http://fedora.laptop.org/xs/testing/olpc/7/source/SRPMS/usbmount-0.15.4.olpc-1.xs7.src.rpm It's a trivial rpm, review & patches welcome. 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 Fri Aug 8 00:18:30 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Fri, 08 Aug 2008 05:48:30 +0530 Subject: Need help: mounting usb devices on headless machines In-Reply-To: <46a038f90808071713t7123500q92d554ce60cfb972@mail.gmail.com> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <46a038f90808070219k605b0716q12eeb8cdc8dd5e8f@mail.gmail.com> <46a038f90808071713t7123500q92d554ce60cfb972@mail.gmail.com> Message-ID: <489B90D6.6070105@fedoraproject.org> Martin Langhoff wrote: > On Thu, Aug 7, 2008 at 9:19 PM, Martin Langhoff > wrote: > >> FWIW, I've imported the history into git, made some minor changes and >> it installs and works on F7. >> >> git >> git://dev.laptop.org/users/martin/usbmount.git >> >> gitweb >> http://dev.laptop.org/git?p=users/martin/usbmount.git;a=summary >> > > Right, Makefile and spec file in the repo linked above, initial SRPM right here. > http://fedora.laptop.org/xs/testing/olpc/7/source/SRPMS/usbmount-0.15.4.olpc-1.xs7.src.rpm > > It's a trivial rpm, review & patches welcome Are you going to submit it for review in Fedora? Rahul From martin.langhoff at gmail.com Fri Aug 8 00:23:46 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 8 Aug 2008 12:23:46 +1200 Subject: Need help: mounting usb devices on headless machines In-Reply-To: <489B90D6.6070105@fedoraproject.org> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <46a038f90808070219k605b0716q12eeb8cdc8dd5e8f@mail.gmail.com> <46a038f90808071713t7123500q92d554ce60cfb972@mail.gmail.com> <489B90D6.6070105@fedoraproject.org> Message-ID: <46a038f90808071723k128b30e8w506cb50394fb4624@mail.gmail.com> On Fri, Aug 8, 2008 at 12:18 PM, Rahul Sundaram wrote: > Are you going to submit it for review in Fedora? I don't think so - as I mentioned before, upstream is mostly dead, so I doubt it'll be accepted. Trivial as it is, I am happy to support it for as long as we have a use for it within XS. If something better comes up, we'll switch in a blink. Supporting it for Fedora is a wider (more varied uses) and longer timeframe. 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 simon at schampijer.de Fri Aug 8 07:55:23 2008 From: simon at schampijer.de (Simon Schampijer) Date: Fri, 08 Aug 2008 09:55:23 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489B81B7.9040308@projetofedora.org> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> Message-ID: <489BFBEB.3070607@schampijer.de> Rodrigo Padula de Oliveira wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Marco Pesenti Gritti escreveu: > | Jerry Williams wrote: > |> > |> I noticed that there is a sugar-desktop group on Fedora 10 Alpha. > |> > |> How do I run it? > |> > |> I tried running sugar-shell and it kind of works, but not like it is > |> suppose to. > |> > | > | Hello, > | > | the packages we have currently in Fedora are only sort of functional. We > | are going to release Sugar 0.82 this week and I really want to get it > | working well, both in Fedora 9 and rawhide. The big chunk of work will > | be to package activities... if someone on this list is interested to > | help packaging them, it would be a great help! > | > | Marco > | > | _______________________________________________ > | Fedora-olpc-list mailing list > | Fedora-olpc-list at redhat.com > | https://www.redhat.com/mailman/listinfo/fedora-olpc-list > | > > > Can i help with the activities packages ?? Sure you are welcome :) > How can i do that ? One activity per package or one package with many > activities ? It will be a package per activity. These are the latest sources for the activities: http://sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.82.0#Fructose_modules And here you can find the journal - an example of a packaged activity http://koji.fedoraproject.org/koji/buildinfo?buildID=58964 We will put up some more detailed instructions in the next days. Best, Simon From mpgritti at gmail.com Fri Aug 8 08:11:08 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Fri, 08 Aug 2008 10:11:08 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489BFBEB.3070607@schampijer.de> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> Message-ID: <489BFF9C.1070208@gmail.com> Simon Schampijer wrote: > Rodrigo Padula de Oliveira wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Marco Pesenti Gritti escreveu: >> | Jerry Williams wrote: >> |> >> |> I noticed that there is a sugar-desktop group on Fedora 10 Alpha. >> |> >> |> How do I run it? >> |> >> |> I tried running sugar-shell and it kind of works, but not like it is >> |> suppose to. >> |> >> | >> | Hello, >> | >> | the packages we have currently in Fedora are only sort of >> functional. We >> | are going to release Sugar 0.82 this week and I really want to get it >> | working well, both in Fedora 9 and rawhide. The big chunk of work will >> | be to package activities... if someone on this list is interested to >> | help packaging them, it would be a great help! >> | >> | Marco >> | >> | _______________________________________________ >> | Fedora-olpc-list mailing list >> | Fedora-olpc-list at redhat.com >> | https://www.redhat.com/mailman/listinfo/fedora-olpc-list >> | >> >> >> Can i help with the activities packages ?? > > Sure you are welcome :) > >> How can i do that ? One activity per package or one package with many >> activities ? > > It will be a package per activity. > > These are the latest sources for the activities: > http://sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.82.0#Fructose_modules > > > And here you can find the journal - an example of a packaged activity > http://koji.fedoraproject.org/koji/buildinfo?buildID=58964 And here are the guidelines: http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines A couple of things about them: * For Fructose activities you don't need to get the source from git, tarballs are available at the url Simon posted. * Translation packaging is not explained in the guidelines, you can see how it's done in the journal. Though I'd really like to figure out a more automatic way to do it (perhaps we can add another macro to sugar-toolkit to deal with it?) I'd suggest to start from chat, log, calculate, terminal and pippy. Those does not have dependencies issues. If you want to join #sugar on freenode we can help you out with any problem you run into (or feel free to use this mailing list if you prefer). Cheers, Marco From simon at schampijer.de Fri Aug 8 10:48:47 2008 From: simon at schampijer.de (Simon Schampijer) Date: Fri, 08 Aug 2008 12:48:47 +0200 Subject: Help with admin tasks In-Reply-To: <489B6989.6030006@gmail.com> References: <489B32FD.9000707@gmail.com> <20080807150305.43827bd6@solitude.devel.redhat.com> <489B6989.6030006@gmail.com> Message-ID: <489C248F.10508@schampijer.de> Marco Pesenti Gritti wrote: > Robin Norwood wrote: >> On Thu, 07 Aug 2008 19:38:05 +0200 >> Marco Pesenti Gritti wrote: >> >> >>> Hello, >>> >>> we need to tag the following package for dist-olpc3: >>> >>> sugar-base-0.82.1-1.fc9 >>> sugar-datastore-0.82.0-1.fc9 >>> sugar-toolkit-0.82.0-1.fc9 >>> sugar-artwork-0.82.0-1.fc9 >>> sugar-0.82.0-1.fc9 >>> >>> Dennis has been doing it for us, but he is not working for OLPC >>> anymore. Suggestions on how to handle it in the future? It would be >>> nice if either one of us could get permissions to tag these, or if a >>> Fedora admin would make himself available to do it... >>> sugar-presence-service-0.82.1-1.fc9 sugar-journal-97-2.fc9 Those are the latest ones. Dennis can you tag those in? Many thanks, Simon From dennis at ausil.us Fri Aug 8 13:20:18 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Fri, 8 Aug 2008 08:20:18 -0500 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489BFF9C.1070208@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> Message-ID: <200808080820.18578.dennis@ausil.us> On Friday 08 August 2008 03:11:08 am Marco Pesenti Gritti wrote: > And here are the guidelines: > > http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines > > A couple of things about them: > > * For Fructose activities you don't need to get the source from git, > tarballs are available at the url Simon posted. > * Translation packaging is not explained in the guidelines, you can see > how it's done in the journal. Though I'd really like to figure out a > more automatic way to do it (perhaps we can add another macro to > sugar-toolkit to deal with it?) > I'd suggest to start from chat, log, calculate, terminal and pippy. > Those does not have dependencies issues. Actually they do. pippy for instance Requires gtksourceview they are just hidden on the XO because we make sure they are installed in the OS. Dennis From mpgritti at gmail.com Fri Aug 8 13:20:47 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Fri, 08 Aug 2008 15:20:47 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <200808080820.18578.dennis@ausil.us> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <200808080820.18578.dennis@ausil.us> Message-ID: <489C482F.6080303@gmail.com> Dennis Gilmore wrote: >> I'd suggest to start from chat, log, calculate, terminal and pippy. >> Those does not have dependencies issues. >> > Actually they do. pippy for instance Requires gtksourceview they are just > hidden on the XO because we make sure they are installed in the OS. > What I mean is that all the dependency they need are already in Fedora (afaik). If you are referring to Pippy requiring an old gtksourceview which is no more in F9, that's fixed in recent pippy versions. Marco From katzj at redhat.com Fri Aug 8 14:21:58 2008 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 08 Aug 2008 10:21:58 -0400 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489BFF9C.1070208@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> Message-ID: <1218205318.22759.4.camel@aglarond.local> On Fri, 2008-08-08 at 10:11 +0200, Marco Pesenti Gritti wrote: > * Translation packaging is not explained in the guidelines, you can see > how it's done in the journal. Though I'd really like to figure out a > more automatic way to do it (perhaps we can add another macro to > sugar-toolkit to deal with it?) My first and most obvious question is "why not put translations into /usr/share/locale like they're supposed to be"? But ignoring that, it should be easy enough to hack up a copy of /usr/lib/rpm/find-lang.sh and put it in the sugar-toolkit package and then have %find_lang_sugar I guess > I'd suggest to start from chat, log, calculate, terminal and pippy. > Those does not have dependencies issues. I've already got a package up for terminal at https://bugzilla.redhat.com/show_bug.cgi?id=457247 Calculate and chat I also have srpms/spec files for and should have them filed for review later today Jeremy From simon at schampijer.de Fri Aug 8 14:34:52 2008 From: simon at schampijer.de (Simon Schampijer) Date: Fri, 08 Aug 2008 16:34:52 +0200 Subject: Help with admin tasks In-Reply-To: <489C248F.10508@schampijer.de> References: <489B32FD.9000707@gmail.com> <20080807150305.43827bd6@solitude.devel.redhat.com> <489B6989.6030006@gmail.com> <489C248F.10508@schampijer.de> Message-ID: <489C598C.6040009@schampijer.de> Simon Schampijer wrote: > Marco Pesenti Gritti wrote: >> Robin Norwood wrote: >>> On Thu, 07 Aug 2008 19:38:05 +0200 >>> Marco Pesenti Gritti wrote: >>> >>> >>>> Hello, >>>> >>>> we need to tag the following package for dist-olpc3: >>>> >>>> sugar-base-0.82.1-1.fc9 >>>> sugar-datastore-0.82.0-1.fc9 >>>> sugar-toolkit-0.82.0-1.fc9 >>>> sugar-artwork-0.82.0-1.fc9 >>>> sugar-0.82.0-1.fc9 >>>> >>>> Dennis has been doing it for us, but he is not working for OLPC >>>> anymore. Suggestions on how to handle it in the future? It would be >>>> nice if either one of us could get permissions to tag these, or if a >>>> Fedora admin would make himself available to do it... >>>> > > sugar-presence-service-0.82.1-1.fc9 got replaced by sugar-presence-service-0.82.2-1.fc9 thanks, Simon > sugar-journal-97-2.fc9 > > Those are the latest ones. Dennis can you tag those in? > > Many thanks, > Simon > From jg at laptop.org Fri Aug 8 15:01:08 2008 From: jg at laptop.org (Jim Gettys) Date: Fri, 08 Aug 2008 11:01:08 -0400 Subject: Introduction... (and OLPC Fedora spin). Message-ID: <1218207668.8502.62.camel@jg-vaio> Hi, I'm Jim Gettys, and I worry about much of OLPC's software and how it fits together.... This instant, I've been investigating with Gregdec and Sebastian Dziallas the feasibility of a more "conventional" fedora desktop to run on the OLPC. The observed problem is that many people who get OLPC's as part of G1G1 often don't read our warnings, and end up unhappy that they get only Sugar, no email program, etc.... Since it is called a "laptop" they have preconceptions kids don't. Sebastian has done a spin that is only 550 megabytes (squashfs, so in jffs2 it would be somewhat bigger) for a small set of western languages. This isn't runnable yet (on the OLPC), but shows something useful can easily fit. It turns out that several hundred megabytes are just fonts and other localization files for Japanese, Chinese, etc. And yes, the intent would be sugar would be included in this spin (whether all common activities will fit, is much less clear). If we go ahead with this, we'll need all the help we can get from fedora folks.... In the fullness of time, nirvana would be that fedora might be configured small enough (in a simple way) to at least match the size of the minimal OLPC load (which is several hundred megabytes smaller). This space is needed so that flash can be used mostly for books and other content on 1 gig systems. If so, the OLPC software for the XO could become just a fedora spin. Whether nirvana can be reached isn't yet clear; lots of people are very sloppy about dependencies, and some essential pieces are currently huge for bad reasons (like all glibc locales live in the same file...). - Jim -- Jim Gettys One Laptop Per Child From gdk at redhat.com Fri Aug 8 15:44:25 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 8 Aug 2008 11:44:25 -0400 (EDT) Subject: Kickoff meeting: 1700 UTC / 1pm Eastern US time today Message-ID: We've been talking about it. Now we'll have it. Join us on freenode, #fedora-olpc, at time in $SUBJECT. The primary topics: * Sugar on Fedora. How's it going? What's our goal? How do we create and track actionable work items? * Fedora on OLPC. Ditto. * Other business people want to discuss. See you all at 1pm Eastern US time. --g From dfarning at sugarlabs.org Fri Aug 8 16:00:40 2008 From: dfarning at sugarlabs.org (David Farning) Date: Fri, 08 Aug 2008 11:00:40 -0500 Subject: Introduction... (and OLPC Fedora spin). In-Reply-To: <1218207668.8502.62.camel@jg-vaio> References: <1218207668.8502.62.camel@jg-vaio> Message-ID: <1218211240.24038.448.camel@dfarning.desktop.org> On Fri, 2008-08-08 at 11:01 -0400, Jim Gettys wrote: > Hi, > > I'm Jim Gettys, and I worry about much of OLPC's software and how it > fits together.... > > This instant, I've been investigating with Gregdec and Sebastian > Dziallas the feasibility of a more "conventional" fedora desktop to run > on the OLPC. This is an excellent idea. The is a tremendous amount of development potential in the operating system part of the OLPC stack. By being able to 'set' multiply desktops on top of stack we can better isolate the problem areas, encourage more widespread engagement in os development, and give the customer what they want. This position might seem ironic given my strong support for sugar. I would like Sugar to become the desktop of choice in certain educational setting because it is the best. Not, because it is the only choice. > Whether nirvana can be reached isn't > yet clear; lots of people are very sloppy about dependencies, and some > essential pieces are currently huge for bad reasons (like all glibc > locales live in the same file...). A thought here is to get in touch with the embedded projects like openembedded, Linux base routers, and mobile devices. These projects are getting very good at stripping the unneeded bit from packages. I can imaging Fedora as a whole benefiting from some ruthless dependency chopping;) dfarning From rnorwood at redhat.com Fri Aug 8 18:24:34 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Fri, 8 Aug 2008 14:24:34 -0400 Subject: Meeting Minutes Friday, August 08 2008 Message-ID: <20080808142434.7bde2ed6@solitude.devel.redhat.com> Hi, Here are the TODOs from the meeting: ** TODO: jeremy to build table of sugar activities and other packaging work items on the Fedora wiki ** TODO: Various people to take items from that list and package them ** TODO: jeremy to go to 1cc, revisit next week. ** TODO: rnorwood to track down the squeek/etoys licensing issues ** TODO: gavin to track down the squeek binary blob issue ** TODO: rnorwood to send out minutes Next Meeting: 1700 UTC / 1pm Eastern US time Friday, Aug 15 Here is a rough IRC transcript. I tried to break things out by topic and clean up some chatter. I spent the week at OLPC HQ in Cambridge... (yes, cjb, can you do that? thx) ...and learned a whole bunch of stuff, and articulated some goals a bit more clearly. So I'm going to throw out a couple of projects that I think could be (relatively) low impact and (relatively) high reward, and then open the floor for discussion about what it'll take to get there. ** TOPIC: Sugar spin for Fedora, including bootable live CD. POTENTIAL PROJECT #1: The Sugar spin for Fedora, including bootable Live CD. WHY? Because there aren't enough developers who can just take Sugar for a spin without lots of bizarre incantations. By building and maintaining the Sugar packages in Fedora (and elsewhere, but we care about Fedora) we can dramatically expand the "geek user base" and thus the potential developer base. So that's the goal. ...let's dig into that. a piece of this project is helping marco with packaging of sugar, and testing.... that's actually probably one of the bigger pieces to be honest We've got people already digging into building Sugar packages. first step is that sugar becomes another desktop like gnome or kde, and you log into sugar. First step is that we get all the important packages built. :) gregdek: very much so "yum install sugar" should be the goal ;-). * jeremy has started making some progress there jg: 'yum groupinstall sugar-desktop' but yes :) marco has the base packages packaged; but activities are not packaged as rpms'. the wishlist is currently here: http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist Actually, this list represents multiple projects, and I wonder if we should be breaking them out and tracking each project's needs separately. For example: * XS packages * Fedora on XO hardware packages * Sugar on Fedora packages So the next question: is the current wishlist-on-wiki mechanism the right one? Is it true that SL is trying to create different levels of Sugar activities to indicate relative levels of stability? Hm, don't think that's been ratified properly. But we've certainly struggled with that question in lots of places. For example, just for OLPC -- which activities should OLPC "support"? as few as possible ;-)... My sense is that some activities are "core" to the sugar experience and should definitely be prioritized. and as many as necessary ;-) journal, browser, pippy, for example. jg: You are a master of policy declaration. ;) Yeah. We've sort of used the list activities we shipped with the original G1G1 as that list of "core", but not all of them are actually maintained. Doh. So I assume that there will exist, at some point, a set of guidelines for what are "supported" and "unsupported" activities that fall out of Sugar Labs discussions. But until that point, what's our policy? "Package what we can find tarballs for"? gregdek: It's a bit of a bone of contention, but the G1G1 set seems agreeable. (And I think it's what's been packaged already.) gregdek, cjb: or as a priority, we might want to package whatever is there in http://sugarlabs.org/go/ReleaseTeam/Roadmap#Fructose_Modules unmadindu: yup, looks right unmadindu: that's probably as good of a starting place as any Don't we have packaging guidelines for activities already for activities on the Fedora wiki? gregdek: http://fedoraproject.org/wiki/Packaging/SugarActivityGuidelines gregdek: the language issue that jeremy pointed out on the ML being the biggest issue, It hink. rnorwood: there are a couple of other things that feel like they could be better after doing a couple of pakcages. once I have a few more done, I suspect I'll have a better feel for "right"-ness gregdek: that's required for inclusion in fedora So we're basically packaging these directly from the source. Which means we are making rpms rather than xos. gregdek: I think in fedora terms, we just ignore the concept of .xos I think that has to be right. Yeah. :) There have been "why not make .rpm be the .xo file format?" discussions, I don't recall the outcomes. cjb: and while that seems an interesting discussion, perhaps a tangent for this meeting :) So let me spell out the simple action items so far: * Split out the wishlist into appropriate package sets (XS, Fedora for XO, Sugar for Fedora, activities) * Point folks in the wishlist to Fructose/Sucrose list and activity packaging guidelines so this means there will be two formats used for installing activities? rpm and xo? (i'm just trying to understand.) pgf_: It's a fair question. pgf_: Users will always have the option to install .xo files locally. pgf_: for a conventional fedora desktop, you'd like to be able to do a yum install.... okay. i'm convinced. :-) One other thing: Is it possible to associate a date with the wishlist items, so we know which stuff has just been sitting, if it comes to that? Or is that overkill? gregdek: It's good practice to include a date, yeah. heh. I think it makes sense if someone's name is also attached.... Well, that's where I was going next... :) Or at least be able to say "unclaimed" or something. We edge closer to trac tickets with every data field we add... but I'd kind of like to hold off yet. :) gregdek: so when you start work on 'something', attach your name and date. Add links to issues/bugs/discussion as needed, and remove it when it's accepted into fedora. * jeremy is making a table for the activities that should help... Thanks, jeremy. :) Hey jeremy, since you're building the table, do you want to do the initial sort of the packages too? I'm trying to do that too Very good. * gregdek writes down "jeremy" in the big book of TODOs. So down the line, once we've got these packages in... ** TODO: jeremy to build table of sugar activities to package as work items. ...the next question is "what needs to happen to allow us to boot Fedora into Sugar instead of GNOME/KDE/xfce/wtfwm? Can we add this feature to the F10 roadmap? gregdek: it should be easy to do when we update the sugar packages. I can work with marco to make sure it happens Needs a feature owner. jeremy, will that be you, too? gregdek: but the feature is a little bit more than GDM. rnorwood: Such as? Maybe someone needs to write a feature spec. Someone who volunteers the notion that "the feature is a little bit more than GDM," maybe. gregdek: well, just 'make sugar work' and the other stuff we're already planning to do. gregdek: 'sugar works and a reasonable set of activities packaged' I can probably throw the start together and then make rnorwood help ;) ...my take: if the feature is "allow GDM to boot Sugar in F10," that sort of encapsulates all the rest of the work, yeah. ...I kinda think that covers must of the "Sugar on Fedora" ground, amirite? gregdek: yup. Jeremy to do initial feature page, and press-gang rnorwood to help ** TODO: jeremy to build initial ** TOPIC: Fedora on the XO WHY? Because Sugar isn't "there" yet for a large segment of the XO/G1G1 userbase, and despite numerous warnings that it's "not a laptop project", people continue to expect it to be a standard laptop. Which means that we're exploring dual-boot options of "Sugar" or "some minimal straight Fedora". Which means that we need to build a "minimal straight Fedora" that actually boots on the XO. Which depends on people who have the hardware! which depends on people that have the hardware the thing that I don't entirely understand (maybe because I haven't played with the hardware as much) is why this really entails any sort of separate spin rnorwood: the problem is, then our friends in redmond have another weapon. and isn't just people making sure the hardware is well supported in fedora jeremy: size. Other than a different kernel and some dependency breakdowns... jeremy: RAM usage of some apps. ...but maybe this is an opportunity to break down some deps in Fedora itself. jeremy: audience.... gregdek: yeah, definitely! Like the fact that PersonalCopy-Lite is the biggest package in the spin currently. :) jg: RAM usage of the apps -- fix the apps, don't skirt the issue by forking things jeremy: somehow, fixing evolution ain't going to happen overnight. jeremy: I need something *quickly*. gregdek: I was able to ship around this libgweather stuff (it was NetworkManager-gnome related), but this one could be fixed, too and if the idea is that people with a g1g1 think that the xo is a laptop and expect it to act like one, then they're going to just expect fedora to *WORK* not go use some weird off to the side thing sdziallas: on a side note, could you send me the kickstart file? bkearney at redhat.com? bryan_kearnay: sure :) jeremy: we have at least two alternatives for mail: thunderbird and claws. I think that there's the ideal, and then there's the pragmatic. evo is not required. jg: agreed! and it will send an interesting message to the evo folks ;-). The pragmatic: we must provide *something* that is more familiar than Sugar. jg: both of which are similarly bad in memory usage to evo (or worse in some cases). I've used them all :( so - 1) Hardware support/kernel, 2) Install size/deps, 3) RAM usage of some apps/evolution sucks Even if it's not the best Fedora experience one might otherwise have. jeremy: but evo comes with 50 meg of help png images: we can't afford the flash load for evo. what about gnome/xfce ? jeremy: need a "run out of flash" option. The spin sebastian made was xfce-based. I think we're going to want GNOME rnorwood: that is another option. (vs) oh :) :) bryan_kearnay: e-mail's out well, I'd have wanted, too So here's my question. first thing to do is to get one working, and look at the RAM footprint. I'd like the full NM applet, full i18n, that kind of stuff. Can straight Fedora work, if the kernel issue is sorted? heh. jg: it depends on what you're targeting as to what the need is plus we know a lot more about hacking on GNOME than on xfce, speaking for the people in this channel. Ii8n is another problem. jg: if you have more you're not saying that flows into the need, I'm ears :) but nothing that's been said thus far really sounds like that's the case turns out that the stock fedora CD space is is dominated by eastern fonts and input methods. I don't want to end up in a situation where we get xfce and then we get feature requests on high to add features to xfce that GNOME already has :) well, when doing the test runs on my machine here, every gnome-based image was at least 100 mb larger than the xfce-based one cjb: -EINGNOMEALREADYWONTFIX I just want us to get to something that boots. That's the first step. :) that'd be a good start, indeed. jeremy: the same people who buy and OLPC thinking it is a conventional laptop (despite our warnings) are the kind that want something a bit more than xfce (at least when I've played with it). gregdek: I agree entirely. that's the next step. now we know we can build spins that are acceptably small. >walters< That was quick. ;-) walters probably has some feedback about gnome-vs-xfce on fedora-XO spin jeremy is coming to 1cc next week! yay! That's the resolution. You guys can slug it out. Just get something that boots plz, kthxbye. :) sounds good. if anyone comes up with any hard data on why/how xfce is smaller please do let me know and greg is now a lolcat walters: I suspect icon files. I haven't gone and looked carefully. hai! can i haz bootfedoraxo? jg: elaborate? walters: this is just a preliminary discussion, not 'decision time', fwiw there are png files for several sizes of all the icons. walters: fewer deps. we can pick just one. Yes. and nuke the others. We can just pick one. jg, gregdek: +1 :) When the time is right, we can do all these things. By the way, dwmw2 boots stock Fedora on external USB hard disks. Oh, he does, does he? so I don't think there are any large obstacles. someone mentioned a kernel problem of some kind? I wonder why that didn't work for us? heh. Maybe we just used the wrong incantation. different incantations. I'm not an OFW incantation expert. yeah, seems like it should have worked, with F9. ah, that might be it. cjb: no, some stuff went in after F9. All right. to kernel.org. I think the devil is in the details here... I betcha you need an updated kernel. ...and I think we can trust jeremy to sort these out in 1cc next week and report back next Friday? bah, who runs f9 anywya? rawhide everywhere! maybe. you could even just use our kernel. and our kernel still carries patches not yet in kernel.org. that's the plan. Brillianr. t. cjb: or maybe you could just use ours ;) we should also talk about getting a Rawhide OLPC stream at some point. We're on F9 now, but we can rebase to F10 for our next release (due around Christmas, I guess) jeremy: we're trying! Heh. ofw2 will probably make it much easier for a generic linux kernel to "just work". I think everything to enable booting an XO on stock distros is upstream now OK. but right now, it won't. So... which is a pretty big step, it took a lot of work, we have custom display hardware and all that stuff --- stickster is now known as stickster_mtg cjb: but you still have to build for OLPC. ** TODO: jeremy to go to 1cc, revisit next week. ** TOPIC: Squeek/etoys licensing. VPRI believes that they have done enough work to change the licence to MIT, Will Red Hat legal except that, or ....? gavin_: there is *no* license issue for squeak now, I'm aware of. gavin_: spot is The Legal Contact. Yeah, so what are we talking about? the last sillyness is that squeak has a binary blob, not rebuilt each time. Right. That's the real pain, from what I hear. likewise. VPRI say it's now BSD-licensed, I don't see who we are to argue with them. Do we know why that is? said binary blob can export every line of smalltalk that is in it. gregdek: it's just the development style. it's a feature. so it is sillyness of people who don't understand about smalltalk. gregdek: they come from a different school of programming. or similar environments. they have total introspection of the blob, so they don't feel a need to rebuilt it from scratch very often. the blob is the preferred format for modification for them. Right. Which our packaging standards totally don't account for. I don't think there's any legal issue here, just some people find it distasteful that they can't diff it etc. people who've never seen introspection, don't comprehend. So when you can actually create all source on the fly from the binary, you are by definition shipping source? Is that the contention? So are there tarball releases of squeek/etoys that say "I am MIT (or BSD) licenced"? the binary *is* the source. rnorwood: I believe so. gregdek: I think there is source available too? It's just that the interpreter isn't created from it each build. Or an SCM we can pull from? rnorwood: Absolutely. rnorwood: the scm is *inside* the squeak environment. rnorwood: The problem is that VPRI had a handful of decades-old contributors that they couldn't get agreement to change the license from. cjb: Ok - put it on the wishlist page ( http://fedoraproject.org/wiki/PackageMaintainers/WishList#OLPC_Wishlist ) it is entirely self-contained. And they decided, given like 490/500 people who agreed to the change and 10 who were uncontactable, to go ahead and change the license. I don't even know how to begin to tackle the packaging issues. Maybe someone can get this issue in front of FESCO? I think spot was dubious that that was legal. cjb: Yeah, that may or may not be a problem. Spot is the guy we need to interface with to get legal to make a call. cjb: that's pretty dubious So it comes down to: jeremy: They'd be happy to rip out those people's code if they complained. cjb: unless the contributions by those ten people are insignificant/obvious cjb: So Red Hat legal makes those calls for us. jeremy: I don't think any of them were major contributions cjb: the problem is that you have to assume they complain and rip the code out rnorwood: yeah. so, that's the problem, anyway. if I were a lawyer, I'd say "don't possibly do anything that sort of contributes risk to someone" So it's a matter of comparing Fedora's risk profile with VPRI's. cjb: ok - how about you, jg, and anyone else who wants to be on the Cc send me your email address and I'll start a conversation with spot about it. cjb: and see what he thinks the best way to proceed is. rnorwood: sounds good OK. Thanks, rnorwood. rnorwood: bert freudenberg is the other person to be involved, on the VPRI side. me too they've been working on for 20 years and then have some random other group tell them they aren't allowed to :) Well, it's tradeoffs, isn't it? "Hey, we'd like to make your software available in one click to millions more users. Accept or deny?" cjb: they can do whatever they want, but that just means that it can't be in fedora nod. >cjb< hey, what's your email addy so I can Cc: you on squeek/etoys >license issue I was planning on takeing the squeak blob issue to FONC ... does any one think that's unnecessary? Maybe wait for legal to come back? cjb: well, if the answer is 'Our lawyers say this is legally dubious, let us help you rip out the offending code...' jeremy: the've been leaning over backwards as it is; but people who don't bother to comprehend that environments like smalltalk are built in fundamentally different ways than UNIX/Linux and complain they are different (and they started first!), I have less patience for. don't conflate the legal issue with the blob issue. Agreed. gavin_: sure. jg: the blob issue is different from the licensing one If you want to attack both separately, that's fine. But understand that progress on one blocks implementation on the other. >gavin_< Do you want me to Cc you in convo about the license issue? If >so, what's your email addy? * jeremy knows he does not know enough right now about the blob to say anything intelligently one way or the other Doesn't mean the issues can't be worked in parallel. Just that there's risk that such work might end up useless. gregdek: +1. gavin_ to drive the blob issue, /me to drive the license issue. yes, the blob thing sounds like a non-issue. Some grumpy Debian people said that if it can't be diff'd it's not "open source", which is ridiculous. Heh. Let's try to be more reasonable than that. ;) ** TODO: rnorwood to track down the squeek/etoys licensing issues ** TODO: gavin to track down the squeek binary blob issue -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From mpgritti at gmail.com Sat Aug 9 08:36:58 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Sat, 09 Aug 2008 10:36:58 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <1218205318.22759.4.camel@aglarond.local> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> Message-ID: <489D572A.7060906@gmail.com> Jeremy Katz wrote: > On Fri, 2008-08-08 at 10:11 +0200, Marco Pesenti Gritti wrote: > >> * Translation packaging is not explained in the guidelines, you can see >> how it's done in the journal. Though I'd really like to figure out a >> more automatic way to do it (perhaps we can add another macro to >> sugar-toolkit to deal with it?) >> > > My first and most obvious question is "why not put translations > into /usr/share/locale like they're supposed to be"? XO Bundles, which are the normal activity distribution mechanism for OLPC are self contained. http://wiki.laptop.org/go/Activity_bundles Now, when installing into the system with rpm, it would actually make more sense to use the standard directory layout. I'm only a little worried that it would complicate the build system of activities which doesn't use Sugar bundlebuilder. Note that we have to extend/replace find-lang.sh regardless, to be aware of localized activity.info. > I've already got a package up for terminal at > https://bugzilla.redhat.com/show_bug.cgi?id=457247 > > Calculate and chat I also have srpms/spec files for and should have them > filed for review later today > Awesome! Marco From mikus at bga.com Sat Aug 9 13:08:18 2008 From: mikus at bga.com (Mikus Grinbergs) Date: Sat, 09 Aug 2008 09:08:18 -0400 Subject: Sugar on Fedora 10 Alpha - how to I run it? Message-ID: <489D96C2.3000608@bga.com> > Now, when installing into the system with rpm, it would actually make > more sense to use the standard directory layout. I'm only a little > worried that it would complicate the build system of activities which > doesn't use Sugar bundlebuilder. For me on my XO, it takes less effort to "upgrade" an already-installed build than to "install from scratch" a build, and then customize. I recently used 'yum install' to apply Journal-97 to Joyride. [That is, the Journal activity was packaged as an rpm.] It amused me that this "rpm" install did not update the version-number in the XO's activity registry. It remained for me to reboot before the registry showed that 97 had replaced 96. mikus From martin.langhoff at gmail.com Mon Aug 11 00:49:06 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 11 Aug 2008 12:49:06 +1200 Subject: [Server-devel] Need help: mounting usb devices on headless machines In-Reply-To: <20080807065242.GC11502@us.netrek.org> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <20080807065242.GC11502@us.netrek.org> Message-ID: <46a038f90808101749p72ac107buf96cb45da22b31d4@mail.gmail.com> On Thu, Aug 7, 2008 at 6:52 PM, James Cameron wrote: > Don't know about Fedoristas, but on Debian and derivatives this is what > I do for a backup disk that is identified by UUID and then backed up to > ... all when plugged in ... beep ... wait for rsync ... beep beep ... > pull it out. ... > echo -en '\007' > /dev/tty1 Well, it *seems* that I cannot get a bell to sound on any of the systems I can get my hands on today. 2 XS (F7, based) desktop machines, 3 different laptops (running F9, Hardy), no bell on ambiguous autocompletion, no audible response to echo -en '\007' on any tty. Nothing obvious in termcap/terminfo (I'm not too handy with those but no 'vb' that I can see). Hmmm. pcspkr.ko is loaded in all of them. And the web is full of advise on how to *disable* it, so I guess modern linuxen have disabled it en-masse, using some trick I can't spot right now. The obvious place is termcap/terminfo, but nothing there... Ah, grumble. ideas? 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 Mon Aug 11 01:19:57 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Mon, 11 Aug 2008 06:49:57 +0530 Subject: [Server-devel] Need help: mounting usb devices on headless machines In-Reply-To: <46a038f90808101749p72ac107buf96cb45da22b31d4@mail.gmail.com> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <20080807065242.GC11502@us.netrek.org> <46a038f90808101749p72ac107buf96cb45da22b31d4@mail.gmail.com> Message-ID: <489F93BD.5010902@fedoraproject.org> Martin Langhoff wrote: > On Thu, Aug 7, 2008 at 6:52 PM, James Cameron wrote: >> Don't know about Fedoristas, but on Debian and derivatives this is what >> I do for a backup disk that is identified by UUID and then backed up to >> ... all when plugged in ... beep ... wait for rsync ... beep beep ... >> pull it out. > ... >> echo -en '\007' > /dev/tty1 > > Well, it *seems* that I cannot get a bell to sound on any of the > systems I can get my hands on today. 2 XS (F7, based) desktop > machines, 3 different laptops (running F9, Hardy), no bell on > ambiguous autocompletion, no audible response to echo -en '\007' on > any tty. Nothing obvious in termcap/terminfo (I'm not too handy with > those but no 'vb' that I can see). > > Hmmm. pcspkr.ko is loaded in all of them. > > And the web is full of advise on how to *disable* it, so I guess > modern linuxen have disabled it en-masse, using some trick I can't > spot right now. The obvious place is termcap/terminfo, but nothing > there... Ah, grumble. > > ideas? Some earlier versions of Fedora including Fedora 7 had it disabled in the kernel level because of the number of complaints and bug reports we got. I am not sure there is a easy way to enable that again in those kernels. I think it was enabled again by default in Fedora 8 along with detailed instructions in the release notes to disable it which helped. That is the same for Fedora 9 too. Rahul From martin.langhoff at gmail.com Mon Aug 11 01:43:55 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 11 Aug 2008 13:43:55 +1200 Subject: [Server-devel] Need help: mounting usb devices on headless machines In-Reply-To: <489F93BD.5010902@fedoraproject.org> References: <46a038f90808062337t763b4922sf2df84e7316a18f1@mail.gmail.com> <20080807065242.GC11502@us.netrek.org> <46a038f90808101749p72ac107buf96cb45da22b31d4@mail.gmail.com> <489F93BD.5010902@fedoraproject.org> Message-ID: <46a038f90808101843k9e227ffvdb012fee841dbf58@mail.gmail.com> On Mon, Aug 11, 2008 at 1:19 PM, Rahul Sundaram wrote: > Some earlier versions of Fedora including Fedora 7 had it disabled in the > kernel level because of the number of complaints and bug reports we got. I > am not sure there is a easy way to enable that again in those kernels. Ah, shame. > I think it was enabled again by default in Fedora 8 along with detailed > instructions in the release notes to disable it which helped. That is the > same for Fedora 9 too. Good to hear :-) - I've added a 'todo' bug entry to retry with F9 once we upgrade - http://dev.laptop.org/ticket/7902 . It probably doesn't work on the F9s I have here because they are laptops which don't seem to have the hw for it. Thanks for clearing up the mistery. 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 rnorwood at redhat.com Mon Aug 11 15:15:23 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Mon, 11 Aug 2008 11:15:23 -0400 Subject: Update on Squeak license issue Message-ID: <20080811111523.10778959@solitude.devel.redhat.com> Hi, For the few of you who aren't on the extensive Cc list, we've had a discussion about the Squeak license with Fedora legal (Tom Callaway) and VPRI (Kim Rose and others). To summarize: o As of this moment, there is probably still some code in Squeak that has not been properly moved to the MIT license. (Mostly because the original contributors can't be found). o Fedora can't accept code that is in this state. o Kim Rose says: """ My colleagues, Yoshiki Ohshima and Bert Freudenbeg (along with a few others) have been reviewing all code and our signed Relicensing Agreements for the past week or so. I believe they are stripping out any code that still remains in the image for which we do not have signed agreements to cover. I will meet with them upon my return from vacation week of August 18th to see exactly where we stand. """ So, it looks very hopeful that squeak will soon be entirely safe to include in Fedora, and we'll know more after the 18th. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From katzj at redhat.com Mon Aug 11 18:32:42 2008 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 11 Aug 2008 14:32:42 -0400 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <489D572A.7060906@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> Message-ID: <1218479562.25627.6.camel@aglarond.local> On Sat, 2008-08-09 at 10:36 +0200, Marco Pesenti Gritti wrote: > Jeremy Katz wrote: > > On Fri, 2008-08-08 at 10:11 +0200, Marco Pesenti Gritti wrote: > >> * Translation packaging is not explained in the guidelines, you can see > >> how it's done in the journal. Though I'd really like to figure out a > >> more automatic way to do it (perhaps we can add another macro to > >> sugar-toolkit to deal with it?) > >> > > > > My first and most obvious question is "why not put translations > > into /usr/share/locale like they're supposed to be"? > > XO Bundles, which are the normal activity distribution mechanism for > OLPC are self contained. It seems like they contain more than just the "binary" bits, also including most of the source tree including things like setup.py and the raw po files that shouldn't be needed at all at runtime. Is this intentional or just something that should be fixed up in bundlebuilder? > > Now, when installing into the system with rpm, it would actually make > more sense to use the standard directory layout. I'm only a little > worried that it would complicate the build system of activities which > doesn't use Sugar bundlebuilder. What proportion of activities don't use bundlebuilder? All the ones I've looked at have, but that is admittedly a small-ish sample set > Note that we have to extend/replace find-lang.sh regardless, to be aware > of localized activity.info. That's a quick fix that I can get into upstream rpm once we are agreed on going in that direction much like we already do for a few other things. Going to hold up with my other packages for the moment so that we can try to get some of these things ironed out and thus have simpler packages rather than a lot of packages with manual kludges that we then take out later Jeremy From mpgritti at gmail.com Mon Aug 11 22:52:50 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Tue, 12 Aug 2008 00:52:50 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <1218479562.25627.6.camel@aglarond.local> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> Message-ID: <48A0C2C2.9090300@gmail.com> Jeremy Katz wrote: >> XO Bundles, which are the normal activity distribution mechanism for >> OLPC are self contained. >> > > It seems like they contain more than just the "binary" bits, also > including most of the source tree Any example of this other than setup.py (and the activity python scripts)? > including things like setup.py and the > raw po files that shouldn't be needed at all at runtime. Is this > intentional or just something that should be fixed up in bundlebuilder? > I think the idea there is that kids should be able to modify activities directly (starting from the installed .xo) and redistribute them. The use case is obviously not relevant to activity rpms though. >> Now, when installing into the system with rpm, it would actually make >> more sense to use the standard directory layout. I'm only a little >> worried that it would complicate the build system of activities which >> doesn't use Sugar bundlebuilder. >> > > What proportion of activities don't use bundlebuilder? All the ones > I've looked at have, but that is admittedly a small-ish sample set > > Vast majority uses bundlebuilder. I can only think of Etoys which doesn't right now. >> Note that we have to extend/replace find-lang.sh regardless, to be aware >> of localized activity.info. >> > > That's a quick fix that I can get into upstream rpm once we are agreed > on going in that direction much like we already do for a few other > things. > I'm inclined to go in that direction, yeah. I'll write a patch for bundlebuilder and see the feedback I get about it by the rest of the team. Thanks! Marco From gdk at redhat.com Tue Aug 12 15:55:25 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 12 Aug 2008 11:55:25 -0400 (EDT) Subject: Forked packages for OLPC Message-ID: So we've got a list of packages that have been forked in OLPC from their F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for getting these together. It might be a good idea to figure out: (a) why they're forked; (b) whether we can unfork; (c) how we keep track of why and when we fork. --g ./telepathy-salut/OLPC-3 ./gnash/OLPC-3 ./sugar-presence-service/OLPC-3 ./xorg-x11-server/OLPC-3 ./texlive/OLPC-3 ./NetworkManager/OLPC-3 ./olpc-utils/OLPC-3 ./poppler/OLPC-3 ./abiword/OLPC-3 ./xorg-x11-utils/OLPC-3 ./ntp/OLPC-3 ./pyabiword/OLPC-3 ./hulahop/OLPC-3 ./python-dotconf/OLPC-3 ./sugar-evince/OLPC-3 ./sugar-toolkit/OLPC-3 ./initscripts/OLPC-3 ./SDL_mixer/OLPC-3 ./sugar-artwork/OLPC-3 ./sugar/OLPC-3 ./dotconf/OLPC-3 ./xulrunner/OLPC-3 ./upstart/OLPC-3 ./gnome-python2/OLPC-3 ./olpcsound/OLPC-3 ./xkeyboard-config/OLPC-3 ./speech-dispatcher/OLPC-3 ./totem/OLPC-3 ./sugar-datastore/OLPC-3 ./ohm/OLPC-3 ./fedora-release/OLPC-3 ./gstreamer-plugins-base/OLPC-3 ./pygame/OLPC-3 ./totem-pl-parser/OLPC-3 ./sugar-base/OLPC-3 ./gnome-vfs2/OLPC-3 ./telepathy-gabble/OLPC-3 From dennis at ausil.us Tue Aug 12 16:34:16 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 12 Aug 2008 11:34:16 -0500 Subject: Forked packages for OLPC In-Reply-To: References: Message-ID: <200808121134.16837.dennis@ausil.us> On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote: > So we've got a list of packages that have been forked in OLPC from their > F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for getting > these together. It might be a good idea to figure out: > > (a) why they're forked; > (b) whether we can unfork; > (c) how we keep track of why and when we fork. > > --g > > ./telepathy-salut/OLPC-3 has a patch that disables security that upstream wouldnt take. i wanted them to add it as a run time option. the dbus security breaks rainbow > ./gnash/OLPC-3 should not have been forked > ./sugar-presence-service/OLPC-3 no longer using, using F-9 packages now > ./xorg-x11-server/OLPC-3 needed to enable evdev. Fedora disables it > ./texlive/OLPC-3 rebuild against the old poppler > ./NetworkManager/OLPC-3 we are using 0.6.x there is work to move to 0.7 > ./olpc-utils/OLPC-3 olpc only though could likely live in fedora just fine > ./poppler/OLPC-3 using an old version not sure why. > ./abiword/OLPC-3 should not be needed. should be able to use fedora's branch > ./xorg-x11-utils/OLPC-3 dropped some dependencies > ./ntp/OLPC-3 can be unforked, changes were made to fedora's ntp, drops perl requirement > ./pyabiword/OLPC-3 should not be needed. should be able to use fedora's branch > ./hulahop/OLPC-3 needs pyxpcom which is not enabled in fedora's xulrunner > ./python-dotconf/OLPC-3 should not be needed. should be able to use fedora's branch > ./sugar-evince/OLPC-3 minimal evince for the XO, should be in fedora and pulled in from there > ./sugar-toolkit/OLPC-3 no longer using, using F-9 packages now > ./initscripts/OLPC-3 is needed > ./SDL_mixer/OLPC-3 Droped perl > ./sugar-artwork/OLPC-3 no longer using, using F-9 packages now > ./sugar/OLPC-3 no longer using, using F-9 packages now > ./dotconf/OLPC-3 not sure on this one > ./xulrunner/OLPC-3 needed to enable pyxpcom it needs to get enabled in fedora so that browse can work, caillion is supposed to be fixing. but as yet has not. > ./upstart/OLPC-3 init doesnt run as pid 1 due to the way the intramfs runs should be fixed. > ./gnome-python2/OLPC-3 needed to drop deps, package should be split up some so that we can use fedora's package > ./olpcsound/OLPC-3 its a subset of csound for the XO, we should make it so that csound provides the minimal needs of OLPC > ./xkeyboard-config/OLPC-3 changed some keymappings, really should get fixed properly > ./speech-dispatcher/OLPC-3 not sure on this one > ./totem/OLPC-3 need a minimal totem that doesnt bring in perl and some gnome libraries, F-9's was horribly broken, we are using totem from rawhide > ./sugar-datastore/OLPC-3 no longer using, using F-9 packages now > ./ohm/OLPC-3 makes no sense on any other hardware though wouldnt hurt being in fedora. > ./fedora-release/OLPC-3 different macros for dist. probbaly should write a olpc-release just for olpc > ./gstreamer-plugins-base/OLPC-3 needed to drop perl dependency there is one plugin that pulls in perl > ./pygame/OLPC-3 should use fedora's > ./totem-pl-parser/OLPC-3 needed version from rawhide to match totem. it had better Requires > ./sugar-base/OLPC-3 no longer using, using F-9 packages now > ./gnome-vfs2/OLPC-3 needed to drop some dependencies > ./telepathy-gabble/OLPC-3 has a patch that disables security that upstream wouldnt take. i wanted them to add it as a run time option. the dbus security breaks rainbow kernel should be branched and built in koji. currently its built elsewhere. Dennis From dsd at laptop.org Tue Aug 12 17:24:41 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 12 Aug 2008 13:24:41 -0400 Subject: Forked packages for OLPC In-Reply-To: References: Message-ID: <1218561881.2744.38.camel@olpc-desktop01.laptop.org> On Tue, 2008-08-12 at 11:55 -0400, Greg Dekoenigsberg wrote: > So we've got a list of packages that have been forked in OLPC from their > F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for getting > these together. It might be a good idea to figure out: > > (a) why they're forked; > (b) whether we can unfork; > (c) how we keep track of why and when we fork. See http://wiki.laptop.org/go/Distro_Version_Migration_Nastiness for reasoning behind some of the forks. Daniel From dsd at laptop.org Tue Aug 12 17:58:22 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 12 Aug 2008 13:58:22 -0400 Subject: Forked packages for OLPC In-Reply-To: <200808121134.16837.dennis@ausil.us> References: <200808121134.16837.dennis@ausil.us> Message-ID: <1218563902.2744.44.camel@olpc-desktop01.laptop.org> On Tue, 2008-08-12 at 11:34 -0500, Dennis Gilmore wrote: > > ./poppler/OLPC-3 > using an old version not sure why. sugar-evince (and hence the Read activity) does not work against a newer one. Too late to fix this for 8.2, but should definitely be worked on in future. Daniel From sayamindu at gmail.com Tue Aug 12 18:09:48 2008 From: sayamindu at gmail.com (Sayamindu Dasgupta) Date: Tue, 12 Aug 2008 23:39:48 +0530 Subject: Forked packages for OLPC In-Reply-To: References: Message-ID: On Tue, Aug 12, 2008 at 9:25 PM, Greg Dekoenigsberg wrote: > > So we've got a list of packages that have been forked in OLPC from their F-9 > equivalents. Thanks to Dennis Gilmore and Jim Gettys for getting these > together. It might be a good idea to figure out: > > (a) why they're forked; > (b) whether we can unfork; > (c) how we keep track of why and when we fork. > > --g > <..snip snip> ./xkeyboard-config/OLPC-3 We have a few outstanding patches which have not made it to upstream yet. However, we have made really good progress (we had around 20 patches for OLPC-2 and now it is around 3/4 patches for OLPC-3) with upstream, and I guess for the next release, all our patches will be in upstream. <..snip snip> Apart from that - we have libX11 (which is pulled in from my dropbox[1] at crank.laptop.org). This is to fix a bug which affects the Amharic keyboard layout, and it affects the Fedora package[2] as well. I'll probably complete the patch, and submit it for the Fedora F-9 package as well. Once that happens, we can use the F-9 package directly. Cheers, Sayamindu [1] http://wiki.laptop.org/go/Build_system#Dropbox_Mechanism [2] http://dev.laptop.org/ticket/7474 -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] From rnorwood at redhat.com Tue Aug 12 18:28:30 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 14:28:30 -0400 Subject: Forked packages for OLPC In-Reply-To: <200808121134.16837.dennis@ausil.us> References: <200808121134.16837.dennis@ausil.us> Message-ID: <20080812142830.40361d8e@solitude.devel.redhat.com> On Tue, 12 Aug 2008 11:34:16 -0500 Dennis Gilmore wrote: > On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote: > > So we've got a list of packages that have been forked in OLPC from > > their F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for > > getting these together. It might be a good idea to figure out: > > > > (a) why they're forked; > > (b) whether we can unfork; > > (c) how we keep track of why and when we fork. > > > > --g > > I took the liberty of organizing these a bit by topic: > > ./gnash/OLPC-3 > should not have been forked > > ./sugar-presence-service/OLPC-3 > no longer using, using F-9 packages now > > ./abiword/OLPC-3 > should not be needed. should be able to use fedora's branch > > ./ntp/OLPC-3 > can be unforked, changes were made to fedora's ntp, drops perl > requirement > > ./pyabiword/OLPC-3 > should not be needed. should be able to use fedora's branch > > ./sugar-artwork/OLPC-3 > no longer using, using F-9 packages now > > ./sugar/OLPC-3 > no longer using, using F-9 packages now > > ./python-dotconf/OLPC-3 > should not be needed. should be able to use fedora's branch > > ./sugar-toolkit/OLPC-3 > no longer using, using F-9 packages now > > ./sugar-datastore/OLPC-3 > no longer using, using F-9 packages now > > ./sugar-base/OLPC-3 > no longer using, using F-9 packages now > > ./pygame/OLPC-3 > should use fedora's Is there anything that needs to be done for these? Are they untagged in Koji so OLPC no longer builds against them? > > ./texlive/OLPC-3 > rebuild against the old poppler > > ./poppler/OLPC-3 > using an old version not sure why. Who can investigate poppler and maybe figure out what's up? > > ./dotconf/OLPC-3 > not sure on this one Who can investigate this? > > ./speech-dispatcher/OLPC-3 > not sure on this one Who can investigate this? > ./telepathy-salut/OLPC-3 > has a patch that disables security that upstream wouldnt take. i > wanted them to add it as a run time option. the dbus security breaks > rainbow > > ./telepathy-gabble/OLPC-3 > has a patch that disables security that upstream wouldnt take. i > wanted them to add it as a run time option. the dbus security breaks > rainbow Is this going to be a permanent fork? Can OLPC move away from needing this patch, or can we convince upstream to take an amended patch? > > ./xorg-x11-server/OLPC-3 > needed to enable evdev. Fedora disables it Any idea why Fedora disables it? Can Ajax be convinced to enable it again? > > ./NetworkManager/OLPC-3 > we are using 0.6.x there is work to move to 0.7 Is this likely to be done in time for F10? > > ./olpc-utils/OLPC-3 > olpc only though could likely live in fedora just fine > > ./ohm/OLPC-3 > makes no sense on any other hardware though wouldnt hurt being in > fedora. These appear to already be branched for F9 and rawhide, just not built. Do they need to pass a package review, or does someone just need to build them? > > ./hulahop/OLPC-3 > needs pyxpcom which is not enabled in fedora's xulrunner > > ./xulrunner/OLPC-3 > needed to enable pyxpcom it needs to get enabled in fedora so that > browse can work, caillion is supposed to be fixing. but as yet has > not. Is there a BZ for this? Does caillon need to be nudged? > > ./xorg-x11-utils/OLPC-3 > dropped some dependencies > > ./sugar-evince/OLPC-3 > minimal evince for the XO, should be in fedora and pulled in from > there > > ./SDL_mixer/OLPC-3 > Droped perl > > ./gnome-python2/OLPC-3 > needed to drop deps, package should be split up some so that we can > use fedora's package > > ./olpcsound/OLPC-3 > its a subset of csound for the XO, we should make it so that csound > provides the minimal needs of OLPC > > ./gstreamer-plugins-base/OLPC-3 > needed to drop perl dependency there is one plugin that pulls in perl > > ./gnome-vfs2/OLPC-3 > needed to drop some dependencies Are there BZ's filed for these so work can be done to split up the Fedora packages so OLPC can only take the smallest bits? > > ./totem/OLPC-3 > need a minimal totem that doesnt bring in perl and some gnome > libraries, F-9's was horribly broken, we are using totem from > rawhide > > ./totem-pl-parser/OLPC-3 > needed version from rawhide to match totem. it had better Requires Is there a BZ to track this? > > ./initscripts/OLPC-3 > is needed Does it make sense to have an olpc-initscripts package that is in Fedora proper? > > ./upstart/OLPC-3 > init doesnt run as pid 1 due to the way the intramfs runs should be > fixed. Does that mean it should already be fixed, and we can get rid of this, or that it needs to be fixed? Is there a BZ for it? > > ./xkeyboard-config/OLPC-3 > changed some keymappings, really should get fixed properly BZ? > > ./fedora-release/OLPC-3 > different macros for dist. probbaly should write a olpc-release just > for olpc I think that's the standard way inside rel-eng. I'm sure Jesse Keating knows the proper way to do this. > kernel should be branched and built in koji. currently its built > elsewhere. Is there any work or hope of getting the OLPC kernel and stock Fedora kernel to converge? Does it make sense to get these into a list/table on the wiki? I'm sure we can find someone with Mad Table-making Skillz to do that. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From katzj at redhat.com Tue Aug 12 19:01:27 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Aug 2008 15:01:27 -0400 Subject: Forked packages for OLPC In-Reply-To: <20080812142830.40361d8e@solitude.devel.redhat.com> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> Message-ID: <1218567687.27760.16.camel@aglarond.local> On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > On Tue, 12 Aug 2008 11:34:16 -0500 Dennis Gilmore wrote: > > > ./texlive/OLPC-3 > > rebuild against the old poppler > > > ./poppler/OLPC-3 > > using an old version not sure why. > > Who can investigate poppler and maybe figure out what's up? Apparently the sugar-evince needs the old one? I suspect this just needs someone to sit down and do some updating. I wouldn't expect it to be difficult > > ./telepathy-salut/OLPC-3 > > has a patch that disables security that upstream wouldnt take. i > > wanted them to add it as a run time option. the dbus security breaks > > rainbow > > > ./telepathy-gabble/OLPC-3 > > has a patch that disables security that upstream wouldnt take. i > > wanted them to add it as a run time option. the dbus security breaks > > rainbow > > Is this going to be a permanent fork? Can OLPC move away from needing > this patch, or can we convince upstream to take an amended patch? And more -- what sort of security is the problem here? dbus security is something that is kind of important, even for olpc. > > > ./xorg-x11-server/OLPC-3 > > needed to enable evdev. Fedora disables it > > Any idea why Fedora disables it? Can Ajax be convinced to enable it > again? evdev just wasn't ready for f9. We're making another go at it for f10 now that whot is onboard afaik. > > > ./hulahop/OLPC-3 > > needs pyxpcom which is not enabled in fedora's xulrunner > > > ./xulrunner/OLPC-3 > > needed to enable pyxpcom it needs to get enabled in fedora so that > > browse can work, caillion is supposed to be fixing. but as yet has > > not. > > Is there a BZ for this? Does caillon need to be nudged? caillon is very aware on this one > > > ./initscripts/OLPC-3 > > is needed > > Does it make sense to have an olpc-initscripts package that is in > Fedora proper? What sort of changes are being made here? I could look and if there's not a response by later when I have time to investigate, I will :-) > > > ./upstart/OLPC-3 > > init doesnt run as pid 1 due to the way the intramfs runs should be > > fixed. > > Does that mean it should already be fixed, and we can get rid of this, > or that it needs to be fixed? Is there a BZ for it? /sbin/init needs to be running as pid 1. If the olpc initramfs doesn't ensure that that's the case, then it needs to be fixed, not hacking around it in other packages. Jeremy From dennis at ausil.us Tue Aug 12 19:02:32 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 12 Aug 2008 14:02:32 -0500 Subject: Forked packages for OLPC In-Reply-To: <20080812142830.40361d8e@solitude.devel.redhat.com> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> Message-ID: <200808121402.33080.dennis@ausil.us> On Tuesday 12 August 2008 01:28:30 pm Robin Norwood wrote: > On Tue, 12 Aug 2008 11:34:16 -0500 > > Dennis Gilmore wrote: > > On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote: > > > So we've got a list of packages that have been forked in OLPC from > > > their F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for > > > getting these together. It might be a good idea to figure out: > > > > > > (a) why they're forked; > > > (b) whether we can unfork; > > > (c) how we keep track of why and when we fork. > > > > > > --g > > I took the liberty of organizing these a bit by topic: > > > ./gnash/OLPC-3 > > > > should not have been forked > > > > > ./sugar-presence-service/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./abiword/OLPC-3 > > > > should not be needed. should be able to use fedora's branch > > > > > ./ntp/OLPC-3 > > > > can be unforked, changes were made to fedora's ntp, drops perl > > requirement > > > > > ./pyabiword/OLPC-3 > > > > should not be needed. should be able to use fedora's branch > > > > > ./sugar-artwork/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./sugar/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./python-dotconf/OLPC-3 > > > > should not be needed. should be able to use fedora's branch > > > > > ./sugar-toolkit/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./sugar-datastore/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./sugar-base/OLPC-3 > > > > no longer using, using F-9 packages now > > > > > ./pygame/OLPC-3 > > > > should use fedora's > > Is there anything that needs to be done for these? Are they untagged > in Koji so OLPC no longer builds against them? someone would need to go through and do a bunch of untagging. but its doable ive been tagging the f-9 sugar builds over as they happen. before F-9 updates are pushed. though once the F-9 updates are pushed we should untag so we pull from F-9 > > > ./texlive/OLPC-3 > > > > rebuild against the old poppler > > > > > ./poppler/OLPC-3 > > > > using an old version not sure why. > > Who can investigate poppler and maybe figure out what's up? hides a bug it seems > > > ./dotconf/OLPC-3 > > > > not sure on this one > > Who can investigate this? > > > > ./speech-dispatcher/OLPC-3 > > > > not sure on this one > > Who can investigate this? dsd can you look please > > ./telepathy-salut/OLPC-3 > > has a patch that disables security that upstream wouldnt take. i > > wanted them to add it as a run time option. the dbus security breaks > > rainbow > > > > > ./telepathy-gabble/OLPC-3 > > > > has a patch that disables security that upstream wouldnt take. i > > wanted them to add it as a run time option. the dbus security breaks > > rainbow > > Is this going to be a permanent fork? Can OLPC move away from needing > this patch, or can we convince upstream to take an amended patch? considering upstream wrote it and when i suggested a runtime flag to enable it, and they stronly objected. there needs to be a propper way around it. likely it needs some PolicyKit rules to be made to work and drop the patch. > > > ./xorg-x11-server/OLPC-3 > > > > needed to enable evdev. Fedora disables it > > Any idea why Fedora disables it? Can Ajax be convinced to enable it > again? because it hosed peoples locales. ajax has been working on a better fix. and F-10 it may be enabled. > > > ./NetworkManager/OLPC-3 > > > > we are using 0.6.x there is work to move to 0.7 > > Is this likely to be done in time for F10? sugar needs to learn to deal with both the NM-0.6 and NM-0.7 api. AFAIK that and gettings some patches upstream are the remaining issues > > > ./olpc-utils/OLPC-3 > > > > olpc only though could likely live in fedora just fine > > > > > ./ohm/OLPC-3 > > > > makes no sense on any other hardware though wouldnt hurt being in > > fedora. > > These appear to already be branched for F9 and rawhide, just not > built. Do they need to pass a package review, or does someone just > need to build them? everything got branched for F-9 if it had a devel branch. the way cvs works all packages have to get added at the devel level > > > ./hulahop/OLPC-3 > > > > needs pyxpcom which is not enabled in fedora's xulrunner > > > > > ./xulrunner/OLPC-3 > > > > needed to enable pyxpcom it needs to get enabled in fedora so that > > browse can work, caillion is supposed to be fixing. but as yet has > > not. > > Is there a BZ for this? Does caillon need to be nudged? honestly not sure if there is a bug. last i spoke to him, he was unsure if he could make the changes or not due to mozilla. ( they are such a hugh roadblock at times) > > > ./xorg-x11-utils/OLPC-3 > > > > dropped some dependencies > > > > > ./sugar-evince/OLPC-3 > > > > minimal evince for the XO, should be in fedora and pulled in from > > there > > > > > ./SDL_mixer/OLPC-3 > > > > Droped perl > > > > > ./gnome-python2/OLPC-3 > > > > needed to drop deps, package should be split up some so that we can > > use fedora's package > > > > > ./olpcsound/OLPC-3 > > > > its a subset of csound for the XO, we should make it so that csound > > provides the minimal needs of OLPC > > > > > ./gstreamer-plugins-base/OLPC-3 > > > > needed to drop perl dependency there is one plugin that pulls in perl > > > > > ./gnome-vfs2/OLPC-3 > > > > needed to drop some dependencies > > Are there BZ's filed for these so work can be done to split up the > Fedora packages so OLPC can only take the smallest bits? > > > > ./totem/OLPC-3 > > > > need a minimal totem that doesnt bring in perl and some gnome > > libraries, F-9's was horribly broken, we are using totem from > > rawhide > > > > > ./totem-pl-parser/OLPC-3 > > > > needed version from rawhide to match totem. it had better Requires > > Is there a BZ to track this? likely not > > > ./initscripts/OLPC-3 > > > > is needed > > Does it make sense to have an olpc-initscripts package that is in > Fedora proper? not really. differences are fairly minor. like 3 vts instead of 7. > > > ./upstart/OLPC-3 > > > > init doesnt run as pid 1 due to the way the intramfs runs should be > > fixed. > > Does that mean it should already be fixed, and we can get rid of this, > or that it needs to be fixed? Is there a BZ for it? its not fixed. but needs to be. probably not a bug for it. > > > ./xkeyboard-config/OLPC-3 > > > > changed some keymappings, really should get fixed properly > > BZ? > > > > ./fedora-release/OLPC-3 > > > > different macros for dist. probbaly should write a olpc-release just > > for olpc > > I think that's the standard way inside rel-eng. I'm sure Jesse Keating > knows the proper way to do this. > > > kernel should be branched and built in koji. currently its built > > elsewhere. > > Is there any work or hope of getting the OLPC kernel and stock Fedora > kernel to converge? It would need to be a subpackage. its possible. most of the olpc specific bits are now upstream or on their way there. having a .geode.rpm kernel build for the XO would be good. it would then let people more easily build their own images from only fedora repos. > Does it make sense to get these into a list/table on the wiki? > > I'm sure we can find someone with Mad Table-making Skillz to do that. yes it should along with bugzilla reports as needed. One thing we need to do is make sure when things get broken into subpackages the subpackages are not required so we dont just end up with the same situation. Dennis From dsaxena at laptop.org Tue Aug 12 18:16:51 2008 From: dsaxena at laptop.org (Deepak Saxena) Date: Tue, 12 Aug 2008 11:16:51 -0700 Subject: Forked packages for OLPC In-Reply-To: <200808121134.16837.dennis@ausil.us> References: <200808121134.16837.dennis@ausil.us> Message-ID: <20080812181651.GA2404@plexity.net> On Aug 12 2008, at 11:34, Dennis Gilmore was caught saying: > On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote: > > So we've got a list of packages that have been forked in OLPC from their > > F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for getting > > these together. It might be a good idea to figure out: > > > > (a) why they're forked; > > (b) whether we can unfork; > > (c) how we keep track of why and when we fork. [Sending from right email address this time] Please add kernel to this. I don't know that we'll ever get our kernels in sync, partially just b/c we use seprate SCMs and also b/c we are out of sync with upstream, but I'd like to at least get us to the point where we can use the fedora build system. I'm preparing a detailed email about this topic, will send out sometime this week if I don't get eaten by 8.2 bugs. ~Deepak -- Deepak Saxena - Kernel Developer - dsaxena at laptop.org From gavin at redhat.com Tue Aug 12 19:28:47 2008 From: gavin at redhat.com (Gavin Romig-Koch) Date: Tue, 12 Aug 2008 15:28:47 -0400 Subject: Squeak and EToys packages for Fedora and OLPC Message-ID: <48A1E46F.3070403@redhat.com> I have posted my first draft of Squeak and EToys packages for Fedora and OLPC. They are not yet ready for package review, but they are on their way there. I'm *hoping* I can build .spec files that are usable for both the Fedora and OLPC distributions. I would appreciate it if people from both the Fedora and OLPC sides would try them out, and look them over so see if what I'm doing is going to be acceptable. http://code.google.com/p/squeak-fedora/ This consists of .spec files, .patch files, and a Makefile to download upstream "sources" and build packages from them. There is also a TODO file listing the things I think/know need to work on before these are ready for Fedora or OLPC. If you find issues contact me. -gavin... From dennis at ausil.us Tue Aug 12 19:43:15 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 12 Aug 2008 14:43:15 -0500 Subject: Forked packages for OLPC In-Reply-To: <1218567687.27760.16.camel@aglarond.local> References: <20080812142830.40361d8e@solitude.devel.redhat.com> <1218567687.27760.16.camel@aglarond.local> Message-ID: <200808121443.16709.dennis@ausil.us> On Tuesday 12 August 2008 02:01:27 pm Jeremy Katz wrote: > On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > > On Tue, 12 Aug 2008 11:34:16 -0500 Dennis Gilmore wrote: > > > > ./texlive/OLPC-3 > > > > > > rebuild against the old poppler > > > > > > > ./poppler/OLPC-3 > > > > > > using an old version not sure why. > > > > Who can investigate poppler and maybe figure out what's up? > > Apparently the sugar-evince needs the old one? I suspect this just > needs someone to sit down and do some updating. I wouldn't expect it to > be difficult > > > > ./telepathy-salut/OLPC-3 > > > has a patch that disables security that upstream wouldnt take. i > > > wanted them to add it as a run time option. the dbus security breaks > > > rainbow > > > > > > > ./telepathy-gabble/OLPC-3 > > > > > > has a patch that disables security that upstream wouldnt take. i > > > wanted them to add it as a run time option. the dbus security breaks > > > rainbow > > > > Is this going to be a permanent fork? Can OLPC move away from needing > > this patch, or can we convince upstream to take an amended patch? > > And more -- what sort of security is the problem here? dbus security is > something that is kind of important, even for olpc. rainbow executes activites as different uid's the uids of the activities dont have permission to talk > > > > ./initscripts/OLPC-3 > > > > > > is needed > > > > Does it make sense to have an olpc-initscripts package that is in > > Fedora proper? > > What sort of changes are being made here? I could look and if there's > not a response by later when I have time to investigate, I will :-) enable prettyboot which will need to be re-evaluated with plymouth. likely going forward all the will be needed is a olpc theme. only have tty1 and tty2 and start console on /dev/ttyS0 exec /usr/sbin/olpc-dm instead of of gdm/kdm/xdm etc setup keyboard rules for the XO make sure dcon is unfrozen if something goes wrong. setup autologin on the virtual terminals and the console not alot but not things that should be in fedora. Dennis From dsd at laptop.org Tue Aug 12 19:42:48 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 12 Aug 2008 15:42:48 -0400 Subject: Forked packages for OLPC In-Reply-To: <20080812142830.40361d8e@solitude.devel.redhat.com> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> Message-ID: <1218570168.2744.59.camel@olpc-desktop01.laptop.org> On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > I took the liberty of organizing these a bit by topic: > > > > ./gnash/OLPC-3 > > should not have been forked > > > ./sugar-presence-service/OLPC-3 > > no longer using, using F-9 packages now > > > ./abiword/OLPC-3 > > should not be needed. should be able to use fedora's branch > > > ./ntp/OLPC-3 > > can be unforked, changes were made to fedora's ntp, drops perl > > requirement > > > ./pyabiword/OLPC-3 > > should not be needed. should be able to use fedora's branch > > > ./sugar-artwork/OLPC-3 > > no longer using, using F-9 packages now > > > ./sugar/OLPC-3 > > no longer using, using F-9 packages now > > > ./python-dotconf/OLPC-3 > > should not be needed. should be able to use fedora's branch > > > ./sugar-toolkit/OLPC-3 > > no longer using, using F-9 packages now > > > ./sugar-datastore/OLPC-3 > > no longer using, using F-9 packages now > > > ./sugar-base/OLPC-3 > > no longer using, using F-9 packages now > > > ./pygame/OLPC-3 > > should use fedora's > > Is there anything that needs to be done for these? Are they untagged > in Koji so OLPC no longer builds against them? Forks are still needed for some of these: gnash was forked to bring dependencies down, I don't think we want those deps back. I'm happy to unfork ntp now that Fedora have made the same changes. How can I do that? pygame fork is needed. I have tried to get upstream to take our changes so that we can unfork. No response yet. https://bugzilla.redhat.com/show_bug.cgi?id=457074 > > > ./texlive/OLPC-3 > > rebuild against the old poppler > > > ./poppler/OLPC-3 > > using an old version not sure why. > > Who can investigate poppler and maybe figure out what's up? It should be easy to fix, but we seemed to reach consensus that it is too late to upgrade this for our 8.2 release which we are rapidly closing in on. > > > ./dotconf/OLPC-3 > > not sure on this one > > Who can investigate this? > > > > > ./speech-dispatcher/OLPC-3 > > not sure on this one > > Who can investigate this? Dennis requested I look at these two, I will do so but have more important things to work on first. > > > ./NetworkManager/OLPC-3 > > we are using 0.6.x there is work to move to 0.7 > > Is this likely to be done in time for F10? You'd have to ask the sugar developers. > > ./xorg-x11-utils/OLPC-3 > > dropped some dependencies We can drop this fork for F10 since Adam made the changes in the devel branch. > > > ./sugar-evince/OLPC-3 > > minimal evince for the XO, should be in fedora and pulled in from > > there > > > ./SDL_mixer/OLPC-3 > > Droped perl > > > ./gnome-python2/OLPC-3 > > needed to drop deps, package should be split up some so that we can > > use fedora's package > > > ./olpcsound/OLPC-3 > > its a subset of csound for the XO, we should make it so that csound > > provides the minimal needs of OLPC > > > ./gstreamer-plugins-base/OLPC-3 > > needed to drop perl dependency there is one plugin that pulls in perl > > > ./gnome-vfs2/OLPC-3 > > needed to drop some dependencies > > Are there BZ's filed for these so work can be done to split up the > Fedora packages so OLPC can only take the smallest bits? sugar-evince: http://dev.laptop.org/ticket/7926 http://dev.laptop.org/ticket/7927 SDL_mixer: don't think so gnome-python2: https://bugzilla.redhat.com/show_bug.cgi?id=456122 olpcsound: don't think so, but actually forking and providing seperate source tarballs is what upstream have agreed to. I think we should just build this in F-9 instead. gstreamer-plugins-base: no bugzilla that I know of gnome-vfs2: don't think so. > > > ./totem/OLPC-3 > > need a minimal totem that doesnt bring in perl and some gnome > > libraries, F-9's was horribly broken, we are using totem from > > rawhide > > > ./totem-pl-parser/OLPC-3 > > needed version from rawhide to match totem. it had better Requires > > Is there a BZ to track this? totem-pl-parser wasn't forked to match totem, it was instead forked to drop a humongous dependency chain. https://bugzilla.redhat.com/show_bug.cgi?id=456113 I don't see this being fixed upstream or in Fedora any time soon: http://bugzilla.gnome.org/show_bug.cgi?id=522639 Thanks, Daniel From katzj at redhat.com Tue Aug 12 19:56:03 2008 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 12 Aug 2008 15:56:03 -0400 Subject: Forked packages for OLPC In-Reply-To: <200808121443.16709.dennis@ausil.us> References: <20080812142830.40361d8e@solitude.devel.redhat.com> <1218567687.27760.16.camel@aglarond.local> <200808121443.16709.dennis@ausil.us> Message-ID: <1218570963.27760.21.camel@aglarond.local> On Tue, 2008-08-12 at 14:43 -0500, Dennis Gilmore wrote: > On Tuesday 12 August 2008 02:01:27 pm Jeremy Katz wrote: > > > > > ./initscripts/OLPC-3 > > > > > > > > is needed > > > > > > Does it make sense to have an olpc-initscripts package that is in > > > Fedora proper? > > > > What sort of changes are being made here? I could look and if there's > > not a response by later when I have time to investigate, I will :-) > > enable prettyboot which will need to be re-evaluated with plymouth. likely > going forward all the will be needed is a olpc theme. k > only have tty1 and tty2 and start console on /dev/ttyS0 Console on /dev/ttyS0 should be happening anyway with the udev rules we have I believe. I could see making this a little bit more tweakable in general and new upstart may help there > exec /usr/sbin/olpc-dm instead of of gdm/kdm/xdm etc Why not just have olpc-dm as an option in prefdm? Then this would just work normally > setup keyboard rules for the XO We setup keyboard rules for normal machines, how are these different? > make sure dcon is unfrozen if something goes wrong. ? > setup autologin on the virtual terminals and the console There are requests about this from time to time, so I could see using this as an excuse to come up with the generic infrastructure for doing it > not alot but not things that should be in fedora. It's not a lot at all, and it actually more seems to me like things that we should be able to handle pretty easily and then be down one more forked package :) Jeremy From dennis at ausil.us Tue Aug 12 20:07:54 2008 From: dennis at ausil.us (Dennis Gilmore) Date: Tue, 12 Aug 2008 15:07:54 -0500 Subject: Forked packages for OLPC In-Reply-To: <1218570168.2744.59.camel@olpc-desktop01.laptop.org> References: <20080812142830.40361d8e@solitude.devel.redhat.com> <1218570168.2744.59.camel@olpc-desktop01.laptop.org> Message-ID: <200808121507.55492.dennis@ausil.us> On Tuesday 12 August 2008 02:42:48 pm Daniel Drake wrote: > gnome-vfs2: don't think so. > > > > > ./totem/OLPC-3 > > > > > > need a minimal totem that doesnt bring in perl and some gnome > > > libraries, F-9's was horribly broken, we are using totem from > > > rawhide > > > > > > > ./totem-pl-parser/OLPC-3 > > > > > > needed version from rawhide to match totem. it had better Requires > > > > Is there a BZ to track this? > > totem-pl-parser wasn't forked to match totem, it was instead forked to > drop a humongous dependency chain. > https://bugzilla.redhat.com/show_bug.cgi?id=456113 > I don't see this being fixed upstream or in Fedora any time soon: > http://bugzilla.gnome.org/show_bug.cgi?id=522639 you blew away my changelog in the spec file http://cvs.fedoraproject.org/viewcvs/rpms/totem-pl-parser/OLPC-3/totem-pl- parser.spec?rev=1.14&view=markup it was branched before you trimmed the dependencies. I really would like to work out how we could spit out -minimal packages from the main ones so that you could use either. maybe a kde user wants totem without pulling in half of gnome ;) Dennis From jg at laptop.org Tue Aug 12 20:30:49 2008 From: jg at laptop.org (Jim Gettys) Date: Tue, 12 Aug 2008 16:30:49 -0400 Subject: forked packages Message-ID: <1218573049.8532.0.camel@jg-vaio> Here's the current list of forked packages from Dennis for the current OLPC image. Some probably don't need to exist; some are bug fixes, some are to build a package differently (often to get rid of a dependency). - Jim -- Jim Gettys One Laptop Per Child -------------- next part -------------- An embedded message was scrubbed... From: Dennis Gilmore Subject: forked packages Date: Fri, 8 Aug 2008 09:50:32 -0500 Size: 6415 URL: From gdk at redhat.com Tue Aug 12 20:37:30 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Tue, 12 Aug 2008 16:37:30 -0400 (EDT) Subject: forked packages In-Reply-To: <1218573049.8532.0.camel@jg-vaio> References: <1218573049.8532.0.camel@jg-vaio> Message-ID: On Tue, 12 Aug 2008, Jim Gettys wrote: > Here's the current list of forked packages from Dennis for the current > OLPC image. Some probably don't need to exist; some are bug fixes, some > are to build a package differently (often to get rid of a dependency). You're a few hours late, Jim. I already sent this. ;) --g From rnorwood at redhat.com Tue Aug 12 20:47:25 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 16:47:25 -0400 Subject: Forked packages for OLPC In-Reply-To: <1218570168.2744.59.camel@olpc-desktop01.laptop.org> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> <1218570168.2744.59.camel@olpc-desktop01.laptop.org> Message-ID: <20080812164725.0aa3320d@solitude.devel.redhat.com> On Tue, 12 Aug 2008 15:42:48 -0400 Daniel Drake wrote: > On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > Forks are still needed for some of these: > gnash was forked to bring dependencies down, I don't think we want > those deps back. Ah, then gnash should go on the 'forked for deps' list, and we should work to get those deps split out. > I'm happy to unfork ntp now that Fedora have made the same changes. > How can I do that? I think you just need to request that someone on the infrastructure team untag ntp from olpc-3. Dennis can do that, and probably anything else that needs doing. > pygame fork is needed. I have tried to get upstream to take our > changes so that we can unfork. No response yet. > https://bugzilla.redhat.com/show_bug.cgi?id=457074 I just emailed Chris Stone and asked him if he minds if I go ahead and make the change (or he can). This is probably an effective strategy for this sort of thing - the interested part(y|ies) in OLPC-land can just sign up to co-maintain the Fedora package, and get things done. It should be less work than having an entirely separate fork. > > > > ./texlive/OLPC-3 > > > rebuild against the old poppler > > > > ./poppler/OLPC-3 > > > using an old version not sure why. > > > > Who can investigate poppler and maybe figure out what's up? > > It should be easy to fix, but we seemed to reach consensus that it is > too late to upgrade this for our 8.2 release which we are rapidly > closing in on. Ok. As long as there's a need and a roadmap, having a fork isn't bad. > > Are there BZ's filed for these so work can be done to split up the > > Fedora packages so OLPC can only take the smallest bits? > > sugar-evince: > http://dev.laptop.org/ticket/7926 > http://dev.laptop.org/ticket/7927 > > SDL_mixer: don't think so > > gnome-python2: https://bugzilla.redhat.com/show_bug.cgi?id=456122 > > olpcsound: don't think so, but actually forking and providing seperate > source tarballs is what upstream have agreed to. I think we should > just build this in F-9 instead. > > gstreamer-plugins-base: no bugzilla that I know of > > gnome-vfs2: don't think so. Excellent. I'm going to try to get all this data in the wiki tonight so we don't lose track of it. > > > > ./totem/OLPC-3 > > > need a minimal totem that doesnt bring in perl and some gnome > > > libraries, F-9's was horribly broken, we are using totem from > > > rawhide > > > > ./totem-pl-parser/OLPC-3 > > > needed version from rawhide to match totem. it had better > > > Requires > > > > Is there a BZ to track this? > > totem-pl-parser wasn't forked to match totem, it was instead forked to > drop a humongous dependency chain. > https://bugzilla.redhat.com/show_bug.cgi?id=456113 > I don't see this being fixed upstream or in Fedora any time soon: > http://bugzilla.gnome.org/show_bug.cgi?id=522639 Well, it looks like Matt Barnes is continuing to work on splitting camel <-> EDS, so there's hope for the future, even if it takes awhile. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From dsd at laptop.org Tue Aug 12 21:09:26 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 12 Aug 2008 17:09:26 -0400 Subject: Forked packages for OLPC In-Reply-To: <20080812164725.0aa3320d@solitude.devel.redhat.com> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> <1218570168.2744.59.camel@olpc-desktop01.laptop.org> <20080812164725.0aa3320d@solitude.devel.redhat.com> Message-ID: <1218575366.2744.65.camel@olpc-desktop01.laptop.org> On Tue, 2008-08-12 at 16:47 -0400, Robin Norwood wrote: > > totem-pl-parser wasn't forked to match totem, it was instead forked to > > drop a humongous dependency chain. > > https://bugzilla.redhat.com/show_bug.cgi?id=456113 > > I don't see this being fixed upstream or in Fedora any time soon: > > http://bugzilla.gnome.org/show_bug.cgi?id=522639 > > Well, it looks like Matt Barnes is continuing to work on splitting > camel <-> EDS, so there's hope for the future, even if it takes awhile. Having libcamel in the build wouldn't be acceptable either, it also has a nasty dependency chain. Unless that changes or we can slim it down. Daniel From dsd at laptop.org Tue Aug 12 21:36:50 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 12 Aug 2008 17:36:50 -0400 Subject: Forked packages for OLPC In-Reply-To: References: Message-ID: <1218577010.2744.71.camel@olpc-desktop01.laptop.org> On Tue, 2008-08-12 at 11:55 -0400, Greg Dekoenigsberg wrote: > ./dotconf/OLPC-3 > ./speech-dispatcher/OLPC-3 The .spec files for these are identical to the F-9 ones. Lets unfork. Daniel From rnorwood at redhat.com Wed Aug 13 03:43:47 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 23:43:47 -0400 Subject: Forked packages for OLPC In-Reply-To: References: Message-ID: <20080812234347.16ea7a75@solitude.devel.redhat.com> On Tue, 12 Aug 2008 11:55:25 -0400 (EDT) Greg Dekoenigsberg wrote: > > So we've got a list of packages that have been forked in OLPC from > their F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for > getting these together. It might be a good idea to figure out: > > (a) why they're forked; > (b) whether we can unfork; > (c) how we keep track of why and when we fork. Here's a (temporary until I find the proper location for this sort of thing) page on the wiki. Please edit with more data as it arrives. -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From rnorwood at redhat.com Wed Aug 13 03:45:12 2008 From: rnorwood at redhat.com (Robin Norwood) Date: Tue, 12 Aug 2008 23:45:12 -0400 Subject: Forked packages for OLPC In-Reply-To: <20080812234347.16ea7a75@solitude.devel.redhat.com> References: <20080812234347.16ea7a75@solitude.devel.redhat.com> Message-ID: <20080812234512.6bd71240@solitude.devel.redhat.com> On Tue, 12 Aug 2008 23:43:47 -0400 Robin Norwood wrote: > On Tue, 12 Aug 2008 11:55:25 -0400 (EDT) > Greg Dekoenigsberg wrote: > > > > > So we've got a list of packages that have been forked in OLPC from > > their F-9 equivalents. Thanks to Dennis Gilmore and Jim Gettys for > > getting these together. It might be a good idea to figure out: > > > > (a) why they're forked; > > (b) whether we can unfork; > > (c) how we keep track of why and when we fork. > > Here's a (temporary until I find the proper location for this sort of > thing) page on the wiki. Please edit with more data as it arrives. *sigh* *HERE* is the link: https://fedoraproject.org/wiki/RobinNorwood/OlpcBranch -RN -- Robin Norwood Red Hat, Inc. "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jg at laptop.org Wed Aug 13 14:27:01 2008 From: jg at laptop.org (Jim Gettys) Date: Wed, 13 Aug 2008 10:27:01 -0400 Subject: Forked packages for OLPC In-Reply-To: <20080812142830.40361d8e@solitude.devel.redhat.com> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> Message-ID: <1218637621.32162.22.camel@jg-vaio> On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > > > > ./NetworkManager/OLPC-3 > > we are using 0.6.x there is work to move to 0.7 > > Is this likely to be done in time for F10? > > We have a version of 0.7, with the mesh changes merged. http://lists.laptop.org/pipermail/devel/2008-July/016895.html Dunno if Sjoerd has upstreamed the changes to Dan Williams yet; I've pinged him asking. Sugar will need patches for NM 0.7 in any case; Marco has been threatening to spend some time on getting sugar up to date on Fedora sometime soon. > > > ./xorg-x11-utils/OLPC-3 > > dropped some dependencies > > > ./sugar-evince/OLPC-3 > > minimal evince for the XO, should be in fedora and pulled in from > > there > > > ./SDL_mixer/OLPC-3 > > Droped perl I suspect, but don't know for sure, that for a more serious fedora "conventional" desktop we're stuck with the footprint for Perl. But this will take some dependency analysis to figure out. > > its a subset of csound for the XO, we should make it so that csound > > provides the minimal needs of OLPC Yes, we don't want to carry a tk/tcl dependency, which, believe it or not, is built into csound as a standard "feature", where csound programs might do UI. This is a very slippery slope for us; not only does tk/tcl carry a substantial footprint in RAM and storage, but tcl's I18N facilities are very poor and we don't want people to be coding in this, setting us up for localization headaches. So we have a build of csound which is an exact, proper subset of the full csound (thanks to Victor Lazzarini). The right thing would be to have both versions built and packaged in fedora. I don't know who the packager is; Victor would likely need help. > > > ./gstreamer-plugins-base/OLPC-3 > > needed to drop perl dependency there is one plugin that pulls in perl Ugh; why a plugin would pull in perl is beyond me... > > > > ./initscripts/OLPC-3 > > is needed > > Does it make sense to have an olpc-initscripts package that is in > Fedora proper? Probably, just for simplicity; but I don't think it really matters; we'll have at least one additional repository, so it can live there. > > > kernel should be branched and built in koji. currently its built > > elsewhere. > > Is there any work or hope of getting the OLPC kernel and stock Fedora > kernel to converge? > There is "hope".... But for the forseeable future we'll likely be pushing on power management in ways that have need for a fork. The hope is that a stock kernel might be able to install on an OLPC once the OFW2 firmware is done (which has enough ACPI and other support to maybe support the install path). But for the forseeable future, the kernel you run for more serious work will want to be a different package. See Deepak's mail. Also, we should not carry the full device driver packages for many file systems, many busses, etc. The only externally accessible busses are SD and USB. Sorry about my slow response. My house got struck by lightning Friday; dead (to date): tivo, router, gigabit switch, 2 ethernet cards, one light circuit, one cable modem. - Jim -- Jim Gettys One Laptop Per Child From katzj at redhat.com Wed Aug 13 16:56:15 2008 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 13 Aug 2008 12:56:15 -0400 Subject: Forked packages for OLPC In-Reply-To: <1218637621.32162.22.camel@jg-vaio> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> <1218637621.32162.22.camel@jg-vaio> Message-ID: <1218646575.27760.43.camel@aglarond.local> On Wed, 2008-08-13 at 10:27 -0400, Jim Gettys wrote: > On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: > > > > ./xorg-x11-utils/OLPC-3 > > > dropped some dependencies > > > > ./sugar-evince/OLPC-3 > > > minimal evince for the XO, should be in fedora and pulled in from > > > there > > > > ./SDL_mixer/OLPC-3 > > > Droped perl > > I suspect, but don't know for sure, that for a more serious fedora > "conventional" desktop we're stuck with the footprint for Perl. But > this will take some dependency analysis to figure out. Sadly, this is probably the case. I've spent time in the past trying to exorcise the demon that is perl without much luck. :-) > > > its a subset of csound for the XO, we should make it so that csound > > > provides the minimal needs of OLPC > > Yes, we don't want to carry a tk/tcl dependency, which, believe it or > not, is built into csound as a standard "feature", where csound programs > might do UI. This is a very slippery slope for us; not only does tk/tcl > carry a substantial footprint in RAM and storage, but tcl's I18N > facilities are very poor and we don't want people to be coding in this, > setting us up for localization headaches. What's csound used for? Maybe it makes sense to try and move to something which doesn't require the ugliness of tcl/tk. Jeremy From jg at laptop.org Wed Aug 13 17:11:18 2008 From: jg at laptop.org (Jim Gettys) Date: Wed, 13 Aug 2008 13:11:18 -0400 Subject: Forked packages for OLPC In-Reply-To: <1218646575.27760.43.camel@aglarond.local> References: <200808121134.16837.dennis@ausil.us> <20080812142830.40361d8e@solitude.devel.redhat.com> <1218637621.32162.22.camel@jg-vaio> <1218646575.27760.43.camel@aglarond.local> Message-ID: <1218647478.32162.48.camel@jg-vaio> On Wed, 2008-08-13 at 12:56 -0400, Jeremy Katz wrote: > > > > its a subset of csound for the XO, we should make it so that csound > > > > provides the minimal needs of OLPC > > > > Yes, we don't want to carry a tk/tcl dependency, which, believe it or > > not, is built into csound as a standard "feature", where csound programs > > might do UI. This is a very slippery slope for us; not only does tk/tcl > > carry a substantial footprint in RAM and storage, but tcl's I18N > > facilities are very poor and we don't want people to be coding in this, > > setting us up for localization headaches. > > What's csound used for? Maybe it makes sense to try and move to > something which doesn't require the ugliness of tcl/tk. CSound is the premier music synthesizer of the world..... You hear it all the time (including in movie scores) and don't know it.... We use it for our music synthesis (including midi). The full version is useful for running a lot of the music/composer hacker applications that have accreted over the last decade, but many/most of them are uninteresting/useful for casual users. It has a large user base (they have meetings of >100 people, on a regular basis). Victor is one of the primary csound maintainers/developers. - Jim -- Jim Gettys One Laptop Per Child From sebastian at when.com Wed Aug 13 22:25:22 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Thu, 14 Aug 2008 00:25:22 +0200 Subject: OLPC kernel repository Message-ID: <48A35F52.1040108@when.com> Hi all, I've been looking around for a repository containing the OLPC kernel, which we wanted to include in our "Fedora on XO" effort. Well, I came across this repo [1], which seems to include the packages with the olpc-3 tag in koji. There's also a kernel in there, but I doubt that it's the official OLPC one, since it has the same version number as the one running on my local F9 machine! So far, no luck. Robin's wiki page [2] concerning the forked packages states that the kernel is "(not built in koji right now) Deepak Saxena will provide more details later." So how to get a repo with the OLPC kernel? Robin made me aware of this one here [3] (thanks! :)). Is this the correct repository? There are some kernel builds in there, but I also found recently this page on the laptop.org wiki [4]. The two given links there to the master and stable branch contain both RPMs, which are, according to the wiki, rebuilt every 30 minutes... Do we need to use them? Or is there any other location for the kernel, we're missing? --Sebastian --- [1] http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/ [2] https://fedoraproject.org/wiki/RobinNorwood/OlpcBranch [3] http://xs-dev.laptop.org/~cscott/repos/joyride/ [4] http://wiki.laptop.org/go/Kernel From sebastian at when.com Wed Aug 13 22:31:45 2008 From: sebastian at when.com (Sebastian Dziallas) Date: Thu, 14 Aug 2008 00:31:45 +0200 Subject: OLPC kernel repository In-Reply-To: <48A35F52.1040108@when.com> References: <48A35F52.1040108@when.com> Message-ID: <48A360D1.50900@when.com> Sebastian Dziallas wrote: > Hi all, > > I've been looking around for a repository containing the OLPC kernel, > which we wanted to include in our "Fedora on XO" effort. [...] > Do we need to use them? Or is there any other location for the kernel, > we're missing? > > --Sebastian Well, just found the GIT repo containing the kernel source thanks to David's advice... http://dev.laptop.org/git?p=olpc-2.6 --Sebastian From michael at laptop.org Wed Aug 13 23:37:01 2008 From: michael at laptop.org (Michael Stone) Date: Wed, 13 Aug 2008 19:37:01 -0400 Subject: OLPC kernel repository In-Reply-To: <48A360D1.50900@when.com> References: <48A35F52.1040108@when.com> <48A360D1.50900@when.com> Message-ID: <20080813233700.GT4384@didacte.laptop.org> Check out http://wiki.laptop.org/go/Kernel and friends. Michael From jg at laptop.org Thu Aug 14 15:25:31 2008 From: jg at laptop.org (Jim Gettys) Date: Thu, 14 Aug 2008 11:25:31 -0400 Subject: Alternate distros from SD In-Reply-To: <1218726382.2701.14.camel@olpc-desktop01.laptop.org> References: <1218726382.2701.14.camel@olpc-desktop01.laptop.org> Message-ID: <1218727531.9326.47.camel@jg-vaio> Cool. On Thu, 2008-08-14 at 11:06 -0400, Daniel Drake wrote: > Hi, > > As mentioned yesterday, me and Bobby spent a few hours working towards > scripting the process of fixing up a SD-based regular distribution > install to work on XOs... > > We started with Fedora 9 and had to make the following changes: > - OLPC kernel (testing branch) and modules with a slightly modified > config (building stuff into the image to avoid needing an initramfs) > - /dev/console needs to be added to Fedora install when you aren't > booting with an initramfs > - /boot/olpc.fth boot script needed > - Display settings from XO's xorg.conf required to avoid things > looking really funky > > Things work quite well from that point. Wireless works, suspend too, > mouse/keyboard just fine, ... > > More on the initramfs thing: > Fedora doesn't like being booted direct from disk when the disk is > mounted read-only (it tries to write to various files). So we had to > drop the 'ro' boot parameter. That makes Fedora attempt to e2fsck the > root partition when it is mounted read-write, so you get something like > the following prompt on each boot: > running e2fsck on a mounted partition is really dangerous, continue? > (y/n) > > We then used the F9 initramfs, which worked (despite about 20 errors > that it couldn't find modules or modules.dep, as you might expect). The > best solution may be rolling a minimal initramfs for our case. > > After figuring out the above, I wrote scripts that will take a SD card > where F9 has been vanilla-installed, and it will make the above changes. > TOTALLY UNTESTED but if you want to look, its at > git://dev.laptop.org/~dsd/XO-alt-distro > > Will probably spend a few more hours on this on Friday or Monday > evening. We also want to look at the latest alphas for F10 and Ubuntu > intrepid. > > I also looked at the USB key that Jim gave me, with his custom minimal > fedora spin. I added my OLPC kernel from above and booted manually using > openfirmware. The initramfs is absolutely needed here because there is > no root fs on the card - the initramfs presumably mounts the squashfs > image and then pivots into that. I reused the existing initramfs > unmodified. > That initramfs tried to load various modules and failed as expected, but > it has logic to abort when such failures are detected. Didn't get any > further than that. It'll certainly require modifying or re-rolling the > initramfs to get this booting on XO. Yes, it probably loads some modules from the image, and loses; we need to respin the image so the modules and the booted kernel matches, I suspect. If the live CD image then boots, install to disk would be one way to get it onto the SD card. > > Another funky bug: sometimes sdhci fails to initialize during boot, > giving an odd error message which we didn't write down (some kind of > command timeout). This is odd given that we're using an OLPC kernel and > I don't think we've seen this on the XO? > Interesting. Deepak, any clue? - Jim -- Jim Gettys One Laptop Per Child From dsd at laptop.org Thu Aug 14 15:55:51 2008 From: dsd at laptop.org (Daniel Drake) Date: Thu, 14 Aug 2008 11:55:51 -0400 Subject: Alternate distros from SD In-Reply-To: <1218727531.9326.47.camel@jg-vaio> References: <1218726382.2701.14.camel@olpc-desktop01.laptop.org> <1218727531.9326.47.camel@jg-vaio> Message-ID: <1218729351.2701.18.camel@olpc-desktop01.laptop.org> On Thu, 2008-08-14 at 11:25 -0400, Jim Gettys wrote: > > TOTALLY UNTESTED but if you want to look, its at > > git://dev.laptop.org/~dsd/XO-alt-distro This should be git://dev.laptop.org/users/dsd/XO-alt-distro but to reiterate.. that was written pretty quickly and hasn't been run at all. When I next spend time on it, I'll hopefully get it into tested and working state. Daniel From jg at laptop.org Thu Aug 14 16:44:04 2008 From: jg at laptop.org (Jim Gettys) Date: Thu, 14 Aug 2008 12:44:04 -0400 Subject: OLPC Hosting Application: Fedora on XO In-Reply-To: <48A45BAB.30903@mindspring.com> References: <48A45BAB.30903@mindspring.com> Message-ID: <1218732244.9326.63.camel@jg-vaio> Robert, It isn't clear (yet) if something gnomeish or xfce is best, given the target audience (G1G1 users, rather than kids). We'll see. Hackers are a different audience than most G1G1 users we've had; certainly xfce is fine for most of us. Only experimentation will tell if a more full fledged Gnome is feasible for RAM footprint reasons or not. But most of the point of this is to make installation really easy: to do that, we'd like a customized fedora spin that can fit in flash (co-resident with our usual software), so that installation will not require external media. Most G1G1 end users who get systems can't handle a long set of instructions such as your page outlines; by making a fedora spin, we can get the installation down to "olpc-update fedora" or some such one line command with in place installation. Sebastian has shown that we can make a spin that is small enough. Our other goal is, until nirvana arrives (praying it does) and the OLPC distro is a proper subset of fedora without any broken dependencies, that it be a fedora spin, so that what a user gets is exactly a version of fedora, rather than something that may have brokenness if various software is installed on top of the 8.2.0 release. It's too late in that release cycle to try to get to nirvana for 8.2.0, and is probably 9.1 fodder. This is for support reasons: we don't want to have to deal with thousands of support calls The discussion of this is taking place on the fedora-olpc-list at redhat com list. In any case, thanks for all your help! Best regards, - Jim On Thu, 2008-08-14 at 11:22 -0500, Robert Myers wrote: > Sebastian, > > > 4. Longer description : we're going to provide a Fedora-based > > : "traditional linux desktop" environment > > : for the XO. if we can, we'd like in allow > > : a parallel installation of this and sugar. > > > > Sorry, but I don't understand the need for this repository. XFCE is > already in common use to provide a more traditional windowing desktop > for the XO. Its use is covered on the Wiki "http://wiki.laptop.org/go/Xfce". > > XFCE seems to be a good fit for the XO, full featured enough to support > most traditional applications, conventional enough to suit the desire > for a non-Sugar solution, and light enough to install easily. Gnome or > KDE seem like too much, and the other lightweight environments look a > little strange to me. > > The XFCE page suffers from some poor editing, competing solutions, and a > failure of the instructions to keep up with changes on the XO, but that > would seem to be able to be handled there. > > Bob > _______________________________________________ > Devel mailing list > Devel at lists.laptop.org > http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child From michael at laptop.org Fri Aug 15 04:09:31 2008 From: michael at laptop.org (Michael Stone) Date: Fri, 15 Aug 2008 00:09:31 -0400 Subject: [Fwd: Please help test our new 8.2.0 weekly beta, joyride-2301!] Message-ID: <20080815040931.GO4384@didacte.laptop.org> I thought I'd pass along this global announcement which I just spammed to the OLPC lists in case anyone over here is interested. (Also, do let me know whether the denizens of this list would like to receive similar announcements in the future.) Regards, Michael -------------- We are thrilled to announce a new test build, joyride-2301, valid until Wednesday, August 20. Please help test it according to the detailed instructions at http://wiki.laptop.org/go/Friends_in_testing while we still have time to fix issues you might find! Our specific interest this week has changed; this week, we'd love to know: "How many ways can you crash or hang your XO?" Currently known issues are recorded at: http://wiki.laptop.org/go/Test_Group_Release_Notes#Build_joyride-2301 New issues should be filed in our bug-tracking system (dev.laptop.org) according to http://wiki.laptop.org/go/Submitting_bugs or by notifying us by other means. Thanks! Michael P.S. - I was asked to include to specific notices in this email; first, that http://wiki.laptop.org/go/Software_update gives full details on the new Sugar Control Panel Activity Updater and second, that we are hoping in future weeks to offer a new "Coordinated Testing" volunteer opportunity as part of the run-up to the 8.2.0 raw OS release. Poke me, Kim, Joe, Charlie, S Page, Seth, or Francesca for details. Sneak preview: http://wiki.laptop.org/go/Test_cases_8.2.0 From gdk at redhat.com Fri Aug 15 15:53:13 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 15 Aug 2008 11:53:13 -0400 (EDT) Subject: Reminder: Fedora OLPC meeting at 1pm Eastern US time today Message-ID: On freenode, #fedora-olpc. In about an hour. --g From gdk at redhat.com Fri Aug 15 18:31:24 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Fri, 15 Aug 2008 14:31:24 -0400 (EDT) Subject: fedora-olpc meeting notes and transcript, 8/15 Message-ID: First, the summary: We spent the hour trying to figure out the goals of "Fedora on XO," and how to get there. The problem: Fedora does not yet boot directly on the XO without siginificant modification to kernel and initramfs. The proposal: Have as many people as possible working on creating a small bootable Fedora, and then have dsd continue his excellent work on a tool that takes such an image and hacks it into something that will boot on an XO. The downsides: * Possibly discourages OLPC folks from pushing stuff upsteam into Fedora. * Tools to create Fedora spins are not necessarily the best possible tool. * Concerns that a standard Fedora desktop for the XO weakens the case for Sugar. * Will not integrate with Sugar-based filesystem at this time. The upsides: * Can take the repetitive work of cranking through package profiles and place it on the shoulders of Fedora folks (like Sebastian and others) * Lowest risk approach to getting something working quickly * Once dsd's conversion script works, should make it trivial for anyone in Fedora-land to create and maintain their own XO-compatible image A lively and interesting meeting. :) Full transcript follows. * * * All righty, then. Shall we start with the Fedora-on-XO stuff? sure. Do we have an XO booting Fedora yet? All spin-cutting questions aside? --> ke4qqq (n=ke4qqq at 64.89.94.194.nw.nuvox.net) has joined #fedora-olpc gregdek: I saw one, though I didn't look too closely. gregdek: well, we had TODOs from last mtg, but they were mostly jeremy. rnorwood: Are those tracked on wiki yet? (based on dsd's install-OLPC's-kernel+initramfs script) m_stone: Someone at 1cc was booting one? gregdek: Nope. Good idea, tho. Some of the subtasks are/were: ** TODO: jeremy to build table of sugar activities and other packaging work items on the Fedora wiki ** TODO: Various people to take items from that list and package them ** TODO: jeremy to go to 1cc, revisit next week. ** TODO: rnorwood to track down the squeek/etoys licensing issues ** TODO: gavin to track down the squeek binary blob issue ** TODO: rnorwood to send out minutes jeremy visited. gregdek: first one is done: http://fedoraproject.org/wiki/PackageMaintainers/WishList#Activities gregdek: https://www.redhat.com/archives/fedora-olpc-list/2008-August/msg00063.html gregdek: Jeremy is waiting on resolving a technical spec file issue before the 2nd TODO gets more work. dsd & bobby did an install onto a 4 gig SD card; you've seen the mail. Right. I (my house) got struck by lightning last Friday, which has wasted immense amounts of my time. OK, so to the Fedora image from dsd: --- gavin_lunch is now known as gavin__ Should we be focusing on testing that on various XOs? Jeremy has 10 in his hands now. Should all 10 of those be allocated to people using dsd's spin? gregdek: not a spin, a conventional install of fedora kludged to work. OK. So how do we join the kludge to the real Fedora spin process, is perhaps the question. gregdek: all the packages need to be hosted in Fedora to make an official spin, IIRC. The package manifest is fun to play with, but figuring out how we get a sustainable install process is the question. rnorwood: yes. gregdek: and IIRC, the kernel is the biggest sticking point here. I don't really care if it's "official", per se. We've got the same class of problems with customized ccrma kernels, for instance. gregdek: dsd has provided a script that throws together the packages and dumps the correct kernel on top. gregdek: ok. then I'm not sure how much of the fedora spin process we can use without being an official spin. Then maybe that's sufficient for now. this seems like as maintainable a process as you're going to get until all the upstream work is completely finished. Could be. Is he using the ks files that jg+sebastian worked on? gregdek: furthermore, it doesn't address the initramfs questions. no. Perhaps we should figure out how to join that work? gregdek: challenging because ks is designed for making real spins; not for making hacked up stuff like what we've got. Heh. gregdek: to put it differently -- I looked at anaconda for the XO builds themselves and concluded that it was completely inappropriate for my purpose. now jeremy knows a lot more about anaconda than I do, so there's hope. So... new initramfs? Is that the critical path? depends on your quality goals. the XO has a crazy filesystem structure -- for olpc-update. these spins that we're making can go in two places: on external media or on nand. Which gives the highest likelihood of user success? gregdek: they're good for different audiences. --> dsd__ (n=dsd at gentoo/developer/dsd) has joined #fedora-olpc --- dsd__ is now known as dsd_ anyway, my point is that the degree of interoperability that you get with the existing on-NAND sugar is going to vary greatly depending on how much hackery you want to do. ... And who is the target audience for Fedora+XO? gregdek: solving the olpc-update path transformation should be pretty easy, and orthogonal to making normal spins that install on external media. jg: do you want them to share /home? gregdek: g1g1 users who don't want sugar, and hackers. jg: if so, then they are far from orthogonal. m_stone: the fedora user's login can be different than /home/olpc. jg: I asked a different question. do you want them to share /home. I think we need to punt on interoperability until we get the upstream sugar work done. there we go. +1, I think. Given the timeframes you're talking about, risk mitigation is the most important goal, I think. me to. * m_stone notes, on the political spectrum, that you're increasing the quantity of bad press due to 'olpc abandons sugar' rumors. m_stone: If possible, I want to include sugar as an alternate desktop, for exactly these reasons. With luck, we can counteract that with strong Sugar work in parallel. exactly. gregdek: my point is that we need to plan on _even stronger_ sugar boosting if interop is not an immediate goal (which jg said its not) gregdek: sugar can't take too many more blows. I think we can manage the perception issues aggressively with a lot of help from a broad community. interop is on my 9.1 personal goals. jg: best state that loud and clearly when discussing this. gregdek: That seems unrealistic; we've been doing stronger Sugar work for the last year, but people still think we ditched Sugar for Windows. * m_stone will be quiet now. The fact that we all still have our day jobs and work hard on Sugar doesn't seem to get the message across. :-) cjb: How much of your time have you dedicated to talking to press? Shall I answer that question for you? :) cjb: we speak at 10 dB and NN speaks at 100 dB. what do you expect? and NN sends incomplete, confusing messages.... I know this is a difficult thing to ask. :) Right. I'm just saying that Greg's suggestion of countering claims that we don't care about Sugar by working Sugar has a historically bad effectiveness. But trust me to help you sort those perception issues out. s/working/working on/ gregdek: ok! gregdek: happily. I definitely recognize the exposure. good. I want to first deal with the "we're ditching Linux" rumors.... Sugar is a 2nd order bit question. Heh. Yes and no Anyway. Easy to slip down this rathole. :) Can we agree that we're working on a simple Linux-only install that is essentially independent from the Sugarized file system? for now, yes. That's one. Do I have more? gregdek: yes so long as we also agree to competently explain why this isn't sugar's death-knell m_stone: I promise you. Pinky swear. :) * gregdek crosses his heart and hopes to die. Okay, works for me too. All right. So what does that choice imply for our current critical path? the critical path is getting a cut down spin to boot. jg: where by 'spin', you mean a genuine Fedora Spin, right? I'd be trying to work on that if I weren't in meetings all this week I've not been playing sysadmin to fix all the lightning damange.... So we've got the boot issues involving initramfs and kernel on one side... m_stone: yes. jg: i.e. no external packages. ...and the Fedora spin work on the other side. How do we join these efforts sanely? m_stone: includes packages from us. but only a few. So to be clear: This is not a "Fedora spin". It can't and shouldn't be. for the moment, yes. It is a "based on Fedora" environment using the best tools available to make it sustainable to maintain. jg: what? that seems to me to contract what you just said. but my hope is it minimizes the number of changes. *contradict jg: I explicitly asked you "Fedora Spin" -- no package divergence -- and you said "yes". was that a mistake? a future goal? m_stone: marco claims to be about to work on fedora sugar packages.... I know you have some questions on whether he will find it hard to succeed. To me, a spin is nothing more than "an internally consistent set of software packages". yup. And a Fedora spin is that, plus "only containing packages in the Fedora universe." We are talking about the former, *not* the latter. yup. until/unless everything we need is upstream. The livecd tools are able to create package manifests from multiple repos, I believe. that's what I've called "nirvana". gregde.k: yes Now, are we talking about a process that looks like: 1. Build a "minimal OLPC/Fedora hybrod spin"; 2. Hack in initramfs changes; 3. Slap it into an image; --> nteon (n=nteon at dhcp-47-122.media.mit.edu) has joined #fedora-olpc 4. Profit? roughly. the closer it is to fedora, the easier it will be for us all to support it.... Right. Can we limit the unique packages to kernel and initramfs to start? that's what sebastian tried to build last night. How did it go? the build seems to have failed, and I've not seen him on line today. Please pardon my out-of-the-loopness... Hm! * gregdek wonders if jeremy has had time to play with this. When's the deadline to have something working? Do we have a clear one? I was about to try to test the previous spin, with a manual hack of the kernel and initrd. Carry on. ;) gregdek: the SD card dsd just put together is probably enough to keep the hounds at bay. * m_stone is extremely confused about the goals of this whole endeavor and fears that some effort will be required if his non-confusion is important. gregdek: but the sooner, the better. Very good. dsd_, thanks for buying us some time. m_stone: feel free to explain. gregdek: I view the underlying goal here as procedural and communal. we're looking for increasingly powerful degrees of 'easy to maintain', 'accessible to both the OLPC and fedora communities', etc. Right. And you feel like we're conflicting with that? well, I view the current approach and intense focus on getting various filesystem trees to boot on the OLPC as rather counterproductive to that. for a couple of reasons. how so? * gregdek listens. first, most of what jg has been asking for has been various degrees of easy installation. i.e. 'a completely isolated SD card that boots fedora on the OLPC' yes, that's to be able to get it into g1g1 hands, without requiring an SD card. uh, _with_ requiring an sd card you mean? maybe jg is talking about a second tier of 'easy installation'; the ability to blow away the existing filesystem and use a stock fedora-like filesystem? yes, easy installation. To be clear: and then finally some degree of interop -- the ability to boot either fedora or sugar off either NAND or SD and have them share data perhaps by having sugar as an alternate desktop (sorry, go ahead) gregdek: so what does this have to do with any of the procedural and communal maintenance bit? m_stone: I don't expect data sharing until we've dealt with sugar's journal issue upstream. jg: why? we've already got copy-to-journal and copy-from-journal. plus, the filenames are stable, so clever symlinking hacks are possible It's a tactical goal that some folks in the Fedora community can help with. jg: and we have external metadata in 8.2.0; easily backportable. gregdek: fine, but why is it any better than 'olpc-update fedora-big' ? m_stone: I'm trying to bound the "requirements" to the minimum. If we get more, I'll be yet happier. underpromise, overdeliver. m_stone: Maybe it's not. m_stone: olpc-update fedora-big is my goal for installation. I'm just looking for the approach that minimizes our short-term risk and allows Fedora folk to help. just like debian, but with a fully usable environment ootb. jg: I can't tell that from the way you're going about it. gregdek: right. m_stone: ergo the use of the live-cd-tools. Listen, gentlemen, I'm a simple man. :) we can build an image, using standard tools, that can fit. that's what sebastian has proven. Right. That's my goal. I know it may be an imperfect goal. But it's something that many people have experience with: building their own Fedora spin. exactly. And it's a place where people can (a) use the tools they know, and (b) familiarize themselves with an environment that they do *not* know in the process. and all dependencies are satisfied, so yum install xxxx will "just work". jg: yum install working has nothing at all to do with the use of anaconda or of livecd-tools. and anaconda is not adapted for using nonstandard kernels or initramfsen which is _critical_ to the way olpc-update works. which is why everyone who has worked on XO software builds has used one of three alternatives. pilgrim, puritan, of manual image creation. *or pilgrim is the ancestor of livecd-tools, you know. gregdek: yes. I've spent quite a bit of time with both. (I helped debug livecdtools on the XS where it also at best marginally appropriate) Which makes me wonder where the two have diverged, and why. gregdek: and livecdtools made some design choices which _conflict_ with the easiest way to get distributions installed on the XO. Are they similar enough to allow people to use ks.cfg files? now you might have another goal, which is not to use olpc-update -- to simply rely on SD cards or on copy-nand. gregdek: no, they're wholly different. gregdek: pilgrim is a big shell script which makes a chroot, installs some packages into, and wraps up the result. My goal is to find the tools with the most common usage, so that you can leverage as much knowledge as possible. gregdek: right, I understand that. gregdek: and I'm saying that jg is doing something different. All right. * gregdek takes a step back. gregdek: anaconda and mkinitrd is going to require _surgery_ in order to be compatible w/ olpc-update. so you shouldn't expect that. Why should we care about compatibility with olpc-update for the Linux-only side? which means that you're either interested in SD-only or in copy-nand solutions. m_stone: all we've done to date is to prove we can build, using live-cd-tools, and image small enough that it could coexist on nand with our image, which would make it possible for olpc-update to function. gregdek: because then we can do an install without external media. :) or you want to rely on something like dsd's script to make the necessary changes to the filesystem churned out by anaconda. those are your three options. Right. Of those... I tend to lean to #3. so far as I can tell, none of them is compatible with making the communal process you want. Maybe that's wrong and hacky. :) :) Well, yes and no. There's different work to be done, right? One set of work: Figuring out a small set of packages that fits well and gives a decent experience. This is work that *many* can share. Second set of work: gregdek: sure. Adapting that to the hw realities of the XO. (puritan is a better tool for that job) Which is probably not terribly scalable work. How many people use/know puritan? gregdek: more than have succeeded in getting anaconda-built software to work on the XO. And how many is that? about 2 for puritan and 0 for anaconda. and how many are familiar with puritan and anaconda, and have made the attempt? Except, of course, that if you have a simple overlay script that massages the livecd output in a predictable way to fix kernel+initramfs, which should be a one-time cost operation, that number changes dramatically. a small number are familiar with puritan because it is newer than anaconda and much more specialized. however, it is quite good at smashing together RPMs (and other package formats) into XO-compatible file-systems. gregdek: thats what i'm scripting m_stone: It feels like you're pushing to use puritan, and that's fine, if that's your choice. But it'll be more difficult for me to deliver knowledgeable community members to your door. gregdek: I'm pushing you to explain how your choices are going to fulfill your goals. Whereas (livecd/etc.) plus (dsd_script) yields many possible contributors. Do others understand my viewpoint? dsd_? jg? m_stone: but you're talking to people who don't have as much experience with the technology, so what they really need to hear is "I suggest doing , which would gain us " yes. what purpose would these community members have? to assist the build process? To iterate over packaging issues. To fix dependency problems in Fedora, which is your base. yes, working on the community's home turf makes sense from that respect To lower the bar for their contribution by allowing them to use tools they already know. Standard gregdek disclaimer: as always, I could be completely wrong. :) heh. As can I, frequently ;-). gregdek: so your desired outcome is a script that takes a .ks and runs it resulting in XO-compatible media. Yes. I think so. e.g. by performing whatever hacks dsd finds are necessary on top of the output from anaconda. Yes. I think so. gregdek: and how are you going to debug that? It's still a package manifest, in the end. What's the likely scope of changes? gregdek: also, in a larger community sense -- how does it help anyone outside of Fedora/RH land? gregdek: hard to predict. This is one specific goal. There are many others. We also have the Sugar stuff to work through, and we haven't talked about it yet, because we've spent an hour debating this. What I'm offering is a way to help offload the maintenance of this Fedora spin from you guys... m_stone: I find it hard to follow your argument because you're pointing out downsides in one approach without mentioning which other approach has far fewer downsides and accomplishes the same goals. ...so you can spend your capacity elsewhere. m_stone: pilgrim's hard to debug, too. every piece of technology for doing this has downsides. pointing at downsides doesn't tell me what we should actually do instead. Anyway. I'm running out of time... <-- kimquirk_ (n=kimquirk at pool-98-110-153-245.bstnma.fios.verizon.net) has left #fedora-olpc ...so I will make my recommendation, and allow you to do with it as you will. I think that dsd_'s approach is good, and I'd like to see folks trying it out. m_stone: Outside of Fedora/RH land people at least have a huge body of experience to tap - plenty of documentation to tap - not to mention significant community pool who already know how things work - can your alternative say the same? dsd_'s approach is great, but doesn't result in a small image. cjb: we should be pushing our patches upstream and fixing packaging bugs until we get to the point where Sugar and Fedora are completely indistiguishable in that the XO software distribution is a fedora install with some on-disk configuration changes. Can dsd_'s approach be merged with the ongoing ks refinement work? cjb: dennis was taking us in that direction and I continue to believe that it's the right way. I also don't have insight into what is required to get us to where olpc-update can be used to do an installation. m_stone: I also believe that it's right. They are not mutually exclusive. cjb: getting more contribution from Fedora folks should occur by asking them to install olpc-generated packages on F-9, F-10, etc. and fixing bugs. or through emulation, or by sending them XOs. m_stone: the unmentioned downside of that plan is that it doesn't get us something in time for G1G1. jg: that's a reason to learn more, rather than a reason not to try to achieve that. cjb: I'm trying to learn; educate me ;-). At some point... ...a wrong decision is better than none. :) How do we move forward? cjb: what is maintainable about what jg/gregdek are suggesting and who does it benefit? --> jwilliam (n=jwilliam at jwilliam.dsl.xmission.com) has joined #fedora-olpc m_stone: This predicates that the dsd_ scripts are actually any good. If they are... gregdek: it's a hack. dsd could certainly maintain it indefinitely. hopefully someone directly from fedora-land could do so as well. It's also a short-term solution, right? gregdek: I'm skeptical of that. Because the goal is NOT to have bootable Fedora forever. gregdek: I think it's going to encourage people not to try to merge OLPC's changes into Fedora proper. The goal is to have bootable Sugar on top of stock Fedora. Why? I have no idea where that assertion comes from. People on fedora-olpc-list continue to iterate through that list of forked packages to solve those problems. Do they not? gregdek: no, they don't need to here. gregdek: they might continue to do so, because they're good people who share the same goal. its a short term solution because in the longer term i hope that upstream kernel will boot on XO.. then we're just left with xorg.conf and boot.fth Right. dsd_: and the initramfs This is trying to get MORE help in solving a SHORT-TERM problem. if upstream kernel boots on Xo then we use fedora's kernel and initramfs no need to customize It does nothing to discourage the ongoing work on the LONG-TERM problems. They are separate. I don't know how to explain myself any more clearly. gregdek: I don't buy it, but fortunately, I don't have to. gregdek: the best I'll give you is that it adds a marginal amount of value to jeremy's goal of widespread dependency splitting. Then why are you arguing? For the sport? :) Anyway. I'm out of time, gentlemen. dsd_: Is your script available for folks to check out / use? gregdek: because I think that encouraging people to work really hard on getting OLPC to deal with Fedora properly and working really hard to modify Fedora procedures that are hard for OLPC to deal with is a far better place to expend effort. m_stone: THEY ARE NOT MUTUALLY EXCLUSIVE. gregdek: yes but it is totally untested, i havent even run it It's a long road. gregdek: going to test and fix it tonight dsd_: Brilliant. I look forward to hearing more about it. And if it sucks, we figure something else out. :) Because, as always, I could be completely wrong. Anyway. * gregdek bangs the gavel. From dfarning at sugarlabs.org Fri Aug 15 21:50:29 2008 From: dfarning at sugarlabs.org (David Farning) Date: Fri, 15 Aug 2008 16:50:29 -0500 Subject: fedora-olpc meeting notes and transcript, 8/15 In-Reply-To: References: Message-ID: <1218837029.7367.397.camel@dfarning.desktop.org> On Fri, 2008-08-15 at 14:31 -0400, Greg Dekoenigsberg wrote: > First, the summary: > > We spent the hour trying to figure out the goals of "Fedora on XO," and > how to get there. > > The problem: Fedora does not yet boot directly on the XO without > siginificant modification to kernel and initramfs. > > The proposal: Have as many people as possible working on creating a small > bootable Fedora, and then have dsd continue his excellent work on a tool > that takes such an image and hacks it into something that will boot on an > XO. > > The downsides: > > * Possibly discourages OLPC folks from pushing stuff upsteam into Fedora. > > * Tools to create Fedora spins are not necessarily the best possible tool. > > * Concerns that a standard Fedora desktop for the XO weakens the case for > Sugar. Running Fedora as the desktop enhances the case for Sugar by reducing the perception of vendor lock in. We are asking potential investors to take a significant risk by deploying the XO. Allowing decision makers to effortlessly opt-out of the Sugar desktop if they are not happy, significantly mitigates that risk. As we ramp up the Sugar ecosystem, I feel confident that we can make Sugar the Learning environment of 'choice' for XO deployments. > * Will not integrate with Sugar-based filesystem at this time. > > The upsides: > > * Can take the repetitive work of cranking through package profiles and > place it on the shoulders of Fedora folks (like Sebastian and others) > > * Lowest risk approach to getting something working quickly > > * Once dsd's conversion script works, should make it trivial for anyone in > Fedora-land to create and maintain their own XO-compatible image > Thanks dfarning From dsd at laptop.org Tue Aug 19 13:42:02 2008 From: dsd at laptop.org (Daniel Drake) Date: Tue, 19 Aug 2008 09:42:02 -0400 Subject: Running F9 from SD card on XO Message-ID: <1219153322.2680.1.camel@olpc-desktop01.laptop.org> Hi, I posted a script and a mini howto on how to get Fedora 9 running on the XO: http://www.reactivated.net/weblog/archives/2008/08/regular-linux-desktops-on-the-xo/ It works well. We'll be putting more info on the OLPC wiki soon. Daniel From lucas at cefetce.br Fri Aug 22 16:12:22 2008 From: lucas at cefetce.br (Lucas - Linux Sys. Admin (CEFETCE/UAB)) Date: Fri, 22 Aug 2008 13:12:22 -0300 Subject: Projeto Fedora no CESoL ! Message-ID: http://www.projetofedora.org/node/92 GO GO GO ! :) -- -- Atenciosamente, Lucas do Amaral Saboya CEFET-CE - UAB-CE. Linux System Administrator Fedora Ambassador & Fedora Translator -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpgritti at gmail.com Sun Aug 24 20:59:01 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Sun, 24 Aug 2008 22:59:01 +0200 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <48A0C2C2.9090300@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> <48A0C2C2.9090300@gmail.com> Message-ID: On Tue, Aug 12, 2008 at 12:52 AM, Marco Pesenti Gritti wrote: > I'm inclined to go in that direction, yeah. I'll write a patch for > bundlebuilder and see the feedback I get about it by the rest of the team. Sorry for the delay, I've been in vacation. I just opened a ticket and added patches for review: http://dev.laptop.org/ticket/8136 Marco From michael at laptop.org Sun Aug 24 22:05:35 2008 From: michael at laptop.org (Michael Stone) Date: Sun, 24 Aug 2008 18:05:35 -0400 Subject: Sugar on Fedora 10 Alpha - how to I run it? In-Reply-To: <48A0C2C2.9090300@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> <48A0C2C2.9090300@gmail.com> Message-ID: <20080824220533.GL4384@didacte.laptop.org> Marco, I don't understand yet how, why, where, and when you're proposing to change the installation patterns for activities, their translation data, source code, etc, nor what effect your proposal may have on the ability of OLPC to use the Fedora activity packaging guidelines to get itself out of impending activity-related dependency hell. Therefore, before committing your changes to Sugar, could you please more fully explain the details of your proposal so everyone has the opportunity to reflect on its impact? (Something PEP-ish or RFC-ish would be most appreciated.) Thanks very much, Michael From mpgritti at gmail.com Sun Aug 24 23:39:02 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Mon, 25 Aug 2008 01:39:02 +0200 Subject: bundlebuilder changes (was Re: Sugar on Fedora 10 Alpha - how to I run it?) In-Reply-To: <20080824220533.GL4384@didacte.laptop.org> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B754B.5040409@gmail.com> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> <48A0C2C2.9090300@gmail.com> <20080824220533.GL4384@didacte.laptop.org> Message-ID: <48B1F116.6060907@gmail.com> Michael Stone wrote: > Marco, > > I don't understand yet how, The specific change I'm proposing is to install .mo files (translations) in they standard system location, /usr/share/locale. > why, Fedora has a script which handles translation packaging and it obviously expect things to be in their normal system location. Another approach would be to provide specific scripts for Sugar activities. But I think installing things where they are supposed to be when using rpm is a cleaner fix. And I think in general it would better to use the standard system paths whenever it's possible. > where, This is a change to bundlebuilder, the build script which is used by most activities. It only applies to system installation, not to .xo builds. > and when Unclear. Depends on the reaction I get about the approach etc. I enumerated several possibilities on the ticket, there are surely more. > you're proposing to > change the installation patterns for activities, their translation data, > source code, The only way this affects source code is that the .po files are not shipped in the rpm. > etc, nor what effect your proposal may have on the ability > of OLPC to use the Fedora activity packaging guidelines to get itself > out of impending activity-related dependency hell. I know nothing about this plan. You should write an RFC about it. It's way more ambitious and complicated than what I'm proposing. The OLPC use cases and requirements are very different from normal Fedora/yum usage. Without knowing more about what you are planning in concrete, I have no idea if this change make things worst or better than what we have now in this respect. Can you elaborate? > Therefore, before committing your changes to Sugar, could you please > more fully explain the details of your proposal so everyone has the > opportunity to reflect on its impact? (Something PEP-ish or RFC-ish > would be most appreciated.) I'm happy to document it on the wiki as soon as I've got more feedback about the general approach. The change is very simple (I hope I managed to clarify what is exactly, otherwise please ask away), but it can have interesting consequences. I hope discussion here, on the ticket and on the Sugar mailing list will provide some good thoughts about it. Marco From martin.langhoff at gmail.com Mon Aug 25 00:18:10 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 25 Aug 2008 12:18:10 +1200 Subject: bundlebuilder changes (was Re: Sugar on Fedora 10 Alpha - how to I run it?) In-Reply-To: <48B1F116.6060907@gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489B81B7.9040308@projetofedora.org> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> <48A0C2C2.9090300@gmail.com> <20080824220533.GL4384@didacte.laptop.org> <48B1F116.6060907@gmail.com> Message-ID: <46a038f90808241718i51100f11n53809dcdd88e9d33@mail.gmail.com> On Mon, Aug 25, 2008 at 11:39 AM, Marco Pesenti Gritti wrote: > The specific change I'm proposing is to install .mo files (translations) in > they standard system location, /usr/share/locale. This is a problem-space well explored by the GNUStep packaging in Debian and right now being discussed in Fedora-devel too. We aren't breaking new ground on this at all... So I assume the approach will be based on the GNUStep approach? If you ask me, I'd guess that Sugar would support both the self-contained bundles for easy d/l and exchange, but also handle RPM-installed activities that are not in a self-contained bundle, but laid out in FHS-compatible manner. One big win in Sugar defining a FHS-compat layout would be stemming the risk of different distros picking different paths. This could happen for GNUStep packages if Fedora decides to go a different way from Debian -- and if it does happen it will probably be quite jarring for the GNUStep upstream. 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 mpgritti at gmail.com Mon Aug 25 00:22:19 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Mon, 25 Aug 2008 02:22:19 +0200 Subject: bundlebuilder changes (was Re: Sugar on Fedora 10 Alpha - how to I run it?) In-Reply-To: <46a038f90808241718i51100f11n53809dcdd88e9d33@mail.gmail.com> References: <28FFE5E2034D440580AA911F4DA13402@Q9450> <489BFBEB.3070607@schampijer.de> <489BFF9C.1070208@gmail.com> <1218205318.22759.4.camel@aglarond.local> <489D572A.7060906@gmail.com> <1218479562.25627.6.camel@aglarond.local> <48A0C2C2.9090300@gmail.com> <20080824220533.GL4384@didacte.laptop.org> <48B1F116.6060907@gmail.com> <46a038f90808241718i51100f11n53809dcdd88e9d33@mail.gmail.com> Message-ID: On Mon, Aug 25, 2008 at 2:18 AM, Martin Langhoff wrote: > On Mon, Aug 25, 2008 at 11:39 AM, Marco Pesenti Gritti > wrote: >> The specific change I'm proposing is to install .mo files (translations) in >> they standard system location, /usr/share/locale. > > This is a problem-space well explored by the GNUStep packaging in > Debian and right now being discussed in Fedora-devel too. We aren't > breaking new ground on this at all... Thanks for the pointer! I'll look into it. > So I assume the approach will be based on the GNUStep approach? If you > ask me, I'd guess that Sugar would support both the self-contained > bundles for easy d/l and exchange, but also handle RPM-installed > activities that are not in a self-contained bundle, but laid out in > FHS-compatible manner. Yup, that's exactly the approach I'm leaning towards here. Marco From martin.langhoff at gmail.com Mon Aug 25 00:44:56 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 25 Aug 2008 12:44:56 +1200 Subject: Packaging jesred? Message-ID: <46a038f90808241744s5b2fdfdek3fe26c7efbc9e87b@mail.gmail.com> We are considering using jesred with Squid, to provide local copies to "external" content for things like activity updates (the activity updater just goes for a standard url). But there are no Fedora packages for it :-/ http://www.linofee.org/~elkner/webtools/jesred/ http://packages.debian.org/jesred Is there any interest in packaging these...? 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 jg at laptop.org Mon Aug 25 21:33:25 2008 From: jg at laptop.org (Jim Gettys) Date: Mon, 25 Aug 2008 17:33:25 -0400 Subject: State of Fedora spin Message-ID: <1219700005.6567.65.camel@jg-vaio> Sebastian Dziallas and I have been investigating a OLPC Fedora spin for OLPC; as not everything is upstream in Fedora (we keep trying!), it is not logical to call this a spin of Fedora, but of an OLPC load of software derived from Fedora. Goals o minimize differences from stock Fedora, so that everyone can help. o small footprint, ideally so small that olpc-update o "culturally" compatible with those expecting a conventional laptop experience, as typified by Give One Get One donors, supporting a selection of "conventional" applications (e.g. web browser, mail client, editor, etc.). Where are we: o Build machine has been established at 1cc; if you want access to it, send an SSH key to me. o a 520 megabyte spin was pretty easy to make; but that is using Squashfs, which is more efficient than JFFS2, so it is still not small enough to fit allowing olpc-update to be used for an in-place upgrade. Said spin booted fine on conventional systems, though since it lacked a kernel for OLPC, could not be booted on the XO. o the olpc kernel lacks the squashfs patch; we created a RPM adding it, which would be necessary to use the Fedora live-cd-tools. o Some experiments have been made with Puritan, another build system done by Michael Stone, though nothing bootable as yet. o I've spent some time looking through Sebastian's spin: it is clear we can make a small enough image, without too much grief... Additionally, Daniel Drake and Bobby Powers have documented how to install Fedora 9 onto an SD card. Initial notes can be found from this message: https://www.redhat.com/archives/fedora-olpc-list/2008-August/msg00070.html Note that a gnome environment runs decently, which is something lots of end users would find acceptable; note we avoid some notable memory pigs: e.g. evolution. On first blush, XFCE is (probably) not necessary. Note that this is a pretty full fedora install, on a 4 gig SD card; something much smaller as a starting point is needed. Problems right now: o live-cd-tools doesn't seem to find the initrd, when Sebastian tries to build a spin with an OLPC kernel. We don't understand this. Anyone familiar with the live-cd-tools who can help is greatly appreciated... o Note that there is tons of other fat to nuke; some unneeded dependencies (e.g. libgweather), icons at a bunch of sizes, /usr/share/doc is accumulates to several hundred megabytes (uncompressed). Note that this is several hundred megabytes larger than the OLPC Sugar only build. We'll need lots of help here; some of it is very easy; for example, nuking post install (most of) what is in /usr/share/doc. o what the manifest of the system should be is something well worth serious discussion: there are questions such as claws versus thunderbird, versus other mail possibilities. o sorting through backgrounds and icons in /usr/share (which, uncompressed, approaches 1GB) to define a minimal set, and dealing with the packaging issues that arise would also be a big help. o Once a spin exists, some modifications would be needed to the installation program to install the spin onto jffs2. We hope that by the time this all is ready to go, conventional packages for Sugar for Fedora will make it possible for a simple sugar installation as well; but only time will tell. So any help folks care to give, please jump in... - Jim -- Jim Gettys One Laptop Per Child From martin.langhoff at gmail.com Wed Aug 27 01:27:14 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 27 Aug 2008 13:27:14 +1200 Subject: What's cooking in the XS pot this week (2008-08-26) In-Reply-To: <46a038f90808251657r6a59ccacm6d9a0ef37f26b3ba@mail.gmail.com> References: <46a038f90808251657r6a59ccacm6d9a0ef37f26b3ba@mail.gmail.com> Message-ID: <46a038f90808261827nd624f31wd096fb0c87796a7f@mail.gmail.com> More OLPC spam :-) -- If you see a raft of "how do I make $something work in F9" questions from me on fedora-devel... the email below outlines what I am working on (in a nutshell, upgrading the School Server spin to F9). Help is deeply appreciated. While most stuff "just works", we have some significant challenges: - Networking infrastructure. Jerry has been helping lots, and any pointers into how to tweak the udev-triggered in ways that don't backfire... welcome! Not many people seem to be playing with it, and our setup has some "special needs". - Upgrade nicely. - Pungi/revisor configuration and scripts for a truly minimal install. - Kickstart / anaconda / firstboot tweaking. cheers, m ---------- Forwarded message ---------- From: Martin Langhoff Date: Tue, Aug 26, 2008 at 11:57 AM Subject: What's cooking in the XS pot this week (2008-08-26) To: XS Devel xs-0.4 is out - so now we're on to xs-0.5. The plan for this week is to - Keep track of any issues on 0.4 -- please report them via Trac or post them here - Add an activity installation server -- which may be available for 0.4. Douglas is working on this. - Make an attempt to rebase on F9. This attempt is time-boxed - if by EoB Friday we have a reasonably well cooked F9-based XS installer, it's all go and xs-0.5 will be based on F9. If instead we have a pile of issues, we'll document the issues and ask for help, but we'll drop the F9 port from the xs-0.5 plans. This is a hard-nosed risk mgmt strategy. F9 gives us security support and a hopefully better build toolchain (anaconda, pungi and revisor seem to be in much better shape, bugs in the F7 versions have been a problem for us). On the other hand, it gives us no user-visible features, and issues with the rebase can be very time consuming to resolve. Reaching end-of-Sept with only a F9-based version with no new features for end users would be a bad scenario. Same date but with a buggy F9-based version and no new features is our worst case. My plan does not allow for either to happen :-) The other non-ideal scenario is a F7-based release with features, but with no security support. This is not the best, but on the risks map this is not as serious because most XS installs we are planning to support in deployments are _not_ on the internet -- they either have no WAN/Internet connection or they are behind NAT. Their value as targets and their exposure is very low. I know some readers care a lot about security, and I am deeply grateful that they do. If you are one of them, do your bit: help us make the F9 port a success. 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 Wed Aug 27 07:41:39 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Wed, 27 Aug 2008 19:41:39 +1200 Subject: Pungi minimal installer, comps.xml trick Message-ID: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> Playing with a minimal Pungi kickstart file I get an install CD of about 500MB. If I add the xs-pkgs dependencies, things balloon to 759MB, no longer fitting in a CD. My guess is that a good 1/3 of that is related to the graphical installer and related dependencies which we don't want on the installed CD. It's not a complete deal breaker, but I prefer to distribute images that are small, and ideally fit on 1 CD. Jerry, you mentioned that fiddling with comps.xml was an option? How do you do that? ;-) This is how I am building the F9 XS images - sudo pungi -c kickstarts/pungi-f9-minimal.ks --nosource --name XS --ver=0.5dev --force --discs=1 --nosplitmedia And pungi-f9-minimal.ks contains... ## These are public repos repo --name=release --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=$basearch repo --name=olpc7 --baseurl=ttp://fedora.laptop.org/xs/testing/olpc/7/i386 repo --name=olpc9 --baseurl=http://fedora.laptop.org/xs/testing/olpc/9/i386 ## I actually use these local copies :-) #repo --name=fedora --baseurl=file:///media/disk/xs/releases/9/Fedora/i386/os/ #repo --name=everything --baseurl=file:///media/disk/xs/releases/9/Everything/i386/os/ #repo --name=olpc7 --baseurl=file:///xsrepos/testing/olpc/7/i386/ #repo --name=olpc9 --baseurl=http://fedora.laptop.org/xs/testing/olpc/9/i386 %packages --nobase #@core bash kernel passwd policycoreutils chkconfig authconfig rootfiles anaconda-runtime #-gnome* #-cairo #-xorg-x11-server-Xorg xs-config xs-pkgs %end 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 Wed Aug 27 09:47:12 2008 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 27 Aug 2008 15:17:12 +0530 Subject: Pungi minimal installer, comps.xml trick In-Reply-To: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> References: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> Message-ID: <48B522A0.2030000@fedoraproject.org> Martin Langhoff wrote: > Playing with a minimal Pungi kickstart file I get an install CD of > about 500MB. If I add the xs-pkgs dependencies, things balloon to > 759MB, no longer fitting in a CD. My guess is that a good 1/3 of that > is related to the graphical installer and related dependencies which > we don't want on the installed CD. > > It's not a complete deal breaker, but I prefer to distribute images > that are small, and ideally fit on 1 CD. > > Jerry, you mentioned that fiddling with comps.xml was an option? How > do you do that? ;-) You fiddle with the comps.xml file and redefine packages that are included in the different groups that are part of your compose like @core. If they are not direct dependencies, you might be able to reduce the content. Rahul From robin.norwood at gmail.com Wed Aug 27 15:14:23 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Wed, 27 Aug 2008 11:14:23 -0400 Subject: [Server-devel] Pungi minimal installer, comps.xml trick In-Reply-To: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> References: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> Message-ID: On Wed, Aug 27, 2008 at 3:41 AM, Martin Langhoff wrote: > Playing with a minimal Pungi kickstart file I get an install CD of > about 500MB. If I add the xs-pkgs dependencies, things balloon to > 759MB, no longer fitting in a CD. My guess is that a good 1/3 of that > is related to the graphical installer and related dependencies which > we don't want on the installed CD. Hi, The people working on Anaconda are moving towards deprecating the text-only installer, if not completely, then for most cases. OTOH, if you're doing kickstart installs of these things, then you don't need the graphical installer after all. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From martin.langhoff at gmail.com Wed Aug 27 23:03:05 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Thu, 28 Aug 2008 11:03:05 +1200 Subject: [Server-devel] Pungi minimal installer, comps.xml trick In-Reply-To: References: <46a038f90808270041g46080b1at2ca577667abd2c35@mail.gmail.com> Message-ID: <46a038f90808271603l7f502d79w88741e8b79c55e8f@mail.gmail.com> On Thu, Aug 28, 2008 at 3:14 AM, Robin Norwood > The people working on Anaconda are moving towards deprecating the > text-only installer, if not completely, > then for most cases. Yes, I've seen notes in that direction and discussion on the buildsys list. It's there in F9, so I'll take advantage of it while I can, and revisit on the next rebase. It is not clear to me how the anaconda team will support installs on embedded systems over serial port. And I have to keep that in mind for some of the HW options we have for the XS. > OTOH, if you're doing kickstart installs of these things, then you > don't need the graphical installer after all. It must support both kickstart-driven (for deployments) and interactive (for developers and pilot sites mainly). The interactive needs are not very complex (partitioning mainly) so as long as a limited text mode remains, we're ok... 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 tomeu at tomeuvizoso.net Thu Aug 28 18:44:38 2008 From: tomeu at tomeuvizoso.net (Tomeu Vizoso) Date: Thu, 28 Aug 2008 20:44:38 +0200 Subject: Sugar people traveling to FUDCon Brno Message-ID: <242851610808281144v36c1a71el59d048718ed3fa12@mail.gmail.com> Hi all, some of the Sugar developers will come out from their honeycombs and fly to Brno, Czech Republic to meet at the FUDCon Brno 2008 the September 5 - 7, 2008. The plan is to explain to whoever listens to us in which way Fedora has been good for Sugar and how good Sugar could be for Fedora. We are starting to plan this meeting in [1] and we should soon move things to [2]. [1] http://www.sugarlabs.org/go/Events/FUDCon_Brno_2008 [2] https://fedoraproject.org/wiki/FUDCon/FUDConBrno2008 Although this meeting will be a bit restricted in scope because it's about Fedora, we'd like to ask everybody for help in creating material that can be used in conferences. One example is an activity tutorial (or perhaps several depending on the audience and format). One pretty ambitious possibility would be to show how to do a gobby-like activity with pieces from Write and XOIrc? Eben, would you like to do a simple mockup of how this could look like? Any comments, suggestions, etc will be most welcome. And if anyone feels like passing by there and saying hello, would be great! Thanks, Tomeu From mpgritti at gmail.com Thu Aug 28 19:20:07 2008 From: mpgritti at gmail.com (Marco Pesenti Gritti) Date: Thu, 28 Aug 2008 21:20:07 +0200 Subject: IRC meeting Message-ID: Are we going to have an irc meeting tomorrow? Not sure if those are supposed to be weekly or not... Marco From katzj at redhat.com Thu Aug 28 19:33:28 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Aug 2008 15:33:28 -0400 Subject: State of Fedora spin In-Reply-To: <1219700005.6567.65.camel@jg-vaio> References: <1219700005.6567.65.camel@jg-vaio> Message-ID: <1219952008.15746.79.camel@aglarond.local> On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote: > o a 520 megabyte spin was pretty easy to make; but that is using > Squashfs, which is more efficient than JFFS2, so it is still not small > enough to fit allowing olpc-update to be used for an in-place upgrade. > Said spin booted fine on conventional systems, though since it lacked a > kernel for OLPC, could not be booted on the XO. Note that the config as it currently stands is missing some pretty important things. Like, say, X drivers :) It also ends up with a lot of duplication from the "base" config and thus will in the long run be a little more painful to maintain. Unfortunately, with the older kernel, there's not a great way around this at the moment. I'll try to add a fixup so that overriding repos works properly in a little bit. > o the olpc kernel lacks the squashfs patch; we created a RPM adding it, > which would be necessary to use the Fedora live-cd-tools. There are a couple of other quirks of the olpc kernel that break using it as-is for a live image: 1) squashfs as mentioned 2) dm_snapshot isn't being built 3) The %post of the kernel package doesn't call new-kernel-pkg, instead doing things by hand. But not including mkinitrd. This led to no initrd and the error that was later seen. Given that the XO is always using an initrd, is there a reason new-kernel-pkg isn't just being called? But with those taken care of, I can get an image built based on rawhide + that kernel that boots. I then have to drop an xorg.conf in as the driver is busted and doesn't manage to auto-config, but that too should be fairly straight-forward to get fixed (bz#460581). > Problems right now: > o live-cd-tools doesn't seem to find the initrd, when Sebastian tries > to build a spin with an OLPC kernel. We don't understand this. Anyone > familiar with the live-cd-tools who can help is greatly appreciated... This is because the initrd isn't being built. See 3 above. > o Note that there is tons of other fat to nuke; some unneeded > dependencies (e.g. libgweather), icons at a bunch of > sizes, /usr/share/doc is accumulates to several hundred megabytes > (uncompressed). Note that this is several hundred megabytes larger than > the OLPC Sugar only build. We'll need lots of help here; some of it is > very easy; for example, nuking post install (most of) what is > in /usr/share/doc. libgweather is part of what's needed for the actual desktop -- it's depended on by the time/date stuff carried by gnome. Also, just nuking docs willy-nilly isn't the wisest of ideas. For one thing, in some cases, the license file is required to be included. Also, if they're just nuked with an rm, then a later update by the user will bring them back. So I have been very cautious about doing anything along those lines for "general purpose" use -- and since it seems one of the goals here is to have the XO generally running Fedora, it may be something to avoid. > o what the manifest of the system should be is something well worth > serious discussion: there are questions such as claws versus > thunderbird, versus other mail possibilities. That depends to some extent what the goal is -- do we want to be able to be running "stock" Fedora or a special spin? The former seems like it's more valuable in a lot of ways because a user who is used to Fedora has the _exact_ same applications, etc available. > o Once a spin exists, some modifications would be needed to the > installation program to install the spin onto jffs2. >From what I remember, jffs2 is substantially different in that you don't do formatting, etc and rather just do imaging. The live install process is already somewhat imaging-like in that we just dd over the filesystem to the final partition and do some resizing tricks, but that's not going to work as-is. I'd have to go back and refresh my memory of jffs2 imaging to give any better indication. It does, at least, look like jffs2 should have all of the right hooks in the kernel for security xattrs, though. > We hope that by the time this all is ready to go, conventional packages > for Sugar for Fedora will make it possible for a simple sugar > installation as well; but only time will tell. Yeah, a couple of separate things need following up on there. Marco's proposed bundlebuilder changes should take care of one set of them. Then it should at least be easier to get packages being built and through the review process, at which point, I'll return to that Jeremy From gdk at redhat.com Thu Aug 28 19:52:41 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 28 Aug 2008 15:52:41 -0400 (EDT) Subject: REMINDER: fedora-olpc meeting tomorrow at 1pm Eastern US time Message-ID: Just want to catch up and find out what everyone's doing. :) #fedora-olpc, irc.freenode.net. See you there. --g From katzj at redhat.com Thu Aug 28 20:01:13 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Aug 2008 16:01:13 -0400 Subject: State of Fedora spin In-Reply-To: <1219952008.15746.79.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> Message-ID: <1219953464.15746.81.camel@aglarond.local> On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote: > On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote: > > o a 520 megabyte spin was pretty easy to make; but that is using > > Squashfs, which is more efficient than JFFS2, so it is still not small > > enough to fit allowing olpc-update to be used for an in-place upgrade. > > Said spin booted fine on conventional systems, though since it lacked a > > kernel for OLPC, could not be booted on the XO. > > Note that the config as it currently stands is missing some pretty > important things. Like, say, X drivers :) It also ends up with a lot > of duplication from the "base" config and thus will in the long run be a > little more painful to maintain. > > Unfortunately, with the older kernel, there's not a great way around > this at the moment. I'll try to add a fixup so that overriding repos > works properly in a little bit. As of commit abfcd5f100d4f52e65ed674b8bd33db05fa8a155 of livecd-tools, this should be doable now. Jeremy From gdk at redhat.com Thu Aug 28 20:18:36 2008 From: gdk at redhat.com (Greg Dekoenigsberg) Date: Thu, 28 Aug 2008 16:18:36 -0400 (EDT) Subject: IRC meeting In-Reply-To: References: Message-ID: On Thu, 28 Aug 2008, Marco Pesenti Gritti wrote: > Are we going to have an irc meeting tomorrow? Not sure if those are > supposed to be weekly or not... They should be. Missed last week because I was on PTO and did not notify folks -- my mistake. I sent out a reminder before I saw this note. :) --g From jg at laptop.org Thu Aug 28 20:36:41 2008 From: jg at laptop.org (Jim Gettys) Date: Thu, 28 Aug 2008 16:36:41 -0400 Subject: State of Fedora spin In-Reply-To: <1219952008.15746.79.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> Message-ID: <1219955801.6567.191.camel@jg-vaio> On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote: > On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote: > > o a 520 megabyte spin was pretty easy to make; but that is using > > Squashfs, which is more efficient than JFFS2, so it is still not small > > enough to fit allowing olpc-update to be used for an in-place upgrade. > > Said spin booted fine on conventional systems, though since it lacked a > > kernel for OLPC, could not be booted on the XO. > > Note that the config as it currently stands is missing some pretty > important things. Like, say, X drivers :) It also ends up with a lot > of duplication from the "base" config and thus will in the long run be a > little more painful to maintain. > > Unfortunately, with the older kernel, there's not a great way around > this at the moment. I'll try to add a fixup so that overriding repos > works properly in a little bit. > > > o the olpc kernel lacks the squashfs patch; we created a RPM adding it, > > which would be necessary to use the Fedora live-cd-tools. > > There are a couple of other quirks of the olpc kernel that break using > it as-is for a live image: > 1) squashfs as mentioned > 2) dm_snapshot isn't being built > 3) The %post of the kernel package doesn't call new-kernel-pkg, instead > doing things by hand. But not including mkinitrd. This led to no > initrd and the error that was later seen. Given that the XO is always > using an initrd, is there a reason new-kernel-pkg isn't just being > called?, Yes, because right now, our initrd for the anti-theft system is pretty magic, and gets built separately (on Debian, believe it or not, the last I heard). Ideally, this can get fixed, so we can share an identical kernel between different loads. Once our 8.2.0 system ships, I think we can/should add the small set of stuff stock fedora needs to the OLPC configuration so that the base system can be identical. > > But with those taken care of, I can get an image built based on rawhide > + that kernel that boots. I then have to drop an xorg.conf in as the > driver is busted and doesn't manage to auto-config, but that too should > be fairly straight-forward to get fixed (bz#460581). > > > Problems right now: > > o live-cd-tools doesn't seem to find the initrd, when Sebastian tries > > to build a spin with an OLPC kernel. We don't understand this. Anyone > > familiar with the live-cd-tools who can help is greatly appreciated... > > This is because the initrd isn't being built. See 3 above. > > > o Note that there is tons of other fat to nuke; some unneeded > > dependencies (e.g. libgweather), icons at a bunch of > > sizes, /usr/share/doc is accumulates to several hundred megabytes > > (uncompressed). Note that this is several hundred megabytes larger than > > the OLPC Sugar only build. We'll need lots of help here; some of it is > > very easy; for example, nuking post install (most of) what is > > in /usr/share/doc. > > libgweather is part of what's needed for the actual desktop -- it's > depended on by the time/date stuff carried by gnome. it Actually, it is just the stupid clock applet to show the names of the cities where you may also show the current time and weather. > Also, just nuking > docs willy-nilly isn't the wisest of ideas. For one thing, in some > cases, the license file is required to be included. Also, if they're > just nuked with an rm, then a later update by the user will bring them > back. So I have been very cautious about doing anything along those > lines for "general purpose" use -- and since it seems one of the goals > here is to have the XO generally running Fedora, it may be something to > avoid. Much of this is ChangeLogs and the like, which I think we can safely delete. We can't burn several hundred meg (uncompressed) on this. I'll get some statistics of the different file types. Preserving license files I agree is essential; we don't want to have to do the inventorying we're doing for the olpc load. > > > o what the manifest of the system should be is something well worth > > serious discussion: there are questions such as claws versus > > thunderbird, versus other mail possibilities. > > That depends to some extent what the goal is -- do we want to be able to > be running "stock" Fedora or a special spin? The former seems like it's > more valuable in a lot of ways because a user who is used to Fedora has > the _exact_ same applications, etc available. > > > o Once a spin exists, some modifications would be needed to the > > installation program to install the spin onto jffs2. > > >From what I remember, jffs2 is substantially different in that you don't > do formatting, etc and rather just do imaging. The live install process > is already somewhat imaging-like in that we just dd over the filesystem > to the final partition and do some resizing tricks, but that's not going > to work as-is. I'd have to go back and refresh my memory of jffs2 > imaging to give any better indication. It does, at least, look like > jffs2 should have all of the right hooks in the kernel for security > xattrs, though. No, for olpc-update, we'll just have to put the bits in the right place on the server, and jffs2 /olpc-update will take care of the rest. Similarly, for an "install to disk". Jffs2 can/should be treated as a normal file system. To coexist with our sugar based load to be able to install via olpc-update, we just put it in a root of its own. Our firmware is set up to allow booting two different systems in their own roots (which may even be sharing hardlinked files); this is to enable our robust upgrade stuff. On our system, you can have an olpc-upgrade fail in the middle, yet still end up with your old system intact. So other than putting a prefix on the paths, (and optionally hardlinking identical files) install from a live CD/USB image should be easy. The only time we need to build a jffs2 image from scratch is if we want an image from scratch that can be installed from ofw using "copy-nand". > > > We hope that by the time this all is ready to go, conventional packages > > for Sugar for Fedora will make it possible for a simple sugar > > installation as well; but only time will tell. > > Yeah, a couple of separate things need following up on there. Marco's > proposed bundlebuilder changes should take care of one set of them. > Then it should at least be easier to get packages being built and > through the review process, at which point, I'll return to that > > Jeremy > > _______________________________________________ > Fedora-olpc-list mailing list > Fedora-olpc-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-olpc-list -- Jim Gettys One Laptop Per Child From katzj at redhat.com Thu Aug 28 21:35:34 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Aug 2008 17:35:34 -0400 Subject: State of Fedora spin In-Reply-To: <1219955801.6567.191.camel@jg-vaio> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219955801.6567.191.camel@jg-vaio> Message-ID: <1219959334.14533.5.camel@aglarond.local> On Thu, 2008-08-28 at 16:36 -0400, Jim Gettys wrote: > On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote: > > On Mon, 2008-08-25 at 17:33 -0400, Jim Gettys wrote: > > > o the olpc kernel lacks the squashfs patch; we created a RPM adding it, > > > which would be necessary to use the Fedora live-cd-tools. > > > > There are a couple of other quirks of the olpc kernel that break using > > it as-is for a live image: > > 1) squashfs as mentioned > > 2) dm_snapshot isn't being built > > 3) The %post of the kernel package doesn't call new-kernel-pkg, instead > > doing things by hand. But not including mkinitrd. This led to no > > initrd and the error that was later seen. Given that the XO is always > > using an initrd, is there a reason new-kernel-pkg isn't just being > > called?, > > Yes, because right now, our initrd for the anti-theft system is pretty > magic, and gets built separately (on Debian, believe it or not, the last > I heard). Ewwww :-) > Ideally, this can get fixed, so we can share an identical > kernel between different loads. Once our 8.2.0 system ships, I think we > can/should add the small set of stuff stock fedora needs to the OLPC > configuration so that the base system can be identical. There's definitely been a lot of drift between the two kernel spec files. Which is worth resolving in any case. The ideal, to me at least, would be if we can just use one of the same kernels that's shipped in Fedora. That's the only way that we're going to be able to have any spin carry the Fedora trademark at present. And really, that doesn't look like it should be that far off -- there's not that much in the diff of 2.6.26 to the olpc kernel tree from a glance. And some may even be resolved in 2.6.27. > > > o Note that there is tons of other fat to nuke; some unneeded > > > dependencies (e.g. libgweather), icons at a bunch of > > > sizes, /usr/share/doc is accumulates to several hundred megabytes > > > (uncompressed). Note that this is several hundred megabytes larger than > > > the OLPC Sugar only build. We'll need lots of help here; some of it is > > > very easy; for example, nuking post install (most of) what is > > > in /usr/share/doc. > > > > libgweather is part of what's needed for the actual desktop -- it's > > depended on by the time/date stuff carried by gnome. it > > Actually, it is just the stupid clock applet to show the names of the > cities where you may also show the current time and weather. Which is also used for the timezone setting bits. While the current stored form of the data has its downsides, it's actually quite good to be able to possibly have a better way in the future of timezone selection than just dealing with the poor stuff that's in tzdata. So rather than throwing out the baby and the bathwater, it's more likely worthwhile to help upstream come up with a better way of representing the data with less duplication. > > > o Once a spin exists, some modifications would be needed to the > > > installation program to install the spin onto jffs2. > > > > >From what I remember, jffs2 is substantially different in that you don't > > do formatting, etc and rather just do imaging. The live install process > > is already somewhat imaging-like in that we just dd over the filesystem > > to the final partition and do some resizing tricks, but that's not going > > to work as-is. I'd have to go back and refresh my memory of jffs2 > > imaging to give any better indication. It does, at least, look like > > jffs2 should have all of the right hooks in the kernel for security > > xattrs, though. > > No, for olpc-update, we'll just have to put the bits in the right place > on the server, and jffs2 /olpc-update will take care of the rest. > Similarly, for an "install to disk". Jffs2 can/should be treated as a > normal file system. To coexist with our sugar based load to be able to > install via olpc-update, we just put it in a root of its own. Our > firmware is set up to allow booting two different systems in their own > roots (which may even be sharing hardlinked files); this is to enable > our robust upgrade stuff. On our system, you can have an olpc-upgrade > fail in the middle, yet still end up with your old system intact. So > other than putting a prefix on the paths, (and optionally hardlinking > identical files) install from a live CD/USB image should be easy. Easy-ish, but slow. Doing a file-based copy took on the order of a heck of a lot longer from what I remember. I'll have to look closer at that, but it's a little lower on my todo list Jeremy From jg at laptop.org Thu Aug 28 22:35:07 2008 From: jg at laptop.org (Jim Gettys) Date: Thu, 28 Aug 2008 18:35:07 -0400 Subject: State of Fedora spin In-Reply-To: <1219959334.14533.5.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219955801.6567.191.camel@jg-vaio> <1219959334.14533.5.camel@aglarond.local> Message-ID: <1219962907.6567.204.camel@jg-vaio> On Thu, 2008-08-28 at 17:35 -0400, Jeremy Katz wrote: > There's definitely been a lot of drift between the two kernel spec > files. Which is worth resolving in any case. The ideal, to me at > least, would be if we can just use one of the same kernels that's > shipped in Fedora. That's the only way that we're going to be able to > have any spin carry the Fedora trademark at present. And really, that > doesn't look like it should be that far off -- there's not that much in > the diff of 2.6.26 to the olpc kernel tree from a glance. And some may > even be resolved in 2.6.27. That's the ideal, but not all OLPC stuff is upstream in kernel.org as yet (e.g. device tree stuff, where there are several alternatives differing in not-very-important details currently gumming the works) . And it is likely/probable we'll continue to do work in power management. in advance of Linus... Whether Fedora would want to carry such patches is far from clear, and .seems unlikely > > > > > o Note that there is tons of other fat to nuke; some unneeded > > > > dependencies (e.g. libgweather), icons at a bunch of > > > > sizes, /usr/share/doc is accumulates to several hundred megabytes > > > > (uncompressed). Note that this is several hundred megabytes larger than > > > > the OLPC Sugar only build. We'll need lots of help here; some of it is > > > > very easy; for example, nuking post install (most of) what is > > > > in /usr/share/doc. > > > > > > libgweather is part of what's needed for the actual desktop -- it's > > > depended on by the time/date stuff carried by gnome. it > > > > Actually, it is just the stupid clock applet to show the names of the > > cities where you may also show the current time and weather. > > Which is also used for the timezone setting bits. While the current > stored form of the data has its downsides, it's actually quite good to > be able to possibly have a better way in the future of timezone > selection than just dealing with the poor stuff that's in tzdata. So > rather than throwing out the baby and the bathwater, it's more likely > worthwhile to help upstream come up with a better way of representing > the data with less duplication. I already complained upstream, and the issue may have already been fixed upstream in Gnome. http://bugzilla.gnome.org/show_bug.cgi?id=547961 > > > > > o Once a spin exists, some modifications would be needed to the > > > > installation program to install the spin onto jffs2. > > > > > > >From what I remember, jffs2 is substantially different in that you don't > > > do formatting, etc and rather just do imaging. The live install process > > > is already somewhat imaging-like in that we just dd over the filesystem > > > to the final partition and do some resizing tricks, but that's not going > > > to work as-is. I'd have to go back and refresh my memory of jffs2 > > > imaging to give any better indication. It does, at least, look like > > > jffs2 should have all of the right hooks in the kernel for security > > > xattrs, though. > > > > No, for olpc-update, we'll just have to put the bits in the right place > > on the server, and jffs2 /olpc-update will take care of the rest. > > Similarly, for an "install to disk". Jffs2 can/should be treated as a > > normal file system. To coexist with our sugar based load to be able to > > install via olpc-update, we just put it in a root of its own. Our > > firmware is set up to allow booting two different systems in their own > > roots (which may even be sharing hardlinked files); this is to enable > > our robust upgrade stuff. On our system, you can have an olpc-upgrade > > fail in the middle, yet still end up with your old system intact. So > > other than putting a prefix on the paths, (and optionally hardlinking > > identical files) install from a live CD/USB image should be easy. > > Easy-ish, but slow. Doing a file-based copy took on the order of a heck > of a lot longer from what I remember. I'll have to look closer at that, > but it's a little lower on my todo list > We do an rsync based update for olpc-update; this has lots of advantages for us. - Jim -- Jim Gettys One Laptop Per Child From katzj at redhat.com Thu Aug 28 22:43:03 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Aug 2008 18:43:03 -0400 Subject: State of Fedora spin In-Reply-To: <1219962907.6567.204.camel@jg-vaio> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219955801.6567.191.camel@jg-vaio> <1219959334.14533.5.camel@aglarond.local> <1219962907.6567.204.camel@jg-vaio> Message-ID: <1219963383.14533.9.camel@aglarond.local> On Thu, 2008-08-28 at 18:35 -0400, Jim Gettys wrote: > On Thu, 2008-08-28 at 17:35 -0400, Jeremy Katz wrote: > > There's definitely been a lot of drift between the two kernel spec > > files. Which is worth resolving in any case. The ideal, to me at > > least, would be if we can just use one of the same kernels that's > > shipped in Fedora. That's the only way that we're going to be able to > > have any spin carry the Fedora trademark at present. And really, that > > doesn't look like it should be that far off -- there's not that much in > > the diff of 2.6.26 to the olpc kernel tree from a glance. And some may > > even be resolved in 2.6.27. > > That's the ideal, but not all OLPC stuff is upstream in kernel.org as > yet (e.g. device tree stuff, where there are several alternatives > differing in not-very-important details currently gumming the works) . > And it is likely/probable we'll continue to do work in power management. > in advance of Linus... Whether Fedora would want to carry such patches > is far from clear, and .seems unlikely Compelling patches that are destined for the next Linus rev (... with someone who's willing to own helping to fix them up if they break the build) go in with some frequency. The big thing is that it's a mentality shift. But the advantages you gain (both from thinking "get kernel changes upstream Linus kernel" and "get packages changes in upstream Fedora") end up making it so that going from Fedora 9->10->11 becomes a far less difficult process. And then maybe we can get to where the actual build being shipped on the XOs has few to no forked packages Jeremy From martin.langhoff at gmail.com Thu Aug 28 23:24:14 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 29 Aug 2008 11:24:14 +1200 Subject: RFH: Anaconda install with alternative default disk layout (kickstart?) Message-ID: <46a038f90808281624if5f5c5fj574630b45d976ee4@mail.gmail.com> I suspect this is trivial for kickstart/anaconda experts -- and help would be appreciated with this. What I am after is a kickstart file to drive XS installs to have a default disk layout that is _different_ from the F9 default disk layout, and yet can be overriden by the user. I've seen kickstart scripts that force-change the screen to a specific console to ask interactive questions. Looked scary to my untrained eye... 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 katzj at redhat.com Thu Aug 28 23:26:14 2008 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 28 Aug 2008 19:26:14 -0400 Subject: State of Fedora spin In-Reply-To: <1219952008.15746.79.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> Message-ID: <1219965974.14533.21.camel@aglarond.local> On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote: > But with those taken care of, I can get an image built based on rawhide > + that kernel that boots. I then have to drop an xorg.conf in as the > driver is busted and doesn't manage to auto-config, but that too should > be fairly straight-forward to get fixed (bz#460581). Okay, the kernel[1] that I used for this is at http://katzj.fedorapeople.org/olpc/kernel/ (rpm + srpm). I then took the kickstart that Sebastian had started with and made it build on top of the base kickstarts in the spin-kickstarts repo[2] and built an image with livecd-creator pointed against today's rawhide. With the livecd-iso-to-disk script in the current livecd-tools[3] repo, you can do ./tools/livecd-iso-to-disk --xo olpc-gnome.iso /path/to/blkdev and get an image that can then be booted on the XO. If you use a USB stick, you'll do boot u:\olpc-usb.fth from OpenFirmware; SD card[4] should be boot sd:\olpc-sd.fth It then boots up into gdm and slowly manages to log into the desktop. I suspect that backing the persistence on the USB stick/SD card rather than in RAM[5] will help, but haven't tried that yet. Image can be grabbed for now at http://katzj.fedorapeople.org/olpc/olpc-gnome.iso Jeremy [1] Changes include: squashfs as previously done by Sebastian and Jim; enabling enough device-mapper stuff for dm_snapshot; adding call to new-kernel-pkg along with appropriate prereq. And I think that's it [2] http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=summary [3] http://git.fedorahosted.org/git/?p=livecd;a=summary [4] SD is untested as I left my SD card at the office yesterday apparently. [5] Using the usual options to livecd-iso-to-disk From martin.langhoff at gmail.com Thu Aug 28 23:19:47 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Fri, 29 Aug 2008 11:19:47 +1200 Subject: RFH: Script to make installable USB stick Message-ID: <46a038f90808281619y1b4fefb8u8620a47b4ffb0ef5@mail.gmail.com> As part of porting the XS to F9 I am moving from using live CDs to anaconda-based installer CDs. This has a fundamental benefit - that you can now upgrade from the CD as well as installing - but a downside: there are not easy tools to turn an installer CD into a bootble installer USB stick that "just works". A couple of weeks ago I started an attempt at it, based on livecd-iso-to-disk. It mostly worked - anaconda did get bootstrapped, but it failed to find the RPMs directory. I haven't had a change to look at it further. Help with it would be appreciated (and probably useful to Fedora users in general). Earlier discussion and patch: http://marc.info/?l=fedora-buildsys-list&m=121740636925259&w=2 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 robin.norwood at gmail.com Fri Aug 29 00:49:14 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Thu, 28 Aug 2008 20:49:14 -0400 Subject: RFH: Anaconda install with alternative default disk layout (kickstart?) In-Reply-To: <46a038f90808281624if5f5c5fj574630b45d976ee4@mail.gmail.com> References: <46a038f90808281624if5f5c5fj574630b45d976ee4@mail.gmail.com> Message-ID: On Thu, Aug 28, 2008 at 7:24 PM, Martin Langhoff wrote: > I suspect this is trivial for kickstart/anaconda experts -- and help > would be appreciated with this. > > What I am after is a kickstart file to drive XS installs to have a > default disk layout that is _different_ from the F9 default disk > layout, and yet can be overriden by the user. Well, you can do an 'interactive' kickstart, which basically means that the defaults are populated by the values in the kickstart, but the user still goes through the entire process. Otherwise... > I've seen kickstart scripts that force-change the screen to a specific > console to ask interactive questions. Looked scary to my untrained > eye... Yes, scary. How about two use cases: 1. Default install, just use a ks file provided by you. 2. Interactive install, using a kickstart file the same as the above, but in interactive mode. This covers partitioning, and any other random details installers may want to change. It's been awhile since I've tried an interactive ks, but it still seems to be a supported option. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From jg at laptop.org Fri Aug 29 12:37:58 2008 From: jg at laptop.org (Jim Gettys) Date: Fri, 29 Aug 2008 08:37:58 -0400 Subject: State of Fedora spin In-Reply-To: <1219963383.14533.9.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219955801.6567.191.camel@jg-vaio> <1219959334.14533.5.camel@aglarond.local> <1219962907.6567.204.camel@jg-vaio> <1219963383.14533.9.camel@aglarond.local> Message-ID: <1220013478.10050.16.camel@jg-vaio> On Thu, 2008-08-28 at 18:43 -0400, Jeremy Katz wrote: > > Compelling patches that are destined for the next Linus rev (... with > someone who's willing to own helping to fix them up if they break the > build) go in with some frequency. The big thing is that it's a > mentality shift. But the advantages you gain (both from thinking "get > kernel changes upstream Linus kernel" and "get packages changes in > upstream Fedora") end up making it so that going from Fedora 9->10->11 > becomes a far less difficult process. And then maybe we can get to > where the actual build being shipped on the XOs has few to no forked > packages > Yup. Also note that a properly configured kernel from Linus will now boot (just not a generic one); but it doesn't have everything we would like to have, much less patches to current drivers; for example, a dcon fix got pushed last night. On the device tree front, the issue is there are several versions out there, PPC, apple and Sun and us; so you have the usual reluctance to change. Andres will have some idea how this "discussion" is going. Some of what we have to do, however, will need some baking before they go upstream. Let me give you a concrete example. Right now, resume time is dominated by USB initialization (accounting for ~1 second out of our current 1.3 seconds). Some of it is slop, but other parts should be done by lazy evaluation, and will require some significant changes to the USB system. These will need some serious baking (but eventually speed resume for everyone, even if not as fast as we can go). And as the USB spec is poor, at best, and arbitrary busses can be hung off of it, when this work occurs, its baking will need to be careful. We believe our hardware is good down to 50ms, btw. - Jim -- Jim Gettys One Laptop Per Child From jg at laptop.org Fri Aug 29 12:42:27 2008 From: jg at laptop.org (Jim Gettys) Date: Fri, 29 Aug 2008 08:42:27 -0400 Subject: State of Fedora spin In-Reply-To: <1219965974.14533.21.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219965974.14533.21.camel@aglarond.local> Message-ID: <1220013747.10050.21.camel@jg-vaio> On Thu, 2008-08-28 at 19:26 -0400, Jeremy Katz wrote: > On Thu, 2008-08-28 at 15:33 -0400, Jeremy Katz wrote: > > But with those taken care of, I can get an image built based on rawhide > > + that kernel that boots. I then have to drop an xorg.conf in as the > > driver is busted and doesn't manage to auto-config, but that too should > > be fairly straight-forward to get fixed (bz#460581). > > Okay, the kernel[1] that I used for this is at > http://katzj.fedorapeople.org/olpc/kernel/ (rpm + srpm). > > I then took the kickstart that Sebastian had started with and made it > build on top of the base kickstarts in the spin-kickstarts repo[2] and > built an image with livecd-creator pointed against today's rawhide. > With the livecd-iso-to-disk script in the current livecd-tools[3] repo, > you can do > ./tools/livecd-iso-to-disk --xo olpc-gnome.iso /path/to/blkdev > and get an image that can then be booted on the XO. If you use a USB > stick, you'll do > boot u:\olpc-usb.fth > from OpenFirmware; SD card[4] should be > boot sd:\olpc-sd.fth > > It then boots up into gdm and slowly manages to log into the desktop. I > suspect that backing the persistence on the USB stick/SD card rather > than in RAM[5] will help, but haven't tried that yet. > > Image can be grabbed for now at > http://katzj.fedorapeople.org/olpc/olpc-gnome.iso > > Jeremy Cool! Thanks, Jermey.... Note that your milage will vary widely on USB, and if you happened to pick a slow USB stick you're performance can be dog slow. Also true for SD. The good news is that our hardware is decent for SD (in particular), and USB2 can be decent speed. The CAFE chip can drive SD to > 20MB/second. - Jim -- Jim Gettys One Laptop Per Child From jg at laptop.org Fri Aug 29 12:56:05 2008 From: jg at laptop.org (Jim Gettys) Date: Fri, 29 Aug 2008 08:56:05 -0400 Subject: State of Fedora spin In-Reply-To: <1219959334.14533.5.camel@aglarond.local> References: <1219700005.6567.65.camel@jg-vaio> <1219952008.15746.79.camel@aglarond.local> <1219955801.6567.191.camel@jg-vaio> <1219959334.14533.5.camel@aglarond.local> Message-ID: <1220014565.10050.28.camel@jg-vaio> On Thu, 2008-08-28 at 17:35 -0400, Jeremy Katz wrote: > > > > > Yes, because right now, our initrd for the anti-theft system is pretty > > magic, and gets built separately (on Debian, believe it or not, the last > > I heard). > > Ewwww :-) > I'm hoping this is a reflection of mixing two build systems (with which I agree), or you'll get me started on why I hate RPM :-)..... - Jim -- Jim Gettys One Laptop Per Child From martin.langhoff at gmail.com Sat Aug 30 06:46:35 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Sat, 30 Aug 2008 18:46:35 +1200 Subject: RFH - xs-rsync on F9 fails with an odd error Message-ID: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> More fun to be had debugging! Rsync and xinetd - those two old friends - are not playing ball, and there error is not something I've ever seen before. So if you have an F9 machine and want to debug something (and hopefully help craft a patch). To start, add a repo to your F9 box pointing to http://fedora.laptop.org/xs/testing/olpc/7/i386 - keep it disabled by default - I don't want a yum update to switch your desktop machine into a school server. Not yet at least. Notes: - that repo contains a single dangerous package. Do NOT dare install xs-config - it will reconfigure your machine in unexpected ways. Everything else is pretty sane. - even if harmless, the packages here will create a directory called /library - assuming you don't have a /library dir you use, all is safe... 1 - From that repo, install xs-rsync, most dependencies are harmless, (see cleanup notes later). 2 - xs-rsync by default binds to an odd address, edit the bind address in /etc/xinet.d/xs-rsync so that it listens on localhost 3 - ah, magic moment: run `rsync rsync://localhost/` - normally, it should list one directory: 'builds' (this is from /library/xs-rsync/pub feel free to put something there). On my system, it errors out, and /var/log/messages talks about getpeeraddr errors, which I've never seen before. Nor has google :-/ 4 - ??? 5 - patch! Cleanup: - You will probably want to remove xinetd, incron, and usbmount if you are not otherwise using them. - rm /library if there is no content of yours there. 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 robin.norwood at gmail.com Sat Aug 30 16:07:13 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Sat, 30 Aug 2008 12:07:13 -0400 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> Message-ID: On Sat, Aug 30, 2008 at 2:46 AM, Martin Langhoff wrote: > More fun to be had debugging! Rsync and xinetd - those two old friends > - are not playing ball, and there error is not something I've ever > seen before. > [...] Well, it looks like fakechroot is the culprit, fwiw. If I take your configs and remove the fakechroot bit from the serverargs line: server_args = -i /library/xs-rsync/state/rsyncd.all -- /usr/bin/rsync --daemon --config /etc/xs-rsyncd.conf It works fine. I dunno anything much about fakechroot, though. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From robin.norwood at gmail.com Sat Aug 30 16:12:15 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Sat, 30 Aug 2008 12:12:15 -0400 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> Message-ID: Argh, forgot replytoall again. On Sat, Aug 30, 2008 at 12:07 PM, Robin Norwood wrote: > On Sat, Aug 30, 2008 at 2:46 AM, Martin Langhoff > wrote: >> More fun to be had debugging! Rsync and xinetd - those two old friends >> - are not playing ball, and there error is not something I've ever >> seen before. >> [...] > > Well, it looks like fakechroot is the culprit, fwiw. If I take your > configs and remove the fakechroot bit from the serverargs line: > > server_args = -i /library/xs-rsync/state/rsyncd.all -- > /usr/bin/rsync --daemon --config /etc/xs-rsyncd.conf > > It works fine. > > I dunno anything much about fakechroot, though. Though I notice that rsync does some strange business to figure out the right args for getpeername() in configure.sh, and fakechroot seems to have it's own version of getpeername, et. al. so it's probably that getpeername from fakechroot uses different args than the system getpeername. And now I'm curious, so I'll poke around some more while the kids play Lego Indiana Jones. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From robin.norwood at gmail.com Sat Aug 30 16:28:57 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Sat, 30 Aug 2008 12:28:57 -0400 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> Message-ID: On Sat, Aug 30, 2008 at 12:12 PM, Robin Norwood wrote: > Though I notice that rsync does some strange business to figure out > the right args for getpeername() in configure.sh, and fakechroot seems > to have it's own version of getpeername, et. al. so it's probably that > getpeername from fakechroot uses different args than the system > getpeername. Yeah, I can confirm that fakechroot's getpeername() is the problem. If I remove getpeername from fakechroot [1], then I get a fakechroot that works with your test [2]. Obviously we need to instead sort out the parameters to match the system getpeername like rsync does. Not really my area of expertise, but I can file a bug in RH bugzilla for fakechroot when I get back. Got to run, now. [1] http://rnorwood.fedorapeople.org/robin-fakechroot.patch [2] http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.2.i386.rpm -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From robin.norwood at gmail.com Sat Aug 30 23:37:09 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Sat, 30 Aug 2008 19:37:09 -0400 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> Message-ID: On Sat, Aug 30, 2008 at 12:28 PM, Robin Norwood wrote: > On Sat, Aug 30, 2008 at 12:12 PM, Robin Norwood wrote: > Yeah, I can confirm that fakechroot's getpeername() is the problem. > If I remove getpeername from fakechroot [1], then I get a fakechroot > that works with your test [2]. Obviously we need to instead sort out > the parameters to match the system getpeername like rsync does. Not > really my area of expertise, but I can file a bug in RH bugzilla for > fakechroot when I get back. Got to run, now. Me again: https://bugzilla.redhat.com/show_bug.cgi?id=460753 Thanks, -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From martin.langhoff at gmail.com Sun Aug 31 21:39:46 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 1 Sep 2008 09:39:46 +1200 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> Message-ID: <46a038f90808311439x786f086hcacdb4760a695df1@mail.gmail.com> On Sun, Aug 31, 2008 at 4:28 AM, Robin Norwood wrote: > Yeah, I can confirm that fakechroot's getpeername() is the problem. > If I remove getpeername from fakechroot [1], then I get a fakechroot > that works with your test [2]. Obviously we need to instead sort out > the parameters to match the system getpeername like rsync does. Not > really my area of expertise, but I can file a bug in RH bugzilla for > fakechroot when I get back. Got to run, now. Thanks! From what I see in your patch, you're working around the problem by removing the local implementation of getpeername() so yes, I agree we'll want to see what upstream says about a proper fix. I'm not versed in the semantics of getpeername() so can't suggest anything smart at the moment. In the meantime, I'll use your package for testing and try to find out how serious it is that getpeername() gets through unwrapped. Thanks again! 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 robin.norwood at gmail.com Sun Aug 31 22:59:41 2008 From: robin.norwood at gmail.com (Robin Norwood) Date: Sun, 31 Aug 2008 18:59:41 -0400 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: <46a038f90808311439x786f086hcacdb4760a695df1@mail.gmail.com> References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> <46a038f90808311439x786f086hcacdb4760a695df1@mail.gmail.com> Message-ID: On Sun, Aug 31, 2008 at 5:39 PM, Martin Langhoff wrote: > On Sun, Aug 31, 2008 at 4:28 AM, Robin Norwood wrote: >> Yeah, I can confirm that fakechroot's getpeername() is the problem. >> If I remove getpeername from fakechroot [1], then I get a fakechroot >> that works with your test [2]. Obviously we need to instead sort out >> the parameters to match the system getpeername like rsync does. Not >> really my area of expertise, but I can file a bug in RH bugzilla for >> fakechroot when I get back. Got to run, now. > > Thanks! From what I see in your patch, you're working around the > problem by removing the local implementation of getpeername() so yes, > I agree we'll want to see what upstream says about a proper fix. > > I'm not versed in the semantics of getpeername() so can't suggest > anything smart at the moment. > > In the meantime, I'll use your package for testing and try to find out > how serious it is that getpeername() gets through unwrapped. Check the bug again, Axel added what I think is the correct fix. He's waiting of a response from upstream, but we should have the fix soon. https://bugzilla.redhat.com/show_bug.cgi?id=460753 http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.4.i386.rpm Is the one I built with Axel's patch, and it seems to work fine for me. Note that I bumped the release to the right of the dist tag, so when axel released -14 (or whatever), upgrades should work. -RN -- Robin Norwood "The Sage does nothing, yet nothing remains undone." -Lao Tzu, Te Tao Ching From martin.langhoff at gmail.com Sun Aug 31 23:11:01 2008 From: martin.langhoff at gmail.com (Martin Langhoff) Date: Mon, 1 Sep 2008 11:11:01 +1200 Subject: [Server-devel] RFH - xs-rsync on F9 fails with an odd error In-Reply-To: References: <46a038f90808292346g72ff192fiee38441e53d5e049@mail.gmail.com> <46a038f90808311439x786f086hcacdb4760a695df1@mail.gmail.com> Message-ID: <46a038f90808311611t5c7897b9if79b17b0fb5a5d7f@mail.gmail.com> On Mon, Sep 1, 2008 at 10:59 AM, Robin Norwood wrote: > Check the bug again, Axel added what I think is the correct fix. He's > waiting of a response from upstream, but we should have the fix soon. Yep, just got a gentle prod from Axel in private too :-) His patch looks good, and your comment about getsockname() is also interesting. > http://rnorwood.fedorapeople.org/fakechroot-2.8-13.fc9.4.i386.rpm > > Is the one I built with Axel's patch, and it seems to work fine for > me. Note that I bumped the release to the right of the dist tag, so > when axel released -14 (or whatever), upgrades should work. Cool. I'll use it for internal testing, and hope that upstream replies and Fedora updates get untagled before the next XS release :-) This is great. A few more pushes to the networking side, and we'll have a ported XS. 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