On Tuesday 12 August 2008 10:55:25 am Greg Dekoenigsberg wrote: 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 should not have been forked no longer using, using F-9 packages now needed to enable evdev. Fedora disables it rebuild against the old poppler we are using 0.6.x there is work to move to 0.7 olpc only though could likely live in fedora just fine using an old version not sure why. should not be needed. should be able to use fedora's branch dropped some dependencies can be unforked, changes were made to fedora's ntp, drops perl requirement should not be needed. should be able to use fedora's branch needs pyxpcom which is not enabled in fedora's xulrunner should not be needed. should be able to use fedora's branch minimal evince for the XO, should be in fedora and pulled in from there no longer using, using F-9 packages now is needed Droped perl no longer using, using F-9 packages now no longer using, using F-9 packages now not sure on this one 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. init doesnt run as pid 1 due to the way the intramfs runs should be fixed. needed to drop deps, package should be split up some so that we can use fedora's package its a subset of csound for the XO, we should make it so that csound provides the minimal needs of OLPC changed some keymappings, really should get fixed properly not sure on this one 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 no longer using, using F-9 packages now makes no sense on any other hardware though wouldnt hurt being in fedora. different macros for dist. probbaly should write a olpc-release just for olpc needed to drop perl dependency there is one plugin that pulls in perl should use fedora's needed version from rawhide to match totem. it had better Requires no longer using, using F-9 packages now needed to drop some dependencies 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

On Aug 12 2008, at 11:34, Dennis Gilmore was caught saying: [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(a)laptop.org

On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: 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 And more -- what sort of security is the problem here? dbus security is something that is kind of important, even for olpc. evdev just wasn't ready for f9. We're making another go at it for f10 now that whot is onboard afaik. caillon is very aware on this one 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 :-) /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

On Tue, 2008-08-12 at 14:43 -0500, Dennis Gilmore wrote: k 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 Why not just have olpc-dm as an option in prefdm? Then this would just work normally We setup keyboard rules for normal machines, how are these different? ? 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 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

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. 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 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. Dennis requested I look at these two, I will do so but have more important things to work on first. You'd have to ask the sugar developers. We can drop this fork for F10 since Adam made the changes in the devel branch. 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-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

On Tue, 12 Aug 2008 15:42:48 -0400 Daniel Drake <dsd(a)laptop.org&gt; wrote: Ah, then gnash should go on the 'forked for deps' list, and we should work to get those deps split out. 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. 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. Ok. As long as there's a need and a roadmap, having a fork isn't bad. Excellent. I'm going to try to get all this data in the wiki tonight so we don't lose track of it. 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

On Tue, 2008-08-12 at 14:28 -0400, Robin Norwood wrote: 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. 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. 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. Ugh; why a plugin would pull in perl is beyond me... 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 <jg(a)laptop.org&gt; One Laptop Per Child

On Wed, 2008-08-13 at 12:56 -0400, Jeremy Katz wrote: 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 <jg(a)laptop.org&gt; One Laptop Per Child

On Tue, Aug 12, 2008 at 9:25 PM, Greg Dekoenigsberg <gdk(a)redhat.com&gt; wrote: <..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]

On Tue, 12 Aug 2008 11:55:25 -0400 (EDT) Greg Dekoenigsberg <gdk(a)redhat.com&gt; wrote: 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