Re: Fedora Desktop on XO
Am Montag, den 12.01.2009, 14:41 -0500 schrieb Erik Garrison: > Here is an image builder which makes Fedora 10-based desktop images > for the XO. They use XFCE. Currently there is at least one > outstanding bug, which is that network manager applet won't start > because of security configuration problems with consolekit. Is this bug still present in Fedora? Has it ever been? Have you filed a bug? Where can I find any details or what else can I do to help you? TIA, Christoph ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Here is an image builder which makes Fedora 10-based desktop images for the XO. They use XFCE. Currently there is at least one outstanding bug, which is that network manager applet won't start because of security configuration problems with consolekit. http://dev.laptop.org/git/users/erik/rpmxo On Sun, Jan 11, 2009 at 12:55 PM, Christoph Wickert wrote: > Am Dienstag, den 06.01.2009, 17:31 -0500 schrieb Erik Garrison: >> On Tue, Jan 06, 2009 at 10:54:24PM +0100, Bert Freudenberg wrote: >> > >> > On 06.01.2009, at 22:34, Benjamin M. Schwartz wrote: >> > >> > > Carlos Nazareno wrote: >> > > >> > >> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool >> > > >> > > Currently, we are assuming that the issue will be RAM consumption, not >> > > CPU. I personally have no reason to expect either system to behave >> > > differently in terms of background CPU overhead or cost of common >> > > operations. >> > >> > >> > At 25c3 I bumped into a guy from LXDE. It's said to be a lot lighter >> > on resources than even XFCE. Unfortunately I did not stay long enough >> > to see it run on the XO, but maybe someone else did already? > > Yes. AFAICS it runs nice and very fast, although/because it is not > feature complete as Gnome or Xfce. > >> My impression from playing around with it is that it's significantly >> less polished than Gnome or XFCE. Polish takes time, users, and >> development... it just seems that LXDE hasn't had enough yet. >> >> You can just look at the age of the projects: >> >> GNOME 1999-03-03 (initial release) >> XFCE 1996 (project start date) >> LXDE 2006 (initial release) > > This is only partly true since a lot of the LXDE components are older, > for example lxpanel, pcmanfm and openbox. > >> [dates pulled from Wikipedia] >> >> As far as I know all these projects have been under development >> continuously since their inception. Two, GNOME and XFCE, have had >> extremely large user bases. It does not seem that LXDE has. > > The Xfce user base is not that large as one might think. On the other > hand LXDE is very popular in Asia, for example in Taiwan. In Brasil > several vendors offer netbooks with LXDE and Mandriva preinstalled. > >> >> Erik > > Regards, > Christoph > > (Fedora package maintainer for both Xfce and LXDE) > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Am Dienstag, den 06.01.2009, 17:31 -0500 schrieb Erik Garrison: > On Tue, Jan 06, 2009 at 10:54:24PM +0100, Bert Freudenberg wrote: > > > > On 06.01.2009, at 22:34, Benjamin M. Schwartz wrote: > > > > > Carlos Nazareno wrote: > > > > > >> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool > > > > > > Currently, we are assuming that the issue will be RAM consumption, not > > > CPU. I personally have no reason to expect either system to behave > > > differently in terms of background CPU overhead or cost of common > > > operations. > > > > > > At 25c3 I bumped into a guy from LXDE. It's said to be a lot lighter > > on resources than even XFCE. Unfortunately I did not stay long enough > > to see it run on the XO, but maybe someone else did already? Yes. AFAICS it runs nice and very fast, although/because it is not feature complete as Gnome or Xfce. > My impression from playing around with it is that it's significantly > less polished than Gnome or XFCE. Polish takes time, users, and > development... it just seems that LXDE hasn't had enough yet. > > You can just look at the age of the projects: > > GNOME 1999-03-03 (initial release) > XFCE 1996 (project start date) > LXDE 2006 (initial release) This is only partly true since a lot of the LXDE components are older, for example lxpanel, pcmanfm and openbox. > [dates pulled from Wikipedia] > > As far as I know all these projects have been under development > continuously since their inception. Two, GNOME and XFCE, have had > extremely large user bases. It does not seem that LXDE has. The Xfce user base is not that large as one might think. On the other hand LXDE is very popular in Asia, for example in Taiwan. In Brasil several vendors offer netbooks with LXDE and Mandriva preinstalled. > > Erik Regards, Christoph (Fedora package maintainer for both Xfce and LXDE) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Fri, Jan 9, 2009 at 3:24 AM, Tomeu Vizoso wrote: > On Fri, Jan 9, 2009 at 09:21, C. Scott Ananian wrote: >> On Wed, Jan 7, 2009 at 11:00 AM, John Gilmore wrote: I'm very interested on this, as it would give us also for free a FUSE interface. Why I haven't pursued it yet is because the API for developing new gio backends is still private and our new backend would then need to live inside the gvfs gnome module or as a patch in every distro. Aside from having to periodically adapt to any API changes. See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html That said, such a backend would be very simple, for the journal in Sugar 0.84. >>> >>> Hi Tomeu, I'd say write the simple backend and submit it upstream. Their >>> interface sounds very much like every other interface in a computer, >>> i.e. not quite done right in retrospect and always subject to change. >>> Their mailing list only got a dozen messsages that month -- it's not >>> evolving SO fast. Host the code in their gnome module and then it'll >>> evolve along with the module and also go into each distro. >>> >>> My idea is that when an ordinary GUI program pops up an "Open File" >>> dialog, if an OLPC Journal exists for that user, it will be one of the >>> icons in the left column (like "Desktop" or "File System" or each >>> mounted removable storage device). If Journal is already the default, >>> or is selected, then the filename and type are pre-defaulted, though >>> the user can override them by typing. >>> >>> Even on a sugarized OLPC, people are going to neet to touch files that >>> have real names in the real filesystem (e.g. Python source code, >>> config files, even new firmware downloads) as well as Journal entries, >>> so they'll need ways to pick things OTHER than the Journal, too. >>> >>> This design would also let people try out the Journal concept, just by >>> "apt-get install olpc-journal" and starting it up. Then by picking >>> Journal in the file dialog or file browser, it will arrange the files >>> that they save or read, by date of access in one big glob, with tags >>> or whatever, rather than making them pick hierarchical names. This >>> would all happen modularly, without installing the Sugar GUI. (It >>> would only be interfaced to Sugar and Gnome, but maybe other desktops >>> would get the hint.) >>> >>> This would also be a really cheap way to browse USB keys, etc. Open >>> two Gnome file browsers (one hierarchical in USB key; the other in >>> Journal) and drag things back and forth. The code's already there, >>> it just lacks this one interface. >> >> John, I don't know if you ever saw: >> http://wiki.laptop.org/go/Journal,_reloaded >> >> Given the massive disruption to the status quo, I'm not sure that I >> would attempt to argue for one approach over the other; just noting >> that there is an alternative. > > For the record, I think that Scott's approach is the best if it can be > put to work. I agree. From a user experience point of view, I think something much closer in functionality to Scott's prototype would be a big step forward for the Journal. I never had the chance to make proper mockups of what it could ultimately look like in Sugar, but I hope to still have the opportunity to do that. - Eben > If I'm working on something else is because we need to ship something > better than what we had and didn't saw so clear how we could do it > given the resources we have and all the open questions that there are. > > Regards, > > Tomeu > ___ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Fri, Jan 9, 2009 at 5:08 AM, Peter Robinson wrote: >>> > For the evince vs sugar-evince I suspect we need to try and get the >>> > mainline evince split out into evince and evince-libs so that we >>> > can build sugar-evince against it similar to what we do with >>> > abiword and write (I think that's its name). >>> >>> Yep, sounds good. >> >> When I get a sec I'll look at what's required and file a RH bug for >> evince to see if we can't get the package split up. > > BTW where does the current sugar-evince srpm live? In koji. Here is the diff against the corresponding evince version: http://dev.laptop.org/git?p=users/dsd/sugar-evince;a=commitdiff;h=d9b354a9318b6a99fa7ae185495b94431ab142c9 There are some changes to the core evince source which means that it will be more than just splitting up the F10 evince package. But that will certainly be a step in the right direction. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Fri, Jan 9, 2009 at 09:21, C. Scott Ananian wrote: > On Wed, Jan 7, 2009 at 11:00 AM, John Gilmore wrote: >>> I'm very interested on this, as it would give us also for free a FUSE >>> interface. Why I haven't pursued it yet is because the API for >>> developing new gio backends is still private and our new backend would >>> then need to live inside the gvfs gnome module or as a patch in every >>> distro. Aside from having to periodically adapt to any API changes. >>> >>> See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html >>> >>> That said, such a backend would be very simple, for the journal in Sugar >>> 0.84. >> >> Hi Tomeu, I'd say write the simple backend and submit it upstream. Their >> interface sounds very much like every other interface in a computer, >> i.e. not quite done right in retrospect and always subject to change. >> Their mailing list only got a dozen messsages that month -- it's not >> evolving SO fast. Host the code in their gnome module and then it'll >> evolve along with the module and also go into each distro. >> >> My idea is that when an ordinary GUI program pops up an "Open File" >> dialog, if an OLPC Journal exists for that user, it will be one of the >> icons in the left column (like "Desktop" or "File System" or each >> mounted removable storage device). If Journal is already the default, >> or is selected, then the filename and type are pre-defaulted, though >> the user can override them by typing. >> >> Even on a sugarized OLPC, people are going to neet to touch files that >> have real names in the real filesystem (e.g. Python source code, >> config files, even new firmware downloads) as well as Journal entries, >> so they'll need ways to pick things OTHER than the Journal, too. >> >> This design would also let people try out the Journal concept, just by >> "apt-get install olpc-journal" and starting it up. Then by picking >> Journal in the file dialog or file browser, it will arrange the files >> that they save or read, by date of access in one big glob, with tags >> or whatever, rather than making them pick hierarchical names. This >> would all happen modularly, without installing the Sugar GUI. (It >> would only be interfaced to Sugar and Gnome, but maybe other desktops >> would get the hint.) >> >> This would also be a really cheap way to browse USB keys, etc. Open >> two Gnome file browsers (one hierarchical in USB key; the other in >> Journal) and drag things back and forth. The code's already there, >> it just lacks this one interface. > > John, I don't know if you ever saw: > http://wiki.laptop.org/go/Journal,_reloaded > > Given the massive disruption to the status quo, I'm not sure that I > would attempt to argue for one approach over the other; just noting > that there is an alternative. For the record, I think that Scott's approach is the best if it can be put to work. If I'm working on something else is because we need to ship something better than what we had and didn't saw so clear how we could do it given the resources we have and all the open questions that there are. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Wed, Jan 7, 2009 at 11:00 AM, John Gilmore wrote: >> I'm very interested on this, as it would give us also for free a FUSE >> interface. Why I haven't pursued it yet is because the API for >> developing new gio backends is still private and our new backend would >> then need to live inside the gvfs gnome module or as a patch in every >> distro. Aside from having to periodically adapt to any API changes. >> >> See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html >> >> That said, such a backend would be very simple, for the journal in Sugar >> 0.84. > > Hi Tomeu, I'd say write the simple backend and submit it upstream. Their > interface sounds very much like every other interface in a computer, > i.e. not quite done right in retrospect and always subject to change. > Their mailing list only got a dozen messsages that month -- it's not > evolving SO fast. Host the code in their gnome module and then it'll > evolve along with the module and also go into each distro. > > My idea is that when an ordinary GUI program pops up an "Open File" > dialog, if an OLPC Journal exists for that user, it will be one of the > icons in the left column (like "Desktop" or "File System" or each > mounted removable storage device). If Journal is already the default, > or is selected, then the filename and type are pre-defaulted, though > the user can override them by typing. > > Even on a sugarized OLPC, people are going to neet to touch files that > have real names in the real filesystem (e.g. Python source code, > config files, even new firmware downloads) as well as Journal entries, > so they'll need ways to pick things OTHER than the Journal, too. > > This design would also let people try out the Journal concept, just by > "apt-get install olpc-journal" and starting it up. Then by picking > Journal in the file dialog or file browser, it will arrange the files > that they save or read, by date of access in one big glob, with tags > or whatever, rather than making them pick hierarchical names. This > would all happen modularly, without installing the Sugar GUI. (It > would only be interfaced to Sugar and Gnome, but maybe other desktops > would get the hint.) > > This would also be a really cheap way to browse USB keys, etc. Open > two Gnome file browsers (one hierarchical in USB key; the other in > Journal) and drag things back and forth. The code's already there, > it just lacks this one interface. John, I don't know if you ever saw: http://wiki.laptop.org/go/Journal,_reloaded Given the massive disruption to the status quo, I'm not sure that I would attempt to argue for one approach over the other; just noting that there is an alternative. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
>> > For the evince vs sugar-evince I suspect we need to try and get the >> > mainline evince split out into evince and evince-libs so that we >> > can build sugar-evince against it similar to what we do with >> > abiword and write (I think that's its name). >> >> Yep, sounds good. > > When I get a sec I'll look at what's required and file a RH bug for > evince to see if we can't get the package split up. BTW where does the current sugar-evince srpm live? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
>> I'm very interested on this, as it would give us also for free a FUSE >> interface. Why I haven't pursued it yet is because the API for >> developing new gio backends is still private and our new backend would >> then need to live inside the gvfs gnome module or as a patch in every >> distro. Aside from having to periodically adapt to any API changes. >> >> See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html >> >> That said, such a backend would be very simple, for the journal in Sugar >> 0.84. > > Hi Tomeu, I'd say write the simple backend and submit it upstream. Their > interface sounds very much like every other interface in a computer, > i.e. not quite done right in retrospect and always subject to change. > Their mailing list only got a dozen messsages that month -- it's not > evolving SO fast. Host the code in their gnome module and then it'll > evolve along with the module and also go into each distro. I agree, and then if there are any API changes its likely that when there is they'll update all the shipped modules to support it which would leave less work over time for maintenance. > My idea is that when an ordinary GUI program pops up an "Open File" > dialog, if an OLPC Journal exists for that user, it will be one of the > icons in the left column (like "Desktop" or "File System" or each > mounted removable storage device). If Journal is already the default, > or is selected, then the filename and type are pre-defaulted, though > the user can override them by typing. > > Even on a sugarized OLPC, people are going to neet to touch files that > have real names in the real filesystem (e.g. Python source code, > config files, even new firmware downloads) as well as Journal entries, > so they'll need ways to pick things OTHER than the Journal, too. > > This design would also let people try out the Journal concept, just by > "apt-get install olpc-journal" and starting it up. Then by picking > Journal in the file dialog or file browser, it will arrange the files > that they save or read, by date of access in one big glob, with tags > or whatever, rather than making them pick hierarchical names. This > would all happen modularly, without installing the Sugar GUI. (It > would only be interfaced to Sugar and Gnome, but maybe other desktops > would get the hint.) This would be great! Also would possibly encourage more 3rd party developers. > This would also be a really cheap way to browse USB keys, etc. Open > two Gnome file browsers (one hierarchical in USB key; the other in > Journal) and drag things back and forth. The code's already there, > it just lacks this one interface. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Erik Garrison wrote: > On Wed, Jan 07, 2009 at 07:47:36AM +0530, Rahul Sundaram wrote: >> One thing, we try not to do, is deviate from upstream and apply many >> patches like some of the other Xfce based spin-off's do which is a >> general Fedora policy as well and not something specific to the Xfce >> team. > > The patches I described (e.g. desktop icon creation) appear to have > been backported from the development version of XFCE. Is backporting > patches from the mainline XFCE development against policy? There isn't a strict policy against anything, there is a set of recommendations outlined at http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream https://fedoraproject.org/wiki/Packaging/Guidelines#All_patches_should_have_an_upstream_bug_link_or_comment Backporting is usually more accepted since the upstream path is clear and we don't have carry them forever. If you have specific suggestions (and pointers to those patches if any), then please report them in bugzilla and the maintainers involved can consider them on a case by case basis. If you wish to discuss ideas, post to fedora-devel list or ping nirik (Kevin Fenzi) in #fedora-devel. I am mether on irc and available on all the usual channels as well. Rahul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Wed, Jan 07, 2009 at 07:47:36AM +0530, Rahul Sundaram wrote: > > One thing, we try not to do, is deviate from upstream and apply many > patches like some of the other Xfce based spin-off's do which is a > general Fedora policy as well and not something specific to the Xfce > team. The patches I described (e.g. desktop icon creation) appear to have been backported from the development version of XFCE. Is backporting patches from the mainline XFCE development against policy? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Wed, Jan 07, 2009 at 07:47:36AM +0530, Rahul Sundaram wrote: > Peter Robinson wrote: > >> >> I don't believe that is true at all. I believe XFCE is an install >> option during a full install and there's a fully Fedora blessed XFCE >> spin available from Fedora here http://spins.fedoraproject.org/ . It >> is certainly not the main desktop they support but it is no less >> supported than any other desktop. I think the XFCE SIG (Special >> Interest Group would somewhat disagree >> https://fedoraproject.org/wiki/SIGs/Xfce > > As the maintainer of the the Xfce Live CD as well as a member of the > SIG, I can vouch for that. Xfce is a pretty well "supported" desktop in > Fedora in as much as any desktop is. The maintainers take care of bugs > quickly, new releases gets pulled in fast etc. We don't have as many > people working on it but it is a smaller community upstream as well. Ok. This is good to know. I had heard differently and not pursued more details. > One thing, we try not to do, is deviate from upstream and apply many > patches like some of the other Xfce based spin-off's do which is a > general Fedora policy as well and not something specific to the Xfce > team. My apologies. I was not well informed. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
> I'm very interested on this, as it would give us also for free a FUSE > interface. Why I haven't pursued it yet is because the API for > developing new gio backends is still private and our new backend would > then need to live inside the gvfs gnome module or as a patch in every > distro. Aside from having to periodically adapt to any API changes. > > See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html > > That said, such a backend would be very simple, for the journal in Sugar 0.84. Hi Tomeu, I'd say write the simple backend and submit it upstream. Their interface sounds very much like every other interface in a computer, i.e. not quite done right in retrospect and always subject to change. Their mailing list only got a dozen messsages that month -- it's not evolving SO fast. Host the code in their gnome module and then it'll evolve along with the module and also go into each distro. My idea is that when an ordinary GUI program pops up an "Open File" dialog, if an OLPC Journal exists for that user, it will be one of the icons in the left column (like "Desktop" or "File System" or each mounted removable storage device). If Journal is already the default, or is selected, then the filename and type are pre-defaulted, though the user can override them by typing. Even on a sugarized OLPC, people are going to neet to touch files that have real names in the real filesystem (e.g. Python source code, config files, even new firmware downloads) as well as Journal entries, so they'll need ways to pick things OTHER than the Journal, too. This design would also let people try out the Journal concept, just by "apt-get install olpc-journal" and starting it up. Then by picking Journal in the file dialog or file browser, it will arrange the files that they save or read, by date of access in one big glob, with tags or whatever, rather than making them pick hierarchical names. This would all happen modularly, without installing the Sugar GUI. (It would only be interfaced to Sugar and Gnome, but maybe other desktops would get the hint.) This would also be a really cheap way to browse USB keys, etc. Open two Gnome file browsers (one hierarchical in USB key; the other in Journal) and drag things back and forth. The code's already there, it just lacks this one interface. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
> I'm not seeing a menu, even after killing ohmd, with "When the power > button is pressed: Ask me" chosen in the g-p-m prefs. Dunno why yet. This works in debXO 0.4, I use it all the time. Ask dilinger how he made it work. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Peter Robinson wrote: > > I don't believe that is true at all. I believe XFCE is an install > option during a full install and there's a fully Fedora blessed XFCE > spin available from Fedora here http://spins.fedoraproject.org/ . It > is certainly not the main desktop they support but it is no less > supported than any other desktop. I think the XFCE SIG (Special > Interest Group would somewhat disagree > https://fedoraproject.org/wiki/SIGs/Xfce As the maintainer of the the Xfce Live CD as well as a member of the SIG, I can vouch for that. Xfce is a pretty well "supported" desktop in Fedora in as much as any desktop is. The maintainers take care of bugs quickly, new releases gets pulled in fast etc. We don't have as many people working on it but it is a smaller community upstream as well. One thing, we try not to do, is deviate from upstream and apply many patches like some of the other Xfce based spin-off's do which is a general Fedora policy as well and not something specific to the Xfce team. Rahul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
>> Does pilgrim (Puritan?) use "kickstart" like files? > > Nope. > >> If not, why do we not create builds using what seems to be fedora's >> standard build system? > > The short answer is that there has never been consensus among the people > dealing with OLPC's builds that anaconda was the right tool for the job. I think also that alot of the automated tools that are now used to build the various Fedora stuff (mock / koji / livecd-tools / appliance-tools) wouldn't have been around when OLPC was first looking for a build system > The longer answer involves a lot of politics which I'm /really/ not > interested in stirring up but which are unavoidable if you want to > really understand how things came to be the way that they are. In order > to navigate this quandary, I'm going to offer you a series of > thought-questions which, I hope, will lead you to your own answer to > your question. No argument there. > (If you want, you can ask me tomorrow for my answers to them but you > should try to construct your own answers first.) > > Hope this helps, > > Michael > > - > > a) Requirements. > > 1. What do you think a build system for OLPC and for XOs needs to do? Simplistically build a working bootable OLPC system, but to do that it is required to deal with the boot system, filesystems, storage, security, signing etc of all of the above. > 2. What explorations have been made in the area of XO-related build > systems? I think the major differences between a standard Fedora system and an OLPC system WRT a build system is the underlying stuff like the boot (lack of BIOS, security etc), the filesystems used, and OLPC security related stuff. > 3. What lists of requirements (or audiences) do each of these > explorations seem to be trying to satisfy? a lot of them, and a mostly moving target as the project matures and so do the tools around it. > b) History & Incumbency of Pilgrim. > > 1. Why did davidz write pilgrim? At a guess because the likes of livecd-tools and appliance-tools either didn't exist or were mature enough to meet the needs of OLPC at the time they were required. > 2. Why did pilgrim not use anaconda? Didn't meet the current requirements of OLPC at the time. Probably a number of other reasons to do with politics and various other related issues with the size/complexity of it because it handles everything from a server to a netbook running on a platform of i386 right through PPC and IA-64 from a small amount of RAM to terabytes and everything else most of which isn't an issue to OLPC which runs on essentially a single piece of hardware. > 3. Why did davidz later write livecd-tools using anaconda? > > 4. What do you have to do in order to get OLPC to use a different > build system? A lot of work and testing for regressions. > c) People & Politics Not even going to try to answer these ones but no doubt they change with time and what is relevant now has probably changed someone since the beginning. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 07:40:07PM -0500, Reuben K. Caron wrote: > Peter Robinson wrote: >> Hi Chris, >> >> >>> > I would remove the old fc9 build from the olpc_development repo (or >>> > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed >>> > up). Surely it should be pulling cyrus-sasl from the Fedora repos >>> > anyway? >>> >>> I've just pushed a patch to pilgrim's joyride branch to switch the >>> baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo >>> from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to >>> http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ >>> >>> (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride >>> should have been switched to write out the olpc4 baseurl when we >>> created the new repo.) >>> >>> And, after the change, we don't have depsolving problems any more! >>> Here's the list of packages to be downloaded -- the next question is >>> going to be how to avoid many of these dependencies. Perhaps instead >>> of trying the groupinstall, we should be hand-picking a smaller base >>> of GNOME packages from this list? >>> >> >> Well its the list up to the "Installing for dependencies" that is >> explicitly requested, all the below is pulled in for deps. I'm not >> sure how pilgrim builds the list but I think if it uses kickstart like >> the other fedora build systems do you should be able to do a specific >> "-packagename" and its removed from the list. >> >> > Does pilgrim (Puritan?) use "kickstart" like files? Nope. > If not, why do we not create builds using what seems to be fedora's > standard build system? The short answer is that there has never been consensus among the people dealing with OLPC's builds that anaconda was the right tool for the job. The longer answer involves a lot of politics which I'm /really/ not interested in stirring up but which are unavoidable if you want to really understand how things came to be the way that they are. In order to navigate this quandary, I'm going to offer you a series of thought-questions which, I hope, will lead you to your own answer to your question. (If you want, you can ask me tomorrow for my answers to them but you should try to construct your own answers first.) Hope this helps, Michael - a) Requirements. 1. What do you think a build system for OLPC and for XOs needs to do? 2. What explorations have been made in the area of XO-related build systems? 3. What lists of requirements (or audiences) do each of these explorations seem to be trying to satisfy? b) History & Incumbency of Pilgrim. 1. Why did davidz write pilgrim? 2. Why did pilgrim not use anaconda? 3. Why did davidz later write livecd-tools using anaconda? 4. What do you have to do in order to get OLPC to use a different build system? c) People & Politics 1. Who has worked on build-system stuff for XOs? for OLPC? 2. How might we describe their knowledge, skills, interests, aims, etc at the time? 3. What demands were placed on them at the time they worked on build-system related things? 4. How should we describe their relationships with one another? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Chris, > > For the evince vs sugar-evince I suspect we need to try and get the > > mainline evince split out into evince and evince-libs so that we > > can build sugar-evince against it similar to what we do with > > abiword and write (I think that's its name). > > Yep, sounds good. When I get a sec I'll look at what's required and file a RH bug for evince to see if we can't get the package split up. > > As for the gconf2-dbus.. I know that's used over the usual dbus > > to drop out the bonobo dependencies but whether that is still a > > factor at the moment with the other things that pull bonobo in I'm > > not sure so it might be worthwhile working out whether we stick > > with it or move back to the mainline version. Not sure who knows > > the answer to that one, I know DSD got it compiled up but other > > than that I don't know the best person to ask. > > I think the reason we're using GConf2-dbus is actually that plain GConf2 > didn't work with Rainbow's preforking code after the move to F10, but > we've reverted that preforking code for the moment, so perhaps we could > just use plain GConf2.. If we can get a definite confirmation of that I'll untag the GConf2-dbus build so that the original GConf gets pulled into joyride and see where we end up from there. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Peter, > Good news. I'm aware of the conflicts you mention. I'm not sure > that we need evince-dvi (not sure if its a requirement of anything > though and hence gets pulled in automatically). That's right, we don't need it. It's part of the groupinstall, but it's not depended on otherwise (and was split out so that people could choose to omit it). > For the evince vs sugar-evince I suspect we need to try and get the > mainline evince split out into evince and evince-libs so that we > can build sugar-evince against it similar to what we do with > abiword and write (I think that's its name). Yep, sounds good. > As for the gconf2-dbus.. I know that's used over the usual dbus > to drop out the bonobo dependencies but whether that is still a > factor at the moment with the other things that pull bonobo in I'm > not sure so it might be worthwhile working out whether we stick > with it or move back to the mainline version. Not sure who knows > the answer to that one, I know DSD got it compiled up but other > than that I don't know the best person to ask. I think the reason we're using GConf2-dbus is actually that plain GConf2 didn't work with Rainbow's preforking code after the move to F10, but we've reverted that preforking code for the moment, so perhaps we could just use plain GConf2.. Thanks! - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Chris, > > How did you go with this? Did you have any luck? I also realised > > that if you drop gnome-user-share you'll drop all the httpd > > requirements. > > Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, > both ship the same .mo files) and evince (against sugar-evince, both > ship the same evince backend shared libraries). Also, it turns out > that evince-dvi is responsible for bringing in texlive, via kpathsea. Good news. I'm aware of the conflicts you mention. I'm not sure that we need evince-dvi (not sure if its a requirement of anything though and hence gets pulled in automatically). For the evince vs sugar-evince I suspect we need to try and get the mainline evince split out into evince and evince-libs so that we can build sugar-evince against it similar to what we do with abiword and write (I think that's its name). As for the gconf2-dbus.. I know that's used over the usual dbus to drop out the bonobo dependencies but whether that is still a factor at the moment with the other things that pull bonobo in I'm not sure so it might be worthwhile working out whether we stick with it or move back to the mainline version. Not sure who knows the answer to that one, I know DSD got it compiled up but other than that I don't know the best person to ask. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Peter Robinson wrote: Hi Chris, > I would remove the old fc9 build from the olpc_development repo (or > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed > up). Surely it should be pulling cyrus-sasl from the Fedora repos > anyway? I've just pushed a patch to pilgrim's joyride branch to switch the baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride should have been switched to write out the olpc4 baseurl when we created the new repo.) And, after the change, we don't have depsolving problems any more! Here's the list of packages to be downloaded -- the next question is going to be how to avoid many of these dependencies. Perhaps instead of trying the groupinstall, we should be hand-picking a smaller base of GNOME packages from this list? Well its the list up to the "Installing for dependencies" that is explicitly requested, all the below is pulled in for deps. I'm not sure how pilgrim builds the list but I think if it uses kickstart like the other fedora build systems do you should be able to do a specific "-packagename" and its removed from the list. Does pilgrim (Puritan?) use "kickstart" like files? If so, how? If not, why do we not create builds using what seems to be fedora's standard build system? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
> Now, the question I have is why we would chose GNOME over XFCE. I think > there are significant differences in system resource consumption. I don't believe the decision has been made yet. > I ask because the impression I had from informal tests was that a system > booting into GNOME was consuming about 3x as much RAM on boot (read via > ps_mem.py). My impression was that the benefit was not eaten up the > moment the I started running GTK applications; it seemed that under XFCE > I could open a fair number more Firefox tabs without running into lockup > than under GNOME. I know these aren't great metrics so I'll run some > more rigorous tests after we have two systems side-by-side for > comparison. > > Even though XFCE is not a Fedora-supported desktop environment, it is > readily supported in other distributions. We could easily borrow the > polish that XUbuntu has applied to its distribution and get a system > equally usable as GNOME. I don't believe that is true at all. I believe XFCE is an install option during a full install and there's a fully Fedora blessed XFCE spin available from Fedora here http://spins.fedoraproject.org/ . It is certainly not the main desktop they support but it is no less supported than any other desktop. I think the XFCE SIG (Special Interest Group would somewhat disagree https://fedoraproject.org/wiki/SIGs/Xfce Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Paul, > i was actually thinking in the other direction: if the ohmd action > were disabled, i assume we'd get the g-p-m screen. is that screen > tuneable? if g-p-m is possibly going in anyway, it might obviate > the power button menu work. I'm not seeing a menu, even after killing ohmd, with "When the power button is pressed: Ask me" chosen in the g-p-m prefs. Dunno why yet. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
9.1.0 Schedule (Was Re: Fedora Desktop on XO)
On Tue, Jan 6, 2009 at 4:48 PM, Michael Stone wrote: > Greg, > > I don't mean to be nasty, but I do feel the need to be blunt: > > On Tue, Jan 06, 2009 at 04:28:36PM -0500, Greg Smith wrote: >> Hi Michael, >> >> We are definitely behind where I would like to be at this stage. > > How far behind? I work in an environment where products are always shipped on time. We are given a deadline to finish the project, which is usually a few months before the product actually ships. We have to finish the project by this deadline, and we believe it. Privately, the management team knows the real date the product must be finished by in order to be manufactured in time to coincide with marketing pushes, holidays, etc. As we reach and pass our first deadline, we are given new drop dead deadlines and we believe them. Absolute honesty in scheduling is not necessarily a good thing. Another way to put it is, you don't win a war without losing any battles. Adding big, scary features to 9.1.0 without stop-shipment level reason just because you know you are going to miss it anyway seems like a bad idea. Regarding filesystem choice, I would lean towards trying to enable swap on JFFS2, or eliminating the need for swap by choosing a lighter setup or enforcing RAM usage restrictions on program startup and adding RAM exhaustion warnings to the UI. Best, -Wade ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Greg, > The choice of file system isn't a deal breaker for the Fedora > Desktop feature. The hard part will be picking the right desktop > (more on that soon, I already love the dancing benchmark bears :-), > making it fit on the NAND, and testing it enough to prove its > usable. The F10 desktop we shipped on SD had swap. Our current JFFS2 filesystem doesn't support swap. I don't think you have any evidence for us being able to avoid a deal-breaker without adding swap, so I disagree. If we can't find either a way to get a swap file working on JFFS2 or get UBI working, maybe it does make more sense to use XFCE (and even that might not work out well). I don't have a desire to ship something with worse performance than the F10 SD build. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Michael, No problem being blunt. I don't know yet how far behind we are or what it will take to catch up. We are close if we create a target bug list in the next two weeks then start daily triage and weekly test blitzes. Quality is my primary concern, especially if you throw in a lot of new code and potential process changes with Sugar. Once we get building and testing, it will be a matter of code quality and how quickly can we fix important bugs. On the feature front, my main concern is security/activation/lease management features. Point #2 here: http://wiki.laptop.org/go/9.1.0#Top_Priority Good progress on signing delegation and faster imaging. However, lease management and image customization need some love. They are critical for Ethiopia and Peru and others. In short, we have a good chance to release with major new features in March. We just need to pick up the pace and keep people focused. In terms of the thread, Deepak said that a replacement for JFFS2 is not in the plan for 9.1.0. I agree. It needs more work from a test/design perspective and it needs better definition of the ROI (work effort vs benefit). The choice of file system isn't a deal breaker for the Fedora Desktop feature. The hard part will be picking the right desktop (more on that soon, I already love the dancing benchmark bears :-), making it fit on the NAND, and testing it enough to prove its usable. Thanks, Greg S Michael Stone wrote: > Greg, > > I don't mean to be nasty, but I do feel the need to be blunt: > > On Tue, Jan 06, 2009 at 04:28:36PM -0500, Greg Smith wrote: >> Hi Michael, >> >> We are definitely behind where I would like to be at this stage. > > How far behind? > >> However, we'll only move the date when we must and we'll only do it >> to improve quality > > What exactly did you think Deepak and Chris were discussing doing? > Michael > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 10:54:24PM +0100, Bert Freudenberg wrote: > > On 06.01.2009, at 22:34, Benjamin M. Schwartz wrote: > > > Carlos Nazareno wrote: > > > >> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool > > > > Currently, we are assuming that the issue will be RAM consumption, not > > CPU. I personally have no reason to expect either system to behave > > differently in terms of background CPU overhead or cost of common > > operations. > > > At 25c3 I bumped into a guy from LXDE. It's said to be a lot lighter > on resources than even XFCE. Unfortunately I did not stay long enough > to see it run on the XO, but maybe someone else did already? My impression from playing around with it is that it's significantly less polished than Gnome or XFCE. Polish takes time, users, and development... it just seems that LXDE hasn't had enough yet. You can just look at the age of the projects: GNOME 1999-03-03 (initial release) XFCE 1996 (project start date) LXDE 2006 (initial release) [dates pulled from Wikipedia] As far as I know all these projects have been under development continuously since their inception. Two, GNOME and XFCE, have had extremely large user bases. It does not seem that LXDE has. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
> Currently, we are assuming that the issue will be RAM consumption, not CPU. > I personally have no reason to expect either system to behave differently > in terms of background CPU overhead or cost of common operations. Well, in any case, it really wouldn't hurt to benchmark the CPU consumption of different window managers would it? Would it be okay for you guys playing with GNOME and XFCE to do this so we can compare? >> In XO OS 8.2.0 + Sugar with no other activities running, I'm getting >> 5.5-5.65fps on Browse Activity and around 8.5fps on Opera 9.63 >> (non-sugar) > > If both browsers were using the same SWF plugin, then this is extremely > remarkable, and merits investigation. They're both using the same Adobe Flash 10 fedora rpm plugin. I haven't installed the Flash .tgz version for the Firefox Activity yet for testing, but it will most likely run at the same FPS as the Browse Activity. There's nothing really remarkable about the discrepancy between the framerates in Browse and Opera. As I said, Browse (as well as the Firefox 0.6 Activity I believe) artificially zooms in content being displayed in pages. Since SWFs are being scaled up artificially by default in Browse, the CPU is working much harder because it's processing more pixels (rescaling bitmaps in this case of TeddyMark or rasterizing more pixels in the case of vector content). Thus, SWFs will run slower in Browse as opposed to in Opera where content is being rendered at their native microscopic resolution. You can test this out yourself by by zooming in and out .swf content. I guess most people don't know this kind of Flash performance impact nowadays since everyone's running GHz+ computers. *** I'll do more benchmarks once I get Teapot's Intrepid Ibex build up and running (I think the XO doesn't like my SD card), and then do some Gnash testing once I get back the other dev XO I lent to the CS Dept at Ateneo de Manila University. Regards, -Naz -- Carlos Nazareno http://www.object404.com -- interactive media specialist zen graffiti studios http://www.zengraffiti.com -- Philippine Flash ActionScripters http://www.phlashers.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, 6 Jan 2009, Benjamin M. Schwartz wrote: > Carlos Nazareno wrote: > >> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool > > Currently, we are assuming that the issue will be RAM consumption, not > CPU. I personally have no reason to expect either system to behave > differently in terms of background CPU overhead or cost of common operations. it may just be the builds I've used, but in many cases the tools bundled with gnome seem to take more cpu to run than some of the other options (even things like displaying text on a xterm-like thing) David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, 6 Jan 2009, Bert Freudenberg wrote: > On 06.01.2009, at 22:34, Benjamin M. Schwartz wrote: > >> Carlos Nazareno wrote: >> >>> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool >> >> Currently, we are assuming that the issue will be RAM consumption, not >> CPU. I personally have no reason to expect either system to behave >> differently in terms of background CPU overhead or cost of common >> operations. > > > At 25c3 I bumped into a guy from LXDE. It's said to be a lot lighter > on resources than even XFCE. Unfortunately I did not stay long enough > to see it run on the XO, but maybe someone else did already? there is a debxo build with LXDE unfortunantly that build didn't include (or at least didn't startup) network manager, so I haven't played with it much. David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, 6 Jan 2009, Chris Ball wrote: > > Now, the question I have is why we would chose GNOME over XFCE. > > I think there are significant differences in system resource > > consumption. > > Ed, maybe you can help here -- since this has been going back and forth > for a while, could you help us come to/make a decision about whether to > target GNOME or XFCE for the 9.1 desktop feature? Thanks. I would ask the question, "what is it about gnome that makes it so desirable?" ignore the fact that it's the default desktop for several distros, on the XO what things can you do with Gnome that you can't do with other window managers? David Lang ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On 06.01.2009, at 22:34, Benjamin M. Schwartz wrote: > Carlos Nazareno wrote: > >> Guys, maybe this can help. I whipped up a flash CPU benchmarking tool > > Currently, we are assuming that the issue will be RAM consumption, not > CPU. I personally have no reason to expect either system to behave > differently in terms of background CPU overhead or cost of common > operations. At 25c3 I bumped into a guy from LXDE. It's said to be a lot lighter on resources than even XFCE. Unfortunately I did not stay long enough to see it run on the XO, but maybe someone else did already? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Greg, I don't mean to be nasty, but I do feel the need to be blunt: On Tue, Jan 06, 2009 at 04:28:36PM -0500, Greg Smith wrote: > Hi Michael, > > We are definitely behind where I would like to be at this stage. How far behind? > However, we'll only move the date when we must and we'll only do it to > improve quality What exactly did you think Deepak and Chris were discussing doing? Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Carlos Nazareno wrote: > Guys, maybe this can help. I whipped up a flash CPU benchmarking tool Currently, we are assuming that the issue will be RAM consumption, not CPU. I personally have no reason to expect either system to behave differently in terms of background CPU overhead or cost of common operations. > In XO OS 8.2.0 + Sugar with no other activities running, I'm getting > 5.5-5.65fps on Browse Activity and around 8.5fps on Opera 9.63 > (non-sugar) If both browsers were using the same SWF plugin, then this is extremely remarkable, and merits investigation. --Ben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
I vote XFCE. Guys, maybe this can help. I whipped up a flash CPU benchmarking tool some time ago to measure the impact of switching from Actionscript 2.0 to 3.0. I called it TeddyMark and it has 16 instances of Teddy (a character we made for one of our games) running around the screen and an FPS meter on the upper left hand of the screen. I found out it's a pretty good scalable CPU benchmark (just increase Teddy count for faster computers), and could help solve this debate CPU-impact wise :) Let's just pick the same browser, then run TeddyMark on 'em under XFCE, then on Gnome (let's throw in XO Sugar into the mix too!), then see how many frames per second it runs under each window manager. The window manager where TeddyMark runs faster should be the more efficient one. What do you guys think? You can run TeddyMark at http://www.phlashers.com/lab/teddymark/index.html It's a Flash 8 .SWF (max of 120fps) written in Actionscript 2.0 so it should run under both Gnash and SWFDec, and I'll be releasing the sourcecode under GPL as a Phlashers project soon. I'd be really interested if you guys posted your FPS scores in here (let it run for a couple of minutes for the FPS to stabilize to get its true FPS). In XO OS 8.2.0 + Sugar with no other activities running, I'm getting 5.5-5.65fps on Browse Activity and around 8.5fps on Opera 9.63 (non-sugar) Cheers! -Naz -- Carlos Nazareno http://www.object404.com -- interactive media specialist zen graffiti studios http://www.zengraffiti.com -- Philippine Flash ActionScripters http://www.phlashers.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Michael, We are definitely behind where I would like to be at this stage. However, we'll only move the date when we must and we'll only do it to improve quality or possibly to include a customer critical feature. We wont move the date to allow in major new features (e.g. new file system) so there's no room to add things assuming we will slip. Lastly, if we have to move the date, I only want to do it once. That means we only pick a new date when we know we can hit it. I heard your concerns in the last two 9.1 meetings but so far I don't have the evidence either way to make any changes. In short, the plan is the plan until it changes. So far, no change. Thanks, Greg S Michael Stone wrote: > On Tue, Jan 06, 2009 at 12:19:52PM -0800, Deepak Saxena wrote: >> On Jan 06 2009, at 14:42, Chris Ball was caught saying: >>> Hi, >>> >>>> I think I missed the previous conversation, re: estimate , but I'm >>>> thinking that swap will have significant impact on the lifetime of >>>> the flash chip. With only 256MiB of RAM, we are bound to swap a >>>> lot. I'd feel more comfortable if we did flash-wide wear leveling >>>> using UBI and created a swap partition on to pof that. >>> >>> That's fine with me too. Are we still planning on moving to UBI for >>> 9.1? If not, maybe we can work out how to get swap files working on >>> JFFS2 (where they would be wear-leveled)? >> >> At this point, with < 2 months to desired release date, > > Deepak, > > I don't think I know anyone who can convincingly argue that the March > date is realistic, based on current rates of change and the remaining > distance to the objective. I asked in the last (maybe even the last > two?) status meetings to re-evaluate that date but was blown off. Make > of that what you will. > > Michael > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 12:19:52PM -0800, Deepak Saxena wrote: >On Jan 06 2009, at 14:42, Chris Ball was caught saying: >> Hi, >> >>> I think I missed the previous conversation, re: estimate , but I'm >>> thinking that swap will have significant impact on the lifetime of >>> the flash chip. With only 256MiB of RAM, we are bound to swap a >>> lot. I'd feel more comfortable if we did flash-wide wear leveling >>> using UBI and created a swap partition on to pof that. >> >> That's fine with me too. Are we still planning on moving to UBI for >> 9.1? If not, maybe we can work out how to get swap files working on >> JFFS2 (where they would be wear-leveled)? > >At this point, with < 2 months to desired release date, Deepak, I don't think I know anyone who can convincingly argue that the March date is realistic, based on current rates of change and the remaining distance to the objective. I asked in the last (maybe even the last two?) status meetings to re-evaluate that date but was blown off. Make of that what you will. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Jan 06 2009, at 14:42, Chris Ball was caught saying: > Hi, > >> I think I missed the previous conversation, re: estimate , but I'm >> thinking that swap will have significant impact on the lifetime of >> the flash chip. With only 256MiB of RAM, we are bound to swap a >> lot. I'd feel more comfortable if we did flash-wide wear leveling >> using UBI and created a swap partition on to pof that. > > That's fine with me too. Are we still planning on moving to UBI for > 9.1? If not, maybe we can work out how to get swap files working on > JFFS2 (where they would be wear-leveled)? At this point, with < 2 months to desired release date, I do not support changing the filesystem. If we think a new filesystem is a priority (and not everyone does from other conversations I've had), we can intergrate it into joyride as soon as 9.1 is out the door so we have plenty of time to do formal testing and get end-user feedback. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Another plug for Teapot's Intrepid Ibex install if you want an easy way to
try the Ubuntu XFCE out on an SD card. I think it is quite beautiful.
http://www.olpcnews.com/forum/index.php?topic=4053.0
On Tue, Jan 6, 2009 at 12:04 PM, Erik Garrison wrote:
> On Tue, Jan 06, 2009 at 02:23:24PM -0500, Chris Ball wrote:
> > Hi,
> >
> >> Now, the question I have is why we would chose GNOME over XFCE. I
> >> think there are significant differences in system resource
> >> consumption.
> >
> > We had a long thread about whether to use GNOME or XFCE on devel@ last
> > month. I suggested XFCE, and was persuaded that the disk image size
> > of DebXO+GNOME is not significantly different than DebXO+XFCE,
>
> Yes, the NAND usage is comparable. You end up using very similar
> libraries. In my tests even fluxbox-based builds required at minimum
> 2/3 of the NAND space of the GNOME builds.
>
> In my experience the benefit is visible only at runtime.
>
> > ... and that both run fine without swap, suggesting that we might be
> > able to pull off GNOME on Fedora. If we find it unbearable, I'm fine
> > with using XFCE instead, but my impression was that GNOME is
> > preferred.
>
> I doubt we will find it unbearable. And I somewhat doubt that even if
> we do we will elect to switch after we invest development effort into
> it. So we should be very careful going into this to choose the most
> suitable option, before we are locked into one system or the other.
>
> I think it is telling that XFCE is designed expressly for limited
> systems such as ours, whereas GNOME has a more general applicability and
> is less optimized for our target. The effort shows.
>
> In terms of features, I have not experienced any significant difference
> in my use of the two systems on the XO, except perhaps that the
> appearance of GNOME is less configurable by the user in its default
> setup. Some may say this is a good thing as it decreases the potential
> problems that can arise, but to me it seems a positive feature to make
> the environment more enjoyable by young people.
>
> ... But frankly I don't care much about window manager features so long
> as a lack of them doesn't get in people's way. I want applications. If
> running one system means a quarter more available memory available to
> user-chosen applications, then we have made a big win.
>
> OK. Enough rambling... My opinions await qualification by tests.
>
> > (For the record, I'm not against investigating adding some swap for 9.1
> > now that we have NAND partitioning available. We'd have to be more sure
> > of our estimate that it won't significantly shorten the lifespan of the
> > flash chip, though. What do people think?)
>
> IMO: The NAND is not sacred. It is there to be used. If the chip fails
> the repair is as simple as installing an SD card; and as time goes on
> they rapidly decrease in price. That all said, it is not my
> understanding that the chip will fail catastrophically. It will just
> wear out, and its storage capacity will decrease. Like the breaks on a
> bike its use necessitates that it be burnt up very slowly.
>
> (don't forget compcache ...)
>
> >> Even though XFCE is not a Fedora-supported desktop environment, it
> >> is readily supported in other distributions. We could easily
> >> borrow the polish that XUbuntu has applied to its distribution and
> >> get a system equally usable as GNOME.
> >
> > Scott previously made a build stream ("faster") that contains both Sugar
> > and XFCE and a way to switch between them, so this integration work has
> > already been done.
>
> I wasn't specifically talking about integration, but polish. Ubuntu's
> XFCE seems to be in a better state than Fedora's or Debian's as they
> have integrated some upstream patches (most notably desktop icon
> customization stuff). They also use the GNOME menu system, which is
> very clear and well-organized. I don't know exactly the state of the
> differences but they are significant enough to be notable from the
> user's perspective.
>
> Erik
> ___
> Devel mailing list
> Devel@lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>
--
"Don't think for a minute that power concedes. We have to work like our
future depends on it." -- Barack Obama
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 02:23:24PM -0500, Chris Ball wrote:
> Hi,
>
>> Now, the question I have is why we would chose GNOME over XFCE. I
>> think there are significant differences in system resource
>> consumption.
>
> We had a long thread about whether to use GNOME or XFCE on devel@ last
> month. I suggested XFCE, and was persuaded that the disk image size
> of DebXO+GNOME is not significantly different than DebXO+XFCE,
Yes, the NAND usage is comparable. You end up using very similar
libraries. In my tests even fluxbox-based builds required at minimum
2/3 of the NAND space of the GNOME builds.
In my experience the benefit is visible only at runtime.
> ... and that both run fine without swap, suggesting that we might be
> able to pull off GNOME on Fedora. If we find it unbearable, I'm fine
> with using XFCE instead, but my impression was that GNOME is
> preferred.
I doubt we will find it unbearable. And I somewhat doubt that even if
we do we will elect to switch after we invest development effort into
it. So we should be very careful going into this to choose the most
suitable option, before we are locked into one system or the other.
I think it is telling that XFCE is designed expressly for limited
systems such as ours, whereas GNOME has a more general applicability and
is less optimized for our target. The effort shows.
In terms of features, I have not experienced any significant difference
in my use of the two systems on the XO, except perhaps that the
appearance of GNOME is less configurable by the user in its default
setup. Some may say this is a good thing as it decreases the potential
problems that can arise, but to me it seems a positive feature to make
the environment more enjoyable by young people.
... But frankly I don't care much about window manager features so long
as a lack of them doesn't get in people's way. I want applications. If
running one system means a quarter more available memory available to
user-chosen applications, then we have made a big win.
OK. Enough rambling... My opinions await qualification by tests.
> (For the record, I'm not against investigating adding some swap for 9.1
> now that we have NAND partitioning available. We'd have to be more sure
> of our estimate that it won't significantly shorten the lifespan of the
> flash chip, though. What do people think?)
IMO: The NAND is not sacred. It is there to be used. If the chip fails
the repair is as simple as installing an SD card; and as time goes on
they rapidly decrease in price. That all said, it is not my
understanding that the chip will fail catastrophically. It will just
wear out, and its storage capacity will decrease. Like the breaks on a
bike its use necessitates that it be burnt up very slowly.
(don't forget compcache ...)
>> Even though XFCE is not a Fedora-supported desktop environment, it
>> is readily supported in other distributions. We could easily
>> borrow the polish that XUbuntu has applied to its distribution and
>> get a system equally usable as GNOME.
>
> Scott previously made a build stream ("faster") that contains both Sugar
> and XFCE and a way to switch between them, so this integration work has
> already been done.
I wasn't specifically talking about integration, but polish. Ubuntu's
XFCE seems to be in a better state than Fedora's or Debian's as they
have integrated some upstream patches (most notably desktop icon
customization stuff). They also use the GNOME menu system, which is
very clear and well-organized. I don't know exactly the state of the
differences but they are significant enough to be notable from the
user's perspective.
Erik
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
chris wrote: > Hi, > >> what happens when you push the power button? > >> i assume the laptop will suspend due to ohmd, but i think g-p-m is >> doing the same dbus listen, no? > > We can just set "When power button is pressed: Do nothing" in the g-p-m > prefs. Yeah, ohmd is running/working. i was actually thinking in the other direction: if the ohmd action were disabled, i assume we'd get the g-p-m screen. is that screen tuneable? if g-p-m is possibly going in anyway, it might obviate the power button menu work. paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi, > what happens when you push the power button? > i assume the laptop will suspend due to ohmd, but i think g-p-m is > doing the same dbus listen, no? We can just set "When power button is pressed: Do nothing" in the g-p-m prefs. Yeah, ohmd is running/working. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi, > I think I missed the previous conversation, re: estimate , but I'm > thinking that swap will have significant impact on the lifetime of > the flash chip. With only 256MiB of RAM, we are bound to swap a > lot. I'd feel more comfortable if we did flash-wide wear leveling > using UBI and created a swap partition on to pof that. That's fine with me too. Are we still planning on moving to UBI for 9.1? If not, maybe we can work out how to get swap files working on JFFS2 (where they would be wear-leveled)? The previous conversation is: http://www.mail-archive.com/devel@lists.laptop.org/msg03766.html >_ __o (o> > ---\<, Give One Laptop, Get One Laptop //\ > - ( )/ ( ) http://www.amazon.com/xoV_/_ Not anymore. :) - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
chris wrote: > Hi Peter, > >> How did you go with this? Did you have any luck? I also realised >> that if you drop gnome-user-share you'll drop all the httpd >> requirements. > > Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, > both ship the same .mo files) and evince (against sugar-evince, both > ship the same evince backend shared libraries). Also, it turns out > that evince-dvi is responsible for bringing in texlive, via kpathsea. > > Here's the command I'm using now: > > -bash-3.2# yum -y install NetworkManager-gnome alacarte at-spi bug-buddy > control-center eog file-roller gcalctool gdm gdm-user-switch-applet > gedit gnome-applets gnome-audio gnome-backgrounds gnome-media > gnome-panel gnome-power-manager gnome-screensaver gnome-session what happens when you push the power button? i assume the laptop will suspend due to ohmd, but i think g-p-m is doing the same dbus listen, no? paul =- paul fox, p...@laptop.org give one laptop, get one laptop --- http://www.laptop.com/xo ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Jan 06 2009, at 14:23, Chris Ball was caught saying: > Hi, > >> Now, the question I have is why we would chose GNOME over XFCE. I >> think there are significant differences in system resource >> consumption. > > We had a long thread about whether to use GNOME or XFCE on devel@ last > month. I suggested XFCE, and was persuaded that the disk image size > of DebXO+GNOME is not significantly different than DebXO+XFCE, and that > both run fine without swap, suggesting that we might be able to pull off > GNOME on Fedora. If we find it unbearable, I'm fine with using XFCE > instead, but my impression was that GNOME is preferred. > > (For the record, I'm not against investigating adding some swap for 9.1 > now that we have NAND partitioning available. We'd have to be more sure > of our estimate that it won't significantly shorten the lifespan of the > flash chip, though. What do people think?) I think I missed the previous conversation, re: estimate , but I'm thinking that swap will have significant impact on the lifetime of the flash chip. With only 256MiB of RAM, we are bound to swap a lot. I'd feel more comfortable if we did flash-wide wear leveling using UBI and created a swap partition on to pof that. ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o> ---\<, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi, > Now, the question I have is why we would chose GNOME over XFCE. > I think there are significant differences in system resource > consumption. Ed, maybe you can help here -- since this has been going back and forth for a while, could you help us come to/make a decision about whether to target GNOME or XFCE for the 9.1 desktop feature? Thanks. - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi,
> Now, the question I have is why we would chose GNOME over XFCE. I
> think there are significant differences in system resource
> consumption.
We had a long thread about whether to use GNOME or XFCE on devel@ last
month. I suggested XFCE, and was persuaded that the disk image size
of DebXO+GNOME is not significantly different than DebXO+XFCE, and that
both run fine without swap, suggesting that we might be able to pull off
GNOME on Fedora. If we find it unbearable, I'm fine with using XFCE
instead, but my impression was that GNOME is preferred.
(For the record, I'm not against investigating adding some swap for 9.1
now that we have NAND partitioning available. We'd have to be more sure
of our estimate that it won't significantly shorten the lifespan of the
flash chip, though. What do people think?)
> Even though XFCE is not a Fedora-supported desktop environment, it
> is readily supported in other distributions. We could easily
> borrow the polish that XUbuntu has applied to its distribution and
> get a system equally usable as GNOME.
Scott previously made a build stream ("faster") that contains both Sugar
and XFCE and a way to switch between them, so this integration work has
already been done.
- Chris.
--
Chris Ball
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, 6 Jan 2009, Erik Garrison wrote: > On Tue, Jan 06, 2009 at 01:31:12PM -0500, Chris Ball wrote: >> Hi Peter, >> >> > How did you go with this? Did you have any luck? I also realised >> > that if you drop gnome-user-share you'll drop all the httpd >> > requirements. >> >> Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, >> both ship the same .mo files) and evince (against sugar-evince, both >> ship the same evince backend shared libraries). Also, it turns out >> that evince-dvi is responsible for bringing in texlive, via kpathsea. >> >> Here's the command I'm using now: >> >> -bash-3.2# yum -y install NetworkManager-gnome alacarte at-spi bug-buddy >> control-center eog file-roller gcalctool gdm gdm-user-switch-applet >> gedit gnome-applets gnome-audio gnome-backgrounds gnome-media >> gnome-panel gnome-power-manager gnome-screensaver gnome-session >> gnome-system-monitor gnome-terminal gnome-user-docs gnome-utils >> gok gthumb gucharmap gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-smb >> libcanberra-gtk2 metacity mousetweaks nautilus orca >> pulseaudio-esound-compat pulseaudio-module-gconf pulseaudio-module-x11 >> scim-bridge-gtk xdg-user-dirs-gtk yelp zenity >> >> Total size: 152 M >> >> After that completes, you can put "exec gnome-session" in ~/.xsession >> and restart X to land in a very normal looking F10 GNOME desktop. >> (I haven't tried to do much with it yet. Sound works, at least.) >> >> Thanks! >> >> - Chris. > > Sweet. > > Now, the question I have is why we would chose GNOME over XFCE. I think > there are significant differences in system resource consumption. A fine question indeed. > I ask because the impression I had from informal tests was that a system > booting into GNOME was consuming about 3x as much RAM on boot (read via > ps_mem.py). My impression was that the benefit was not eaten up the > moment the I started running GTK applications; it seemed that under XFCE > I could open a fair number more Firefox tabs without running into lockup > than under GNOME. I know these aren't great metrics so I'll run some > more rigorous tests after we have two systems side-by-side for > comparison. > > Even though XFCE is not a Fedora-supported desktop environment... Note that this does *not* mean that Xfce is not available in Fedora. There are Xfce spins built for Fedora that you can download and run right now, and I'm sure they're comparable, and Sebastian Dziallas is working on making a more "official" spin right now. It's all a question of what "official" means, and that changes in direct proportion to number of users. > ...it is readily supported in other distributions. We could easily > borrow the polish that XUbuntu has applied to its distribution and get a > system equally usable as GNOME. --g -- Got an OLPC that you're not using? Loan it to a needy developer! [[ http://wiki.laptop.org/go/XO_Exchange_Registry ]] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 06, 2009 at 01:31:12PM -0500, Chris Ball wrote: > Hi Peter, > >> How did you go with this? Did you have any luck? I also realised >> that if you drop gnome-user-share you'll drop all the httpd >> requirements. > > Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, > both ship the same .mo files) and evince (against sugar-evince, both > ship the same evince backend shared libraries). Also, it turns out > that evince-dvi is responsible for bringing in texlive, via kpathsea. > > Here's the command I'm using now: > > -bash-3.2# yum -y install NetworkManager-gnome alacarte at-spi bug-buddy > control-center eog file-roller gcalctool gdm gdm-user-switch-applet > gedit gnome-applets gnome-audio gnome-backgrounds gnome-media > gnome-panel gnome-power-manager gnome-screensaver gnome-session > gnome-system-monitor gnome-terminal gnome-user-docs gnome-utils > gok gthumb gucharmap gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-smb > libcanberra-gtk2 metacity mousetweaks nautilus orca > pulseaudio-esound-compat pulseaudio-module-gconf pulseaudio-module-x11 > scim-bridge-gtk xdg-user-dirs-gtk yelp zenity > > Total size: 152 M > > After that completes, you can put "exec gnome-session" in ~/.xsession > and restart X to land in a very normal looking F10 GNOME desktop. > (I haven't tried to do much with it yet. Sound works, at least.) > > Thanks! > > - Chris. Sweet. Now, the question I have is why we would chose GNOME over XFCE. I think there are significant differences in system resource consumption. I ask because the impression I had from informal tests was that a system booting into GNOME was consuming about 3x as much RAM on boot (read via ps_mem.py). My impression was that the benefit was not eaten up the moment the I started running GTK applications; it seemed that under XFCE I could open a fair number more Firefox tabs without running into lockup than under GNOME. I know these aren't great metrics so I'll run some more rigorous tests after we have two systems side-by-side for comparison. Even though XFCE is not a Fedora-supported desktop environment, it is readily supported in other distributions. We could easily borrow the polish that XUbuntu has applied to its distribution and get a system equally usable as GNOME. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Peter, > How did you go with this? Did you have any luck? I also realised > that if you drop gnome-user-share you'll drop all the httpd > requirements. Yep, it worked! I had RPM conflicts in GConf2 (against GConf2-dbus, both ship the same .mo files) and evince (against sugar-evince, both ship the same evince backend shared libraries). Also, it turns out that evince-dvi is responsible for bringing in texlive, via kpathsea. Here's the command I'm using now: -bash-3.2# yum -y install NetworkManager-gnome alacarte at-spi bug-buddy control-center eog file-roller gcalctool gdm gdm-user-switch-applet gedit gnome-applets gnome-audio gnome-backgrounds gnome-media gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-system-monitor gnome-terminal gnome-user-docs gnome-utils gok gthumb gucharmap gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-smb libcanberra-gtk2 metacity mousetweaks nautilus orca pulseaudio-esound-compat pulseaudio-module-gconf pulseaudio-module-x11 scim-bridge-gtk xdg-user-dirs-gtk yelp zenity Total size: 152 M After that completes, you can put "exec gnome-session" in ~/.xsession and restart X to land in a very normal looking F10 GNOME desktop. (I haven't tried to do much with it yet. Sound works, at least.) Thanks! - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
On Tue, Jan 6, 2009 at 07:50, Peter Robinson wrote: > >* Does not need to make it easy to share files between Fedora and Sugar. > - assuming its all running from the same base OS and just switching > GUIs this should be OK except for stuff stored in the journal > possibly. If its stored in the journal would it be possible to write a > gio interface for the journal ? I'm very interested on this, as it would give us also for free a FUSE interface. Why I haven't pursued it yet is because the API for developing new gio backends is still private and our new backend would then need to live inside the gvfs gnome module or as a patch in every distro. Aside from having to periodically adapt to any API changes. See http://mail.gnome.org/archives/gvfs-list/2008-May/msg4.html That said, such a backend would be very simple, for the journal in Sugar 0.84. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Chris, >> > I would remove the old fc9 build from the olpc_development repo (or >> > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed >> > up). Surely it should be pulling cyrus-sasl from the Fedora repos >> > anyway? >> >> I've just pushed a patch to pilgrim's joyride branch to switch the >> baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo >> from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to >> http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ >> >> (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride >> should have been switched to write out the olpc4 baseurl when we >> created the new repo.) >> >> And, after the change, we don't have depsolving problems any more! >> Here's the list of packages to be downloaded -- the next question is >> going to be how to avoid many of these dependencies. Perhaps instead >> of trying the groupinstall, we should be hand-picking a smaller base >> of GNOME packages from this list? > > Well its the list up to the "Installing for dependencies" that is > explicitly requested, all the below is pulled in for deps. I'm not > sure how pilgrim builds the list but I think if it uses kickstart like > the other fedora build systems do you should be able to do a specific > "-packagename" and its removed from the list. > > A quick look through the list. if you remove tomboy you should > loose all the mono deps, bluez-gnome and gnome-bluetooth should drop > out all the bluetooth related stuff, nautilus-cd-burner and > nautilus-sendto should drop various other non required deps (various > CD burning stuff and pidgin etc), compiz* won't be required as I doubt > the graphics adapter does cool whirly effects, How did you go with this? Did you have any luck? I also realised that if you drop gnome-user-share you'll drop all the httpd requirements. I was going through the list of stuff at http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO and have a few comments on the points made. Some might be obvious, some not so much. * Must support camera, microphone, speakers, wifi 802.11 A/B/G, touchpad, Keyboard, USB interfaces, and SD interface. - being based on Fedora all of the above comes as standard. I presume with the wifi bit you mean support of the onboard wifi interface. * Does not need to make it easy to share files between Fedora and Sugar. - assuming its all running from the same base OS and just switching GUIs this should be OK except for stuff stored in the journal possibly. If its stored in the journal would it be possible to write a gio interface for the journal ? * Must fully support Yum. - This would come as standard. * Must come with applications on default install (will be chosen and will be a very minimal set). - this would be dependant on the choice of apps. we already have the base of quite a few installed from the gnome side of things (totem, abiword etc) in some cases its a matter of just adding the standard 'GUI' along with the sugar one. * Must boot as fast as Sugar. - in most cases its the other parts of the OS that take the time. Not sure how you'll switch between the two but in the case of a gnome gui it would be mostly the 'login time' difference. * Must support upgrading the Fedora version and the Sugar version in 9.2.0 and future releases. - Like yum support this would be automatic :-) * Must not keep two copies of any files or libraries. Any file which is exactly the same on both Sugar and Fedora images should be used by both and should not take twice the space. - The issue here would be forked libraries. The ones that come to mind specifically are abiword, totem, totem-pl-parser, telepathy and GConf2-dbus. In some cases where the gnome desktop requires evolution-data-server in other areas anyway there is suddenly very little need to keep the forked packages around. A gnome based desktop make some sense in the discussions as we already package so much of it already Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Chris, > > I would remove the old fc9 build from the olpc_development repo (or > > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed > > up). Surely it should be pulling cyrus-sasl from the Fedora repos > > anyway? > > I've just pushed a patch to pilgrim's joyride branch to switch the > baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo > from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to > http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ > > (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride > should have been switched to write out the olpc4 baseurl when we > created the new repo.) > > And, after the change, we don't have depsolving problems any more! > Here's the list of packages to be downloaded -- the next question is > going to be how to avoid many of these dependencies. Perhaps instead > of trying the groupinstall, we should be hand-picking a smaller base > of GNOME packages from this list? Well its the list up to the "Installing for dependencies" that is explicitly requested, all the below is pulled in for deps. I'm not sure how pilgrim builds the list but I think if it uses kickstart like the other fedora build systems do you should be able to do a specific "-packagename" and its removed from the list. A quick look through the list. if you remove tomboy you should loose all the mono deps, bluez-gnome and gnome-bluetooth should drop out all the bluetooth related stuff, nautilus-cd-burner and nautilus-sendto should drop various other non required deps (various CD burning stuff and pidgin etc), compiz* won't be required as I doubt the graphics adapter does cool whirly effects, That should be a start to reduce the dep list quite significantly. >From there if there's extra deps we need to drop from specific packages as its for a gnome desktop it would be best to file a bug and link it against the tracker bug for OLPC packages in fedora for easy tracking rather than forking. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Peter, > I would remove the old fc9 build from the olpc_development repo (or > even have one for 8.2.0 and one for 9.1.0 so they don't get mixed > up). Surely it should be pulling cyrus-sasl from the Fedora repos > anyway? I've just pushed a patch to pilgrim's joyride branch to switch the baseurl that gets written out in /etc/yum.repos.d/olpc-development.repo from http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ to http://kojipkgs.fedoraproject.org/static-repos/dist-olpc4-build-current/i386/ (olpc3 is our 8.2/F9 repo, and olpc4 is the 9.1/F10 repo, so Joyride should have been switched to write out the olpc4 baseurl when we created the new repo.) And, after the change, we don't have depsolving problems any more! Here's the list of packages to be downloaded -- the next question is going to be how to avoid many of these dependencies. Perhaps instead of trying the groupinstall, we should be hand-picking a smaller base of GNOME packages from this list? Dependencies Resolved === Package Arch Version RepositorySize === Installing: NetworkManager-gnomei386 1:0.7.0-0.12.svn4326.fc10 olpc_development 355 k alacartenoarch 0.11.6-4.fc10olpc_development 126 k at-spi i386 1.24.0-5.fc10olpc_development 241 k bluez-gnome i386 1.8-8.fc10 olpc_development 240 k bug-buddy i386 1:2.24.2-1.fc10 olpc_development 725 k compiz-gnomei386 0.7.8-4.fc10 olpc_development 156 k control-center i386 1:2.24.0.1-9.fc10olpc_development 2.4 M dasher i386 4.9.0-2.fc10 olpc_development 6.7 M eog i386 2.24.2-1.fc10olpc_development 1.9 M evince i386 2.24.2-1.fc10olpc_development 1.2 M evince-djvu i386 2.24.2-1.fc10olpc_development 26 k evince-dvi i386 2.24.2-1.fc10olpc_development 77 k file-roller i386 2.24.2-1.fc10olpc_development 1.3 M gcalctool i386 5.24.2-1.fc10olpc_development 1.6 M gdm i386 1:2.24.0-12.fc10 olpc_development 1.1 M gdm-user-switch-applet i386 1:2.24.0-12.fc10 olpc_development 90 k gedit i386 1:2.24.2-1.fc10 olpc_development 4.2 M gnome-applets i386 1:2.24.2-2.fc10 olpc_development 6.3 M gnome-audio noarch 2.22.2-2.fc10olpc_development 1.7 M gnome-backgrounds noarch 2.24.0-2.fc10olpc_development 9.3 M gnome-bluetooth i386 0.11.0-5.fc10olpc_development 243 k gnome-media i386 2.24.0.1-2.fc10 olpc_development 1.9 M gnome-panel i386 2.24.2-1.fc10olpc_development 2.9 M gnome-pilot i386 2.0.16-2.fc9 olpc_development 644 k gnome-power-manager i386 2.24.2-2.fc10olpc_development 2.6 M gnome-screensaver i386 2.24.1-1.fc10olpc_development 1.8 M gnome-session i386 2.24.2-1.fc10olpc_development 596 k gnome-system-monitori386 2.24.1-1.fc10olpc_development 1.9 M gnome-terminal i386 2.24.2-2.fc10olpc_development 1.6 M gnome-user-docs noarch 2.22.1-1.fc9 olpc_development 16 M gnome-user-sharei386 0.40-3.fc10 olpc_development 92 k gnome-utils i386 1:2.24.1-1.fc10 olpc_development 5.9 M gok i386 2.24.0-2.fc10olpc_development 1.4 M gthumb i386 2.10.10-3.fc10 olpc_development 2.6 M gucharmap i386 2.24.2-1.fc10olpc_development 2.4 M gvfs-archivei386 1.0.3-4.fc10 olpc_development 56 k gvfs-fuse i386 1.0.3-4.fc10 olpc_development 20 k gvfs-gphoto2i386 1.0.3-4.fc10 olpc_development 85 k gvfs-smbi386 1.0.3-4.fc10 olpc_development 111 k libcanberra-gtk2i386 0.10-2.fc10 olpc_development 20 k metacityi386 2.24.0-2.fc10olpc_development 1.5 M mousetweaks i386 2.24.2-1.fc10olpc_development 613 k nautilusi386 2.24.2-1.fc10olpc_development 4.4 M nautilus-cd-burner i386 2.24.0-1.fc10olpc_development 521 k nautilus-sendto i386 1.1.0-1.fc10 olpc_development 122 k orcai386 2.24.2-1.fc10olpc_developm
Re: Fedora Desktop on XO
Hi Chris, No probs on the reply. > Hi Peter, thanks for the reply, > > > Is this on 8.2.0 or joyride? It looks like 8.2 due to the > > gnome-python version being olpc3. > > It's running a joyride F10 build, but looks like you're right about > olpc3. Here's the /etc/yum.repos.d/olpc-development.repo shipped in > Joyride: > > [olpc_development] > name=OLPC development repository, based on koji tag dist-olpc3-devel. > baseurl=http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ > enabled=1 > gpgcheck=0 > exclude=kernel > > [olpc-joyride] > name=OLPC 'Joyride' repository > baseurl=http://xs-dev.laptop.org/~cscott/repos/joyride/ > enabled=1 > gpgcheck=0 > > > I suspect some of the errors are due to the custom packages, or > > possibly due to a repo not being available. You can get some weird > > errors if there's two package provides split across repos > > (something like a base gnome-python provided by the olpc3 repo > > where as the gnome-python-blah which was stripped out of the olpc3 > > build is then provided by the Fedora 9 repo. Overall it looks like > > an issue with cyrus-sasl. What does a "yum list cyrus-sasl*" show? > > Excluding Packages from Fedora 10 - i386 > Finished > Excluding Packages from OLPC development repository, based on koji tag > dist-olpc3-devel. > Finished > Excluding Packages from Fedora 10 - i386 - Updates > Finished > Installed Packages > cyrus-sasl-lib.i386 2.1.22-19.fc10 installed > Available Packages > cyrus-sasl.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-debuginfo.i3862.1.22-15.fc9 olpc_development > cyrus-sasl-devel.i3862.1.22-15.fc9 olpc_development > cyrus-sasl-gssapi.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-krb4.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-ldap.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-md5.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-ntlm.i386 2.1.22-15.fc9 olpc_development > cyrus-sasl-plain.i3862.1.22-15.fc9 olpc_development > cyrus-sasl-sql.i386 2.1.22-15.fc9 olpc_development I would remove the old fc9 build from the olpc_development repo (or even have one for 8.2.0 and one for 9.1.0 so they don't get mixed up). Surely it should be pulling cyrus-sasl from the Fedora repos anyway? Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Peter, thanks for the reply, > Is this on 8.2.0 or joyride? It looks like 8.2 due to the > gnome-python version being olpc3. It's running a joyride F10 build, but looks like you're right about olpc3. Here's the /etc/yum.repos.d/olpc-development.repo shipped in Joyride: [olpc_development] name=OLPC development repository, based on koji tag dist-olpc3-devel. baseurl=http://xs-dev.laptop.org/~cscott/repos/dist-olpc3-devel/ enabled=1 gpgcheck=0 exclude=kernel [olpc-joyride] name=OLPC 'Joyride' repository baseurl=http://xs-dev.laptop.org/~cscott/repos/joyride/ enabled=1 gpgcheck=0 > I suspect some of the errors are due to the custom packages, or > possibly due to a repo not being available. You can get some weird > errors if there's two package provides split across repos > (something like a base gnome-python provided by the olpc3 repo > where as the gnome-python-blah which was stripped out of the olpc3 > build is then provided by the Fedora 9 repo. Overall it looks like > an issue with cyrus-sasl. What does a "yum list cyrus-sasl*" show? Excluding Packages from Fedora 10 - i386 Finished Excluding Packages from OLPC development repository, based on koji tag dist-olpc3-devel. Finished Excluding Packages from Fedora 10 - i386 - Updates Finished Installed Packages cyrus-sasl-lib.i386 2.1.22-19.fc10 installed Available Packages cyrus-sasl.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-debuginfo.i3862.1.22-15.fc9 olpc_development cyrus-sasl-devel.i3862.1.22-15.fc9 olpc_development cyrus-sasl-gssapi.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-krb4.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-ldap.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-md5.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-ntlm.i386 2.1.22-15.fc9 olpc_development cyrus-sasl-plain.i3862.1.22-15.fc9 olpc_development cyrus-sasl-sql.i386 2.1.22-15.fc9 olpc_development Thanks! - Chris. -- Chris Ball ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
> Hi Greg, > > Sorry for delayed response, I've had little internet connectivity so > have only had limited mail access and mostly through a windows box :( > >> I'm still looking for help resolving the dependencies Chris found when he >> tried to install Gnome. >> >> The issue and thread are documented in the specifications section here: >> http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO >> >> What do we do next when we get a list of "dependency errors"? > > Is this on 8.2.0 or joyride? It looks like 8.2 due to the gnome-python > version being olpc3. I suspect some of the errors are due to the > custom packages, or possibly due to a repo not being available. You > can get some weird errors if there's two package provides split across > repos (something like a base gnome-python provided by the olpc3 repo > where as the gnome-python-blah which was stripped out of the olpc3 > build is then provided by the Fedora 9 repo. Overall it looks like an > issue with cyrus-sasl. What does a "yum list cyrus-sasl*" show? The other thing to check for is that there isn't multiple versions installed (rpm -qa | grep cyrus), I've seen this sometimes with things like glibc and openssl where there's both an i386 and i686 version. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fedora Desktop on XO
Hi Greg, Sorry for delayed response, I've had little internet connectivity so have only had limited mail access and mostly through a windows box :( > I'm still looking for help resolving the dependencies Chris found when he > tried to install Gnome. > > The issue and thread are documented in the specifications section here: > http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO > > What do we do next when we get a list of "dependency errors"? Is this on 8.2.0 or joyride? It looks like 8.2 due to the gnome-python version being olpc3. I suspect some of the errors are due to the custom packages, or possibly due to a repo not being available. You can get some weird errors if there's two package provides split across repos (something like a base gnome-python provided by the olpc3 repo where as the gnome-python-blah which was stripped out of the olpc3 build is then provided by the Fedora 9 repo. Overall it looks like an issue with cyrus-sasl. What does a "yum list cyrus-sasl*" show? Regards, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fedora Desktop on XO
Hi Peter et al, I'm still looking for help resolving the dependencies Chris found when he tried to install Gnome. The issue and thread are documented in the specifications section here: http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO What do we do next when we get a list of "dependency errors"? Paul, I believe that you got XFCE running. Can you add the description of what you did to make that happen to this page? http://wiki.laptop.org/go/Feature_roadmap/Run_Fedora_applications_on_XO I may have a little time tomorrow to try it out if its not too complicated. Thanks, Greg S ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
