Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Sat, Apr 17, 2010 at 4:45 AM, Peter Robinson wrote:
> And there is a perfect reason for a stable distro such as RHEL or CentOS :-)
:-)
Two quick things I want to inject into this conversation.
- Timing affects this decision. We're not in the abstract -- this is
_now_. If RHEL6/CentOS6 is reasonably close to shipping on the target
release date, I'd pick RHEL6 instead of F13/F14. Maybe a year or two
later the base OS is F16. This is entirely pragmatic.
- In my (fairly long) experience "customising upstreams for
deployment", once your upstream has the basics you need, it's _a lot_
less work to backport specific things you need than to re-base,
re-test, re-stabilise all your work on top of a new release often.
Specially when your "test surface" is large. And ours is _huge_.
Yes, backporting things is a pain, but it's visible and localised. And
you know when you are "done". Re-testing is a huge workload, and we're
just not seeing it because very little of it is getting done. The test
teams we have are good -- we'd just need 10x of them! So many bugs
that come from library changes ("churn") are not being found, reported
or fixed; and this has very low visibility, and hard to measure
"completion".
Earlier (F7, F9), stable-ish upstreams didn't have what we needed, so
Fedora's bleeding edge approach was crucial. When RHEL6/CentOS comes
out, that game changes profoundly.
cheers,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Sat, Apr 17, 2010 at 2:52 AM, Bernie Innocenti wrote: > On Fri, 2010-04-16 at 23:31 +0100, Peter Robinson wrote: > > [...] > >> > I'm not against packaging Sugar for RHEL. I just think it would cost >> > more to support after the first year or two. >> >> Agreed. And in fact I said that exactly and hence my reference to the >> 18 month to 2.5 year point but the fact is by then you'll almost be to >> RHEL N+1 release so you role it over. > > Oh, now I get it. And I think I agree with you. > > >> The EL packaging makes it easy enough that its "if it compile and >> there is demand for it then you can do so because to push it out isn't >> had" if it stops compiling you send it out to the lists and either >> people care enough to fix the problem or else it stays on what ever >> the currently compiling version is. Sort of like the extended >> maintenance of the 0.84.x releases. > > Agreed here too (we're on the good way). > > >> Your making the problem like a Cross Road in a road. Its really not >> that. We are going to be following the upstream Fedora releases but I >> really don't think it will be hard to follow a RHEL release train >> either. In the F-7 to F-10 time frame the changes were massive. I know >> I had to assist in merging them upstream. But since then there's not >> been massive underlying changes that aren't manageable. The biggest I >> think are probably Tomeu's plans for the telepathy stuff and that is >> just to bring us back in line with the main line. > > I really hope you're wrong, but I'm afraid you're correct. We'd still > have to change so much before Sugar becomes as mature and usable as > Gnome is nowadays. > > Besides toemu's rewrite of the collaboration stack, there's Sascha's > rewrite of the datastore still in the works. Yes, but I suspect that's more an internal change to the underlying structure and design rather than something that is going to require the latest and greatest library version X that's not released yet. >> I think the next big disruptive change will be python3 and associated >> pygtk changes, and while I don't have a crystal ball I think we can >> either stick with the current and it will be supported or there will >> be ways to support the new stuff. > > I'm not looking forward for Python 3. Every other large Python project > has been procrastinating on this transition because there's not much to > gain and a lot to loose. Yes, but its starting to pick momentum now. The first 3.x release is out fixing up some of the issues. Fedora 13 will have a python3 package and the python hack fest hosted at OLPC's office to bring up the gnome python bindings in preparation for gnome 3 also had quite a focus on support for python3 too, > For us, switching to Python 3 would be unthinkably disruptive: half of > the activities would remain broken for years, unless we maintain a > Python 2 stack for backwards compatibility... /me shrugs And there is a perfect reason for a stable distro such as RHEL or CentOS :-) Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, 2010-04-16 at 23:31 +0100, Peter Robinson wrote: [...] > > I'm not against packaging Sugar for RHEL. I just think it would cost > > more to support after the first year or two. > > Agreed. And in fact I said that exactly and hence my reference to the > 18 month to 2.5 year point but the fact is by then you'll almost be to > RHEL N+1 release so you role it over. Oh, now I get it. And I think I agree with you. > The EL packaging makes it easy enough that its "if it compile and > there is demand for it then you can do so because to push it out isn't > had" if it stops compiling you send it out to the lists and either > people care enough to fix the problem or else it stays on what ever > the currently compiling version is. Sort of like the extended > maintenance of the 0.84.x releases. Agreed here too (we're on the good way). > Your making the problem like a Cross Road in a road. Its really not > that. We are going to be following the upstream Fedora releases but I > really don't think it will be hard to follow a RHEL release train > either. In the F-7 to F-10 time frame the changes were massive. I know > I had to assist in merging them upstream. But since then there's not > been massive underlying changes that aren't manageable. The biggest I > think are probably Tomeu's plans for the telepathy stuff and that is > just to bring us back in line with the main line. I really hope you're wrong, but I'm afraid you're correct. We'd still have to change so much before Sugar becomes as mature and usable as Gnome is nowadays. Besides toemu's rewrite of the collaboration stack, there's Sascha's rewrite of the datastore still in the works. > I think the next big disruptive change will be python3 and associated > pygtk changes, and while I don't have a crystal ball I think we can > either stick with the current and it will be supported or there will > be ways to support the new stuff. I'm not looking forward for Python 3. Every other large Python project has been procrastinating on this transition because there's not much to gain and a lot to loose. For us, switching to Python 3 would be unthinkably disruptive: half of the activities would remain broken for years, unless we maintain a Python 2 stack for backwards compatibility... /me shrugs -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
> Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on > which we depend for hulahop (and hence Browse). I had zero problems running Firefox 3.5 from the Terminal activity on my XOs. I am currently running Firefox 3.6.3 - again, zero problems - including being able to launch it from an icon within Home View. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, Apr 16, 2010 at 9:20 PM, Bernie Innocenti wrote: > On Tue, 2010-04-13 at 07:59 +0100, Peter Robinson wrote: >> > I agree on this, but it misses the point :-) >> >> Not exactly. > > That was just supposed to continue your point-point-point pun :) > > >> > * GSM connectivity requires up-to-date versions of udev and >> > modem-manager to support USB dongles commonly available in stores >> >> RH updates those sort of components regularly to ensure support. > > This isn't a trivial bugfix or a matter of a missing product ID. It's an > entire missing subsystem. I asked Harald Hoyer, the maintainer of udev, > if there was a way to back-port the mode switch functionality from F12 > to F11 and he told me "good luck with it". Yes, but usb_modeswitch works quite well. There's been a lot change since RHEL 5 was released about 3 years ago. I think RHEL-6 will be somewhat more easy in that regard because a lot of the building blocks that weren't in place 3 years ago are now. >> > * Playing multimedia content downloaded from the Internet requires >> > gstreamer with up-to-date codecs >> >> That is not due to up to date codecs but rather patent free codecs. >> Completely different issues. That is as valid with F-13 today as >> RHEL-5 > > RPM Fusion does indeed support RHEL5, but that's quite surprising. > > Enterprise distros have a tiny user base relative to the mainstream ones > and tend to be badly supported even by proprietary software vendors such > as Skype and Adobe. Hmm. Skype isn't what I would call an enterprise product. If you want enterprise VoIP you'd use enterprise. Adobe still support acroread etc on RHEL-4! >> > * activities such as Record tend to uncover obscure bugs in GStreamer >> >> Nothing stopping these being fixed in RHEL/CentOS. > > Nothing stops bugs from being fixed on Red Hat 7.2 either, as long as > you're willing to invest your own time to do it. Yes, but being supported on the enterprise product means its more likely to be fixed in their stream. It also gives you a more stable environment rather that something that is like running across jelly. >> > * Browse depends on xulrunner for security and compatiblity with web >> > standards. Surfing the web today with a version of Firefox from >> > 3 years ago would be unthinkable >> >> RHEL updates this regularly as well and actively moves to the current >> version. I believe RHEL-5 has firefox 3.5 > > Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on > which we depend for hulahop (and hence Browse). Yes, but we would have packages in the later versions of fedora that would support the later ABI of the newer versions of firefox that we would be able to compile against it so that isn't a major problem. One of the advantages of following both release trains. > If adding features incrementally without ever breaking the ABI was > feasible, the mainstream distros would do it as well. See point above. >> > * ...not to mention NetworkManager... >> >> Mention what about it? We don't use any of the latest NM features, its >> stable and the maintainer actively assists and accepts patches. > > Stable?!? See this thread (it's broken up across 3 months in the > pipermail archives): > > http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505 umm we're talking RHEL or a RHEL derived distro. That side will be stable. and the core components of NM are stable. The thread that you reference from the quick read I had was due to instability in the driver that was worked around in NetworkManager so that can only talk up not down NM support! > Besides this one, there were also other problems. I'd say NM was a major > headache for this development cycle. Really? I bet it was more the underlying driver issues that were more the case. Almost all of the issues I have wit NM ultimately are the drivers not NM at all. >> In fact alot of the differences in packages were merged back in by me >> in the F-10/F-11 timeframe. I'm well aware of those issues, I still >> track them closely. I just wish it was the same with the kernel :-) > > Sorry, I totally forgot about the awesome work you had done for > upstreaming OLPC changes into Fedora. :-) >> > 2) we switch to a real package system for activities with full support >> > for dependency checking and a build cluster for multiple targets. >> >> One word. PackageKit. Then its agnostic for all the distributions. > > +1 from me, but many Sugar developers wish to maintain the status quo. > > It's been discussed many times in the past. Unless the distributors take > the initiative to do the work, it looks like native packaging formats > aren't going to be supported by Sugar anytime soon. People are slowly coming around, and I'm slowly bribing people :-D >> You've obviously not dealt with them then on the RHEL side of things. >> I work for a company that had over 1200 RHEL systems. > > Are we talking about paid support or free support? I'm sure you ca
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Fri, 2010-04-16 at 14:00 -0700, Yioryos Asprobounitis wrote: > But at least you have 2 years. With F11 you have 0. I agree. Today we should be releasing a system based on F13, which would come with 12 months of "official" support and maybe 8-10 months of *real* attention of the upstream developers of the OS components we rely upon. > Is there any reason on whu you think that rebasing every > 12-18months will actually be less of a problem/cost? Because rebasing on a new OS is not as expensive as fixing all bugs on your own. Moreover, soon or later you'd have to rebase anyway. The more you wait, the harder it gets. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
--- On Fri, 4/16/10, Bernie Innocenti wrote: > From: Bernie Innocenti > Subject: Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 > build 119) > > I'm not against packaging Sugar for RHEL. I just think it > would cost > more to support after the first year or two. > But at least you have 2 years. With F11 you have 0. Is there any reason on whu you think that rebasing every 12-18months will actually be less of a problem/cost? > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Tue, 2010-04-13 at 07:59 +0100, Peter Robinson wrote: > > I agree on this, but it misses the point :-) > > Not exactly. That was just supposed to continue your point-point-point pun :) > > * GSM connectivity requires up-to-date versions of udev and > > modem-manager to support USB dongles commonly available in stores > > RH updates those sort of components regularly to ensure support. This isn't a trivial bugfix or a matter of a missing product ID. It's an entire missing subsystem. I asked Harald Hoyer, the maintainer of udev, if there was a way to back-port the mode switch functionality from F12 to F11 and he told me "good luck with it". > > * Playing multimedia content downloaded from the Internet requires > > gstreamer with up-to-date codecs > > That is not due to up to date codecs but rather patent free codecs. > Completely different issues. That is as valid with F-13 today as > RHEL-5 RPM Fusion does indeed support RHEL5, but that's quite surprising. Enterprise distros have a tiny user base relative to the mainstream ones and tend to be badly supported even by proprietary software vendors such as Skype and Adobe. > > * activities such as Record tend to uncover obscure bugs in GStreamer > > Nothing stopping these being fixed in RHEL/CentOS. Nothing stops bugs from being fixed on Red Hat 7.2 either, as long as you're willing to invest your own time to do it. > > * Browse depends on xulrunner for security and compatiblity with web > > standards. Surfing the web today with a version of Firefox from > > 3 years ago would be unthinkable > > RHEL updates this regularly as well and actively moves to the current > version. I believe RHEL-5 has firefox 3.5 Ha! Upgrading Firefox to version 3.5 would break the xulrunner ABI, on which we depend for hulahop (and hence Browse). If adding features incrementally without ever breaking the ABI was feasible, the mainstream distros would do it as well. > > * ...not to mention NetworkManager... > > Mention what about it? We don't use any of the latest NM features, its > stable and the maintainer actively assists and accepts patches. Stable?!? See this thread (it's broken up across 3 months in the pipermail archives): http://lists.laptop.org/pipermail/devel/2010-February/thread.html#27505 Besides this one, there were also other problems. I'd say NM was a major headache for this development cycle. > In fact alot of the differences in packages were merged back in by me > in the F-10/F-11 timeframe. I'm well aware of those issues, I still > track them closely. I just wish it was the same with the kernel :-) Sorry, I totally forgot about the awesome work you had done for upstreaming OLPC changes into Fedora. > > 2) we switch to a real package system for activities with full support > > for dependency checking and a build cluster for multiple targets. > > One word. PackageKit. Then its agnostic for all the distributions. +1 from me, but many Sugar developers wish to maintain the status quo. It's been discussed many times in the past. Unless the distributors take the initiative to do the work, it looks like native packaging formats aren't going to be supported by Sugar anytime soon. > You've obviously not dealt with them then on the RHEL side of things. > I work for a company that had over 1200 RHEL systems. Are we talking about paid support or free support? I'm sure you can get RH to fix any bug if you purchase 1200 RHEL licenses from them. > There are advantages to both approaches and I don't see that > supporting both is going to be an issue to do so at least in the short > term. I don't see that we need to rule out either option. I'm not against packaging Sugar for RHEL. I just think it would cost more to support after the first year or two. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Wed, Apr 14, 2010 at 1:27 AM, James Cameron wrote: > http://dev.laptop.org/ticket/9350 (xrandr screen rotation support) is > still being worked. We did try with software frame buffer rotation > enabled, but it did not perform well. > > -- > James Cameron > http://quozl.linux.org.au/ > Chris, James, thanks a lot for the quick replies, I knew I had missed something... Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
http://dev.laptop.org/ticket/9350 (xrandr screen rotation support) is still being worked. We did try with software frame buffer rotation enabled, but it did not perform well. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
Hi, > I updated my XO-1.5s to 119 yesterday and was surprised to see > that the screen rotation button still doesn't seem to > work. Looking through the mailing-lists I didn't find any > discussion about this topic which kinda surprised me. The openchrome driver hasn't previously had support for on-the-fly rotation switching, but Jon Nettleton's got a plan to add it soon. - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Fri, Apr 9, 2010 at 10:27 PM, Chris Ball wrote: > http://wiki.laptop.org/go/F11_for_1.5 > http://build.laptop.org/10.2.0/os119 > > Compressed image size: 678.36mb (+0.01mb since build 118) > > Description of changes in this build: > * kernel: allow negotiation of 5/10/15/30fps (#10106) > > With this change, Record should be able to record audio+video together, > although you'll still need to VT switch away and back if you get a black > Xv overlay as described in http://dev.laptop.org/ticket/10068. > > Package changes since build 118: > > -kernel-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > -kernel-firmware-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > I updated my XO-1.5s to 119 yesterday and was surprised to see that the screen rotation button still doesn't seem to work. Looking through the mailing-lists I didn't find any discussion about this topic which kinda surprised me. So am I the only one with this issue? Or was support for screen rotation dropped and I simply missed the discussion? Thanks, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Tue, Apr 13, 2010 at 1:11 PM, Daniel Drake wrote: > On 12 April 2010 19:13, Peter Robinson wrote: >> That's because of the exim. Do a 'yum install ssmtp' then a 'yum >> remove exim' and most of that problem goes away. the auto depsolving >> for '/usr/bin/sendmail' get exim by default because its the shortest >> name and comes first. exim depends on perl. ssmtp is a very small 50k >> dep that gives cronie what it wants. > > Indeed. The change seems fine so I adjusted the build configuration. > > Once runin is fixed, sugar-only builds will have dropped the dependency on > perl. I filed this bug [1] for the inkscape dep and I think that should fix the build for sugar+gnome builds as well. [1] https://bugzilla.redhat.com/show_bug.cgi?id=579390 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 12 April 2010 19:13, Peter Robinson wrote: > That's because of the exim. Do a 'yum install ssmtp' then a 'yum > remove exim' and most of that problem goes away. the auto depsolving > for '/usr/bin/sendmail' get exim by default because its the shortest > name and comes first. exim depends on perl. ssmtp is a very small 50k > dep that gives cronie what it wants. Indeed. The change seems fine so I adjusted the build configuration. Once runin is fixed, sugar-only builds will have dropped the dependency on perl. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Tue, Apr 13, 2010 at 2:31 AM, Bernie Innocenti wrote: > On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: >> Bernie, I'm not sure the point of this point at this point in time. To >> copy and paste part of the response I did to the other thread on >> fedora-olpc for others benefit. >> >> I personally don't see the point discussing it because from where I >> sit I believe it will be supported well in both and continue to be so. >> That way people have the choice. It might well get to a stage where >> the newer versions of sugar won't run in RHEL/CentOS due to whatever >> deps at which point we get to a situation where that release becomes >> like 0.84 is currently and is a long term support release. I don't see >> why its hard to support both because its not. The package maintenance >> is simple and is done easily by a couple of people. There will be >> Fedora and it will continue to be supported in Fedora for the >> developers and the like that want the bleeding edge and then there >> will be the EL branch for those that don't like so much blood. Its >> called choice. There's no reason to limit it. There's not much point >> discussing it at the moment as RHEL-6 isn't out yet, yes its in beta >> but its not out. > > I agree on this, but it misses the point :-) Not exactly. > I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it > is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal > tweaks. > > Most end-user support issues lay within base OS components rather than > the relatively small codebase of Sugar. Here are some real-world > examples from this development cycle: Agreed. > * GSM connectivity requires up-to-date versions of udev and > modem-manager to support USB dongles commonly available in stores RH updates those sort of components regularly to ensure support. > * Playing multimedia content downloaded from the Internet requires > gstreamer with up-to-date codecs That is not due to up to date codecs but rather patent free codecs. Completely different issues. That is as valid with F-13 today as RHEL-5 > * activities such as Record tend to uncover obscure bugs in GStreamer Nothing stopping these being fixed in RHEL/CentOS. > * Browse depends on xulrunner for security and compatiblity with web > standards. Surfing the web today with a version of Firefox from > 3 years ago would be unthinkable RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 > * ...not to mention NetworkManager... Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. > > I would guesstimate that 80% of my time went into fixing platform bugs > and just 20% on Sugar itself. In part, this is because I could offload > the actual bugfixing to helpful people such as alsroot, silbe, > sayamindu, mtd and others. You are not alone, you should see my BZ queue. >> In short RHEL-6 isn't out yet, the associated CentOS6 release is quite >> a while away as a result. Also ARM isn't a supported platform there. >> Sugar is about options and I think having both options will be of >> benefit to different users. I believe the leading edge Fedora will >> continue to be a platform for development and then others in the know >> or deployments themselves can make the decision as to what's best for >> them. > > In practice, choosing the distro independently of Sugar won't be > feasible on the XO until: > > 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done > a lot of work in this direction, but there are still a number of > rogue packages in F11-XO1. In fact alot of the differences in packages were merged back in by me in the F-10/F-11 timeframe. I'm well aware of those issues, I still track them closely. I just wish it was the same with the kernel :-) > 2) we switch to a real package system for activities with full support > for dependency checking and a build cluster for multiple targets. One word. PackageKit. Then its agnostic for all the distributions. > After this is done, it remains to be seen if someone who is using RHEL-6 > on the XO would be able to file a bug in Red Hat's Bugzilla and actually > get it fixed for free. I have a feeling one would need to purchase an > enterprise support contract of some kind in order to attract the > necessary developer attention. You've obviously not dealt with them then on the RHEL side of things. I work for a company that had over 1200 RHEL systems. There are advantages to both approaches and I don't see that supporting both is going to be an issue to do so at least in the short term. I don't see that we need to rule out either option. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 09:31:25PM -0400, Bernie Innocenti wrote: > On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: > > Bernie, I'm not sure the point of this point at this point in time. To > > copy and paste part of the response I did to the other thread on > > fedora-olpc for others benefit. > > > > I personally don't see the point discussing it because from where I > > sit I believe it will be supported well in both and continue to be so. > > That way people have the choice. It might well get to a stage where > > the newer versions of sugar won't run in RHEL/CentOS due to whatever > > deps at which point we get to a situation where that release becomes > > like 0.84 is currently and is a long term support release. I don't see > > why its hard to support both because its not. The package maintenance > > is simple and is done easily by a couple of people. There will be > > Fedora and it will continue to be supported in Fedora for the > > developers and the like that want the bleeding edge and then there > > will be the EL branch for those that don't like so much blood. Its > > called choice. There's no reason to limit it. There's not much point > > discussing it at the moment as RHEL-6 isn't out yet, yes its in beta > > but its not out. > > I agree on this, but it misses the point :-) > > I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it > is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal > tweaks. > > Most end-user support issues lay within base OS components rather than > the relatively small codebase of Sugar. That's what I'm feeling all time started from the first time of my participating in sugar when I packaged sugar for several distros. > Here are some real-world > examples from this development cycle: > > * GSM connectivity requires up-to-date versions of udev and >modem-manager to support USB dongles commonly available in stores > > * Playing multimedia content downloaded from the Internet requires >gstreamer with up-to-date codecs > > * activities such as Record tend to uncover obscure bugs in GStreamer > > * Browse depends on xulrunner for security and compatiblity with web >standards. Surfing the web today with a version of Firefox from >3 years ago would be unthinkable > > * ...not to mention NetworkManager... > > > I would guesstimate that 80% of my time went into fixing platform bugs > and just 20% on Sugar itself. In part, this is because I could offload > the actual bugfixing to helpful people such as alsroot, silbe, > sayamindu, mtd and others. > > > > In short RHEL-6 isn't out yet, the associated CentOS6 release is quite > > a while away as a result. Also ARM isn't a supported platform there. > > Sugar is about options and I think having both options will be of > > benefit to different users. I believe the leading edge Fedora will > > continue to be a platform for development and then others in the know > > or deployments themselves can make the decision as to what's best for > > them. > > In practice, choosing the distro independently of Sugar won't be > feasible on the XO until: > > 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done >a lot of work in this direction, but there are still a number of >rogue packages in F11-XO1. > > 2) we switch to a real package system for activities with full support >for dependency checking and a build cluster for multiple targets. > > After this is done, it remains to be seen if someone who is using RHEL-6 > on the XO would be able to file a bug in Red Hat's Bugzilla and actually > get it fixed for free. I have a feeling one would need to purchase an > enterprise support contract of some kind in order to attract the > necessary developer attention. and thats why I like 0install way - it is not tied to particular distro (packaging system) but can get benefits from all major distros (via PackageKit) and add distro agnostic packaging system. In my plans create distro agnostic sugar distribution entirely based on 0install - on most recent systems, users need only several clicks to install sugar w/o root privileges and even if sugar didn't packaged at all for this particular distro. -- Aleksey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
IMHO I not only agree 120%, but also OLE Bolivia has budgeted support for upstreaming development. The idea being, if we are going to benefit, as an institution/country/project from work done professionally, if we are going to depend on it and expect it keeps up with improvements, then we have a duty to feed it, upstream, regularly. While an individual needs not be made responsible for that, I believe that any deployment above, say, 30-50 machines should consider helping fund development, at the local level especially, and have that development be made available to others. Deployments above the 1.000 units definitely can be counted as fair play when they have people on staff who are regularly connected with others worldwide in this effort. One of the uglier sides of piracy is that there is little sense of the duty to give back that has been built over the years. Hopefully we will get our project permitted to start sometime soon and we'll be able to contribute, as we have already benefited a lot from y'alls work. As Bernie says, there is a lot of skills out there, just waiting to be given a chance. Yama > I've been spending several months looking at problems > in the field, trying to fix some of them and, more importantly, trying > to build local capacity for fixing them autonomously. In my mind, this > is *the only* reasonable strategy to scale Sugar support up to the size > of an entire planet. Those who think it would be impossible for people > in developing nations to learn the technical skills needed for fixing > their software would be shocked to see what Nepal and Paraguay have been > able to achieve in just two years, with very little funding. > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: > Bernie, I'm not sure the point of this point at this point in time. To > copy and paste part of the response I did to the other thread on > fedora-olpc for others benefit. > > I personally don't see the point discussing it because from where I > sit I believe it will be supported well in both and continue to be so. > That way people have the choice. It might well get to a stage where > the newer versions of sugar won't run in RHEL/CentOS due to whatever > deps at which point we get to a situation where that release becomes > like 0.84 is currently and is a long term support release. I don't see > why its hard to support both because its not. The package maintenance > is simple and is done easily by a couple of people. There will be > Fedora and it will continue to be supported in Fedora for the > developers and the like that want the bleeding edge and then there > will be the EL branch for those that don't like so much blood. Its > called choice. There's no reason to limit it. There's not much point > discussing it at the moment as RHEL-6 isn't out yet, yes its in beta > but its not out. I agree on this, but it misses the point :-) I'm sure maintaining the Sugar 0.84 packages will be easy in RHEL6 as it is in F11. I've even back-ported Sugar 0.88 to Fedora 11 with minimal tweaks. Most end-user support issues lay within base OS components rather than the relatively small codebase of Sugar. Here are some real-world examples from this development cycle: * GSM connectivity requires up-to-date versions of udev and modem-manager to support USB dongles commonly available in stores * Playing multimedia content downloaded from the Internet requires gstreamer with up-to-date codecs * activities such as Record tend to uncover obscure bugs in GStreamer * Browse depends on xulrunner for security and compatiblity with web standards. Surfing the web today with a version of Firefox from 3 years ago would be unthinkable * ...not to mention NetworkManager... I would guesstimate that 80% of my time went into fixing platform bugs and just 20% on Sugar itself. In part, this is because I could offload the actual bugfixing to helpful people such as alsroot, silbe, sayamindu, mtd and others. > In short RHEL-6 isn't out yet, the associated CentOS6 release is quite > a while away as a result. Also ARM isn't a supported platform there. > Sugar is about options and I think having both options will be of > benefit to different users. I believe the leading edge Fedora will > continue to be a platform for development and then others in the know > or deployments themselves can make the decision as to what's best for > them. In practice, choosing the distro independently of Sugar won't be feasible on the XO until: 1) we merge (or kill) all the OLPC customizations. dsd and sdz have done a lot of work in this direction, but there are still a number of rogue packages in F11-XO1. 2) we switch to a real package system for activities with full support for dependency checking and a build cluster for multiple targets. After this is done, it remains to be seen if someone who is using RHEL-6 on the XO would be able to file a bug in Red Hat's Bugzilla and actually get it fixed for free. I have a feeling one would need to purchase an enterprise support contract of some kind in order to attract the necessary developer attention. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 06:12:46PM -0400, Bernie Innocenti wrote: > In the past, Sugar and OLPC development was much hurt by its > disconnection from the rest of the free software ecosystem on which it > was built. We need to get much closer to our upstream projects, both in > time (by using current software) and in space (by not diverging our > codebase). It's not just a technological issue, it's a long-term > sustainability issue. +1 I've also observed a correlation between cost of fixing problems and the release distance between the version we have and the upstream versions available. This distance, or lag, is important in the enterprise context, where I've worked for years in support ... but the lag causes higher costs that enterprise users can bear. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IAEP] Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Mon, Apr 12, 2010 at 11:12 PM, Bernie Innocenti wrote: > On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote: > >> Has there been any discussion on whether CentOS was an option as a >> base for the distro? With RHEL/CentOS 6 hopefully within sight, that >> would give a nice target to provide both the combination of stability >> and long term support. > > This comes up every once in a while. Frankly, I don't "believe" in the > value of enterprise Linux distributions; I've been stuck with them in a > couple of cases in the past, and they were always a support PITA even > for non-development usage: nobody in the community cares to help you > with debugging and back-porting recent versions of software becomes > increasingly painful over time. > > Granted, frequently upgrading the OS also comes with its own aches too, > but these are amply compensated by useful new features and better > support from upstream. > > We've been very lucky that Dan Williams was kind enough to spend some of > his time for helping us with critical bugs in NetworkManager 0.7. We've > not been equally lucky with udev and GStreamer, both of which have > unsolved issues in F11 for which we lack expertise. > > Over the last 5 years, I've become a strong advocate of the > decentralized, community-driven development model. I do believe in it > because I've observed it at work for 15 years. Traditionally minded > managers are still looking at this enormous market value accumulated by > the open model as some sort of economic anomaly; some sort of prestige > trick which contradicts the rules of classic schoolbooks. Yet, an entire > industry of new businesses has grown out of free software and is > flourishing with it. Those who guessed its rules can play the game and > win. > > As Martin and I discussed not long ago, our development model doesn't > have to directly affect end-users. Already released free software > doesn't have an expiration date. Conservative users can keep using Sugar > 0.82 forever, if they really like it better than newer releases. > Bugfixes and new features could be back-ported from newer releases, of > course with increasing costs as time passes. > > We OLPC & Sugar developers cannot effectively support the entire > codebase of an entire OS without strong backing from the larger Fedora > community and the even larger global Linux community. > > In the past, Sugar and OLPC development was much hurt by its > disconnection from the rest of the free software ecosystem on which it > was built. We need to get much closer to our upstream projects, both in > time (by using current software) and in space (by not diverging our > codebase). It's not just a technological issue, it's a long-term > sustainability issue. > > Before anyone yells "Yarr! Ye don't care about the children!", I'd like > to point out that I've been spending several months looking at problems > in the field, trying to fix some of them and, more importantly, trying > to build local capacity for fixing them autonomously. In my mind, this > is *the only* reasonable strategy to scale Sugar support up to the size > of an entire planet. Those who think it would be impossible for people > in developing nations to learn the technical skills needed for fixing > their software would be shocked to see what Nepal and Paraguay have been > able to achieve in just two years, with very little funding. Bernie, I'm not sure the point of this point at this point in time. To copy and paste part of the response I did to the other thread on fedora-olpc for others benefit. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. In short RHEL-6 isn't out yet, the associated CentOS6 release is quite a while away as a result. Also ARM isn't a supported platform there. Sugar is about options and I think having both options will be of benefit to different users. I believe the leading edge Fedora will continue to be a platform for development and then others in the know or deployments themselves can make the decision as to what's best for them. Peter Peter ___ Devel mailing list Devel@lists.laptop.org
Re: New XO-1.5 10.2.0 build 119
Hi, > There's not much point discussing it at the moment as RHEL-6 > isn't out yet This is my feeling too -- I agree that RHEL and CentOS 6 will be a more attractive base than any of their previous releases have been, and we'll want to consider them then. Not much more to say until we know more about the release, though. By the way, there's been some Sugar Labs discussion about finding a long-term support platform for Sugar, with an eye towards RHEL/CentOS 6 as a candidate for that: http://wiki.sugarlabs.org/go/User:Walter/Goals * Define Sugar 1.0 so that we can begin partnering with long-term stable distros, such as RHEL If that happens, and SL does choose a base for "Sugar 1.0" to be supported long-term, that'll make a decision for us to forego constant updates easier. (Since we'll only need the constant updates if Sugar's depending on them.) - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
>> Believe me I'll be one of the first poeple adding the sugar packages >> to EL-6 branches and testing them but its not necessarily the golden >> path that some people think. In the short term of the first 12 months >> it will be fine, 18 months to 2.5 years it won't seem as good. > > I am not seeing where the 18 months to 2.5 years breakdown happens. > You have a base OS that is being supported for security updates by the > largest Linux vendor for the next 6 years. For the small subset of > packages that you need a more recent version of, i.e. the kernel and > telepathy, you would just release in an OLPC yum repository. This is > already being done for the kernel and other OLPC specific packages, so > really there is little overhead to this path. The 18 months to 2.5 years was a rough guesstimate of the time from where RHEL 6 is released to when the libraries it runs are out of date and not what the latest sugar release wants at the time. Then RHEL-7 is released and we repeat the process all over again. > We are getting to a point where the core components of linux on the > desktop are matured such that a core refresh really isn't needed every > 6 months. NetworkManager, PackageKit, PolicyKit provide a lot of what > the desktop needs from an administration point (Yes I didn't mention > Pulseaudio, maybe soon :-)). For the first time in a long time I > really don't see any major changes in the near future that will really > be a roadblock to a stable distribution rolled out in the next year. Things change, 2, 3, or 6 years is a long time in IT, a life time in open source. gstreamer 1 will come along in a year or so and there'll be something we want for some smart new hardware. Sugar will be ported to python3. The new ARM based XO 1.75 or XO-3 or what ever the XO-x version is that's not supported in CentOS. I personally don't see the point discussing it because from where I sit I believe it will be supported well in both and continue to be so. That way people have the choice. It might well get to a stage where the newer versions of sugar won't run in RHEL/CentOS due to whatever deps at which point we get to a situation where that release becomes like 0.84 is currently and is a long term support release. I don't see why its hard to support both because its not. The package maintenance is simple and is done easily by a couple of people. There will be Fedora and it will continue to be supported in Fedora for the developers and the like that want the bleeding edge and then there will be the EL branch for those that don't like so much blood. Its called choice. There's no reason to limit it. There's not much point discussing it at the moment as RHEL-6 isn't out yet, yes its in beta but its not out. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 10:34 PM, Daniel Drake wrote: > On 12 April 2010 15:10, Peter Robinson wrote: >> I don't have the XO near me to test but 'yum remove perl' will give >> you the answer. > > On XO-1.5 running something very close to 10.2.0 build 119, it wants > to remove many components including anacron, yum, rpm, > ds-backup-client, olpc-update, ... > > Is this what you expect? That's because of the exim. Do a 'yum install ssmtp' then a 'yum remove exim' and most of that problem goes away. the auto depsolving for '/usr/bin/sendmail' get exim by default because its the shortest name and comes first. exim depends on perl. ssmtp is a very small 50k dep that gives cronie what it wants. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Long-term development strategy (Was: New XO-1.5 10.2.0 build 119)
On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote: > Has there been any discussion on whether CentOS was an option as a > base for the distro? With RHEL/CentOS 6 hopefully within sight, that > would give a nice target to provide both the combination of stability > and long term support. This comes up every once in a while. Frankly, I don't "believe" in the value of enterprise Linux distributions; I've been stuck with them in a couple of cases in the past, and they were always a support PITA even for non-development usage: nobody in the community cares to help you with debugging and back-porting recent versions of software becomes increasingly painful over time. Granted, frequently upgrading the OS also comes with its own aches too, but these are amply compensated by useful new features and better support from upstream. We've been very lucky that Dan Williams was kind enough to spend some of his time for helping us with critical bugs in NetworkManager 0.7. We've not been equally lucky with udev and GStreamer, both of which have unsolved issues in F11 for which we lack expertise. Over the last 5 years, I've become a strong advocate of the decentralized, community-driven development model. I do believe in it because I've observed it at work for 15 years. Traditionally minded managers are still looking at this enormous market value accumulated by the open model as some sort of economic anomaly; some sort of prestige trick which contradicts the rules of classic schoolbooks. Yet, an entire industry of new businesses has grown out of free software and is flourishing with it. Those who guessed its rules can play the game and win. As Martin and I discussed not long ago, our development model doesn't have to directly affect end-users. Already released free software doesn't have an expiration date. Conservative users can keep using Sugar 0.82 forever, if they really like it better than newer releases. Bugfixes and new features could be back-ported from newer releases, of course with increasing costs as time passes. We OLPC & Sugar developers cannot effectively support the entire codebase of an entire OS without strong backing from the larger Fedora community and the even larger global Linux community. In the past, Sugar and OLPC development was much hurt by its disconnection from the rest of the free software ecosystem on which it was built. We need to get much closer to our upstream projects, both in time (by using current software) and in space (by not diverging our codebase). It's not just a technological issue, it's a long-term sustainability issue. Before anyone yells "Yarr! Ye don't care about the children!", I'd like to point out that I've been spending several months looking at problems in the field, trying to fix some of them and, more importantly, trying to build local capacity for fixing them autonomously. In my mind, this is *the only* reasonable strategy to scale Sugar support up to the size of an entire planet. Those who think it would be impossible for people in developing nations to learn the technical skills needed for fixing their software would be shocked to see what Nepal and Paraguay have been able to achieve in just two years, with very little funding. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 2:04 PM, Peter Robinson wrote: > On Mon, Apr 12, 2010 at 10:04 PM, Mikus Grinbergs wrote: >>> It will then be OK for a while until Sugar needs a newer version of a >>> library >> >> I think there is an "elephant in the living room" to which too little >> attention is being paid. Consider Peru - they have a lot of XO-1 >> systems, on which it is unlikely that the newest version of Sugar will >> ever be installed. But Peru *might* want to add a Linux utility into >> their systems -- for that they need access to a package repository with >> the same-level software as the rest of the software they already have. >> >> What I am saying is that for many deployments, a "need for newer >> libraries" will probably never exist -- but a "need for older libraries" >> is more likely to arise. > > I'm not saying its not the right direction and it might be almost time > to move there but I've also seen hacked up versions of old Fedora in > the past just to get the later version of some telepathy library, and > Tomeu's work to bring sugar inline with the rest of telepathy and > allow support of other IM interfaces in the next release might well be > an example of this. > > Believe me I'll be one of the first poeple adding the sugar packages > to EL-6 branches and testing them but its not necessarily the golden > path that some people think. In the short term of the first 12 months > it will be fine, 18 months to 2.5 years it won't seem as good. I am not seeing where the 18 months to 2.5 years breakdown happens. You have a base OS that is being supported for security updates by the largest Linux vendor for the next 6 years. For the small subset of packages that you need a more recent version of, i.e. the kernel and telepathy, you would just release in an OLPC yum repository. This is already being done for the kernel and other OLPC specific packages, so really there is little overhead to this path. We are getting to a point where the core components of linux on the desktop are matured such that a core refresh really isn't needed every 6 months. NetworkManager, PackageKit, PolicyKit provide a lot of what the desktop needs from an administration point (Yes I didn't mention Pulseaudio, maybe soon :-)). For the first time in a long time I really don't see any major changes in the near future that will really be a roadblock to a stable distribution rolled out in the next year. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 2:34 PM, Daniel Drake wrote: > On 12 April 2010 15:10, Peter Robinson wrote: >> I don't have the XO near me to test but 'yum remove perl' will give >> you the answer. > > On XO-1.5 running something very close to 10.2.0 build 119, it wants > to remove many components including anacron, yum, rpm, > ds-backup-client, olpc-update, ... > This is a dependency problem because you don't have ssmtp installed to provide the sendmail requirement that all these packages need. Personally I always install ssmtp instead of sendmail on all my embedded respins. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 12 April 2010 15:10, Peter Robinson wrote: > I don't have the XO near me to test but 'yum remove perl' will give > you the answer. On XO-1.5 running something very close to 10.2.0 build 119, it wants to remove many components including anacron, yum, rpm, ds-backup-client, olpc-update, ... Is this what you expect? Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 10:04 PM, Mikus Grinbergs wrote: >> It will then be OK for a while until Sugar needs a newer version of a >> library > > I think there is an "elephant in the living room" to which too little > attention is being paid. Consider Peru - they have a lot of XO-1 > systems, on which it is unlikely that the newest version of Sugar will > ever be installed. But Peru *might* want to add a Linux utility into > their systems -- for that they need access to a package repository with > the same-level software as the rest of the software they already have. > > What I am saying is that for many deployments, a "need for newer > libraries" will probably never exist -- but a "need for older libraries" > is more likely to arise. I'm not saying its not the right direction and it might be almost time to move there but I've also seen hacked up versions of old Fedora in the past just to get the later version of some telepathy library, and Tomeu's work to bring sugar inline with the rest of telepathy and allow support of other IM interfaces in the next release might well be an example of this. Believe me I'll be one of the first poeple adding the sugar packages to EL-6 branches and testing them but its not necessarily the golden path that some people think. In the short term of the first 12 months it will be fine, 18 months to 2.5 years it won't seem as good. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
> It will then be OK for a while until Sugar needs a newer version of a > library I think there is an "elephant in the living room" to which too little attention is being paid. Consider Peru - they have a lot of XO-1 systems, on which it is unlikely that the newest version of Sugar will ever be installed. But Peru *might* want to add a Linux utility into their systems -- for that they need access to a package repository with the same-level software as the rest of the software they already have. What I am saying is that for many deployments, a "need for newer libraries" will probably never exist -- but a "need for older libraries" is more likely to arise. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 3:56 PM, Peter Robinson wrote: > In the longer term its likely that it will be. The libraries in CentOS > 5 are too old. The problem is that RHEL-6 isn't out yet, nor is there At least this XS guy is hopefuly that RHEL-6 will appear soon and XS 0.7 or 0.8 will be based on it (or matching CentOS). When we need latest and greatest (kernel, xorg, etc) Fedora is unbeatable. But that same speed hurts. At least the XS clearly doesn't need latest and greatest except for very specific packages. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
--- On Mon, 4/12/10, Peter Robinson wrote: > From: Peter Robinson > Subject: Re: New XO-1.5 10.2.0 build 119 > To: "Yioryos Asprobounitis" > Cc: "Bernie Innocenti" , "Devel" > , "Fedora OLPC" > Date: Monday, April 12, 2010, 3:56 PM > On Mon, Apr 12, 2010 at 8:40 PM, > Yioryos Asprobounitis > > wrote: > > > > > > --- On Mon, 4/12/10, Bernie Innocenti > wrote: > > > >> From: Bernie Innocenti > >> Subject: Re: New XO-1.5 10.2.0 build 119 > >> To: "Peter Robinson" > >> Cc: "Devel" , > "Fedora OLPC" > >> Date: Monday, April 12, 2010, 9:15 AM > >> On Sat, 2010-04-10 at 17:57 +0100, > >> Peter Robinson wrote: > >> > >> Finally, I guess you have thought of > it, but > >> by the > >> > >> time 10.2 will be out F11 > repositories will > >> be down > >> > >> and thus the builds totally frozen > >> software-wise. > >> > > > >> > > I think it would have been better to > rebase on > >> F12 6 months ago. > >> > > Now it's way too close to the release > date :-( > >> > > >> > I recommended F-12 which was in beta when > this process > >> started but was > >> > ignored. I noticed the other day that dsd has > created > >> a F-12 branch in > >> > git but I think we should be aiming straight > for F-13 > >> now. It'll be > >> > out in a little over a month, is quite stable > already > >> and have will be > >> > supported for another 14 months. > >> > >> +1 > >> > >> F13, btw, seems like a very solid release to me. > > > > I do not know why re-basing on F13 will reach > deployment status much faster than F11 and will not be at > the same point a year from now. > > The XO is a _production_ machine. Makes no sense to > run development/short-lived OS. Maybe the RHEL/CentOS idea > should not be dismissed, if feasible. > > In the longer term its likely that it will be. The > libraries in CentOS > 5 are too old. The problem is that RHEL-6 isn't out yet, > nor is there > any announcements when it will be, then from there the > CentOS team > need to review, engineer, QA and release CentOS 6. Then you > need to > build/test/QA sugar etc for it. > > It will then be OK for a while until Sugar needs a newer > version of a > library that is static on CentOS due to the support > requirements. And > then it reverts to Fedora. And before you mention Ubuntu > LTS, the > previous LTS has the same version issues, the current one > will still > have the same problems going forward. Maybe so, but the fact is that "going forward" actually means that the XOs are still running F9, and hopping to get an EOL F11 in the next few months. So at the end of the day this "needed library" is not actually used by the vast majority of the actual users. I repeat that the XO, and education in general, is/needs _production_ machines. Given the resources and the development rate, a 3-4 years OS support should be the minimum I think, even if the feature requiring "that library" is not implemented. Just my 2c. > > Peter > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
> > Gentlemen - on some of my XO-1s I've installed perl onto my > > "permanent" SD card, rather than having it occupy jffs2. By > > doing so, I've saved about 33 MB of space in jffs2. > > > > Is that a large enough savings (given a 4000 MB XO-1.5) to be > > worth spending this much discussion on ? > > Yes, because some XO-1.5s may have 2GB, and your 33MB is compressed > size whereas the XO-1.5 uses an uncompressed fs -- the used space > on 1.5 may be several times your 33MB. The 33 MB I gave is not compressed - it is what 'du' tells me about the directory tree on the SD card where I have (all of) perl installed. I have not added up how much space is taken up by having /versions in addition to what is needed to run a build - but I suspect the current "overhead" exceeds 100 MB. That's where I would start "saving space". mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 8:40 PM, Yioryos Asprobounitis wrote: > > > --- On Mon, 4/12/10, Bernie Innocenti wrote: > >> From: Bernie Innocenti >> Subject: Re: New XO-1.5 10.2.0 build 119 >> To: "Peter Robinson" >> Cc: "Devel" , "Fedora OLPC" >> >> Date: Monday, April 12, 2010, 9:15 AM >> On Sat, 2010-04-10 at 17:57 +0100, >> Peter Robinson wrote: >> > >> Finally, I guess you have thought of it, but >> by the >> > >> time 10.2 will be out F11 repositories will >> be down >> > >> and thus the builds totally frozen >> software-wise. >> > > >> > > I think it would have been better to rebase on >> F12 6 months ago. >> > > Now it's way too close to the release date :-( >> > >> > I recommended F-12 which was in beta when this process >> started but was >> > ignored. I noticed the other day that dsd has created >> a F-12 branch in >> > git but I think we should be aiming straight for F-13 >> now. It'll be >> > out in a little over a month, is quite stable already >> and have will be >> > supported for another 14 months. >> >> +1 >> >> F13, btw, seems like a very solid release to me. > > I do not know why re-basing on F13 will reach deployment status much faster > than F11 and will not be at the same point a year from now. > The XO is a _production_ machine. Makes no sense to run > development/short-lived OS. Maybe the RHEL/CentOS idea should not be > dismissed, if feasible. In the longer term its likely that it will be. The libraries in CentOS 5 are too old. The problem is that RHEL-6 isn't out yet, nor is there any announcements when it will be, then from there the CentOS team need to review, engineer, QA and release CentOS 6. Then you need to build/test/QA sugar etc for it. It will then be OK for a while until Sugar needs a newer version of a library that is static on CentOS due to the support requirements. And then it reverts to Fedora. And before you mention Ubuntu LTS, the previous LTS has the same version issues, the current one will still have the same problems going forward. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
Hi, > Gentlemen - on some of my XO-1s I've installed perl onto my > "permanent" SD card, rather than having it occupy jffs2. By > doing so, I've saved about 33 MB of space in jffs2. > > Is that a large enough savings (given a 4000 MB XO-1.5) to be > worth spending this much discussion on ? Yes, because some XO-1.5s may have 2GB, and your 33MB is compressed size whereas the XO-1.5 uses an uncompressed fs -- the used space on 1.5 may be several times your 33MB. - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 8:52 PM, Mikus Grinbergs wrote: >> 'yum remove perl' will give you the answer. > > Gentlemen - on some of my XO-1s I've installed perl onto my "permanent" > SD card, rather than having it occupy jffs2. By doing so, I've saved > about 33 MB of space in jffs2. > > Is that a large enough savings (given a 4000 MB XO-1.5) to be worth > spending this much discussion on ? Everything helps, and this is also relevant for the XO-1. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
> 'yum remove perl' will give you the answer. Gentlemen - on some of my XO-1s I've installed perl onto my "permanent" SD card, rather than having it occupy jffs2. By doing so, I've saved about 33 MB of space in jffs2. Is that a large enough savings (given a 4000 MB XO-1.5) to be worth spending this much discussion on ? mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
--- On Mon, 4/12/10, Bernie Innocenti wrote: > From: Bernie Innocenti > Subject: Re: New XO-1.5 10.2.0 build 119 > To: "Peter Robinson" > Cc: "Devel" , "Fedora OLPC" > > Date: Monday, April 12, 2010, 9:15 AM > On Sat, 2010-04-10 at 17:57 +0100, > Peter Robinson wrote: > > >> Finally, I guess you have thought of it, but > by the > > >> time 10.2 will be out F11 repositories will > be down > > >> and thus the builds totally frozen > software-wise. > > > > > > I think it would have been better to rebase on > F12 6 months ago. > > > Now it's way too close to the release date :-( > > > > I recommended F-12 which was in beta when this process > started but was > > ignored. I noticed the other day that dsd has created > a F-12 branch in > > git but I think we should be aiming straight for F-13 > now. It'll be > > out in a little over a month, is quite stable already > and have will be > > supported for another 14 months. > > +1 > > F13, btw, seems like a very solid release to me. I do not know why re-basing on F13 will reach deployment status much faster than F11 and will not be at the same point a year from now. The XO is a _production_ machine. Makes no sense to run development/short-lived OS. Maybe the RHEL/CentOS idea should not be dismissed, if feasible. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 04/12/2010 02:51 PM, Daniel Drake wrote: > find /sys -name '*cputemp*' /sys/devices/platform/via_cputemp.0 Awesome! I'll change my scripts and remove that dependency. Thanks. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 11:10 AM, Peter Robinson wrote: > On Mon, Apr 12, 2010 at 7:09 PM, Daniel Drake wrote: >> On 12 April 2010 14:51, Peter Robinson wrote: >>> I've got some more time and have finally had a chance to look at these >>> further. From an initial looks it looks like your getting exim due to >>> the cronie deps on /usr/bin/sendmail. If you add an explicit 'ssmtp' >>> into the .ks that will provide that dep instead. Also it looks like >>> inkscape and the burning tools are the only other things that require >>> perl. I'm hoping the inkscape issue will be fixed before F-11 goes >>> EOL, and I'm not sure whether the olpc burnin tools are a requirement >>> for the final shipping image or how large the perl dep is there. >> >> Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? > > I don't have the XO near me to test but 'yum remove perl' will give > you the answer. Yes that is the one. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 12 April 2010 15:45, Richard A. Smith wrote: > Except for where I specified extra stuff I needed. :) like lm_sensors > which requires perl. > > So I need to find a way to read the CPU temp without lm_sensors or we > somehow need to break lm_sensors use of perl. It's really easy to read from sysfs. I wish we had some XO's here to test. This should give some clues: find /sys -name '*cputemp*' Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 7:45 PM, Richard A. Smith wrote: > On 04/12/2010 02:34 PM, Peter Robinson wrote: > >>> perl? I created them on the XO so anything that I used should have >>> already been installed. > > Except for where I specified extra stuff I needed. :) like lm_sensors which > requires perl. > > So I need to find a way to read the CPU temp without lm_sensors or we > somehow need to break lm_sensors use of perl. Ah :-D Let me have a look at lm_sensors and see what there depends on it and see if we can't get it split out into a perl sub package. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 04/12/2010 02:34 PM, Peter Robinson wrote: >> perl? I created them on the XO so anything that I used should have >> already been installed. Except for where I specified extra stuff I needed. :) like lm_sensors which requires perl. So I need to find a way to read the CPU temp without lm_sensors or we somehow need to break lm_sensors use of perl. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 7:21 PM, Richard A. Smith wrote: > On 04/12/2010 02:10 PM, Peter Robinson wrote: > >>> >>> Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? >> >> I don't have the XO near me to test but 'yum remove perl' will give >> you the answer. > > The runin scripts are all bash. Not sure why perl would be a > dependency. Perhaps one of the commands that the runin tests call needs > perl? I created them on the XO so anything that I used should have > already been installed. I'll be home shortly so I can look closer. Cheers, Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
smith wrote: > On 04/12/2010 02:10 PM, Peter Robinson wrote: > > >> > >> Which burnin package are you referring to? > >> olpc-runin-tests-0.9.15-1.noarch? > > > > I don't have the XO near me to test but 'yum remove perl' will give > > you the answer. > > The runin scripts are all bash. Not sure why perl would be a > dependency. Perhaps one of the commands that the runin tests call needs > perl? I created them on the XO so anything that I used should have > already been installed. but dependencies don't get created automatically. it must be due to something in your spec file, no? paul =- paul fox, p...@laptop.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 04/12/2010 02:10 PM, Peter Robinson wrote: >> >> Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? > > I don't have the XO near me to test but 'yum remove perl' will give > you the answer. The runin scripts are all bash. Not sure why perl would be a dependency. Perhaps one of the commands that the runin tests call needs perl? I created them on the XO so anything that I used should have already been installed. -- Richard A. Smith One Laptop per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Mon, Apr 12, 2010 at 7:09 PM, Daniel Drake wrote: > On 12 April 2010 14:51, Peter Robinson wrote: >> I've got some more time and have finally had a chance to look at these >> further. From an initial looks it looks like your getting exim due to >> the cronie deps on /usr/bin/sendmail. If you add an explicit 'ssmtp' >> into the .ks that will provide that dep instead. Also it looks like >> inkscape and the burning tools are the only other things that require >> perl. I'm hoping the inkscape issue will be fixed before F-11 goes >> EOL, and I'm not sure whether the olpc burnin tools are a requirement >> for the final shipping image or how large the perl dep is there. > > Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? I don't have the XO near me to test but 'yum remove perl' will give you the answer. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On 12 April 2010 14:51, Peter Robinson wrote: > I've got some more time and have finally had a chance to look at these > further. From an initial looks it looks like your getting exim due to > the cronie deps on /usr/bin/sendmail. If you add an explicit 'ssmtp' > into the .ks that will provide that dep instead. Also it looks like > inkscape and the burning tools are the only other things that require > perl. I'm hoping the inkscape issue will be fixed before F-11 goes > EOL, and I'm not sure whether the olpc burnin tools are a requirement > for the final shipping image or how large the perl dep is there. Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
Hey Chris, On Fri, Apr 9, 2010 at 9:27 PM, Chris Ball wrote: > http://wiki.laptop.org/go/F11_for_1.5 > http://build.laptop.org/10.2.0/os119 > > Compressed image size: 678.36mb (+0.01mb since build 118) > > Description of changes in this build: > * kernel: allow negotiation of 5/10/15/30fps (#10106) > > With this change, Record should be able to record audio+video together, > although you'll still need to VT switch away and back if you get a black > Xv overlay as described in http://dev.laptop.org/ticket/10068. > > Package changes since build 118: > > -kernel-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > -kernel-firmware-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 I've got some more time and have finally had a chance to look at these further. From an initial looks it looks like your getting exim due to the cronie deps on /usr/bin/sendmail. If you add an explicit 'ssmtp' into the .ks that will provide that dep instead. Also it looks like inkscape and the burning tools are the only other things that require perl. I'm hoping the inkscape issue will be fixed before F-11 goes EOL, and I'm not sure whether the olpc burnin tools are a requirement for the final shipping image or how large the perl dep is there. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Sat, 2010-04-10 at 17:57 +0100, Peter Robinson wrote: > >> Finally, I guess you have thought of it, but by the > >> time 10.2 will be out F11 repositories will be down > >> and thus the builds totally frozen software-wise. > > > > I think it would have been better to rebase on F12 6 months ago. > > Now it's way too close to the release date :-( > > I recommended F-12 which was in beta when this process started but was > ignored. I noticed the other day that dsd has created a F-12 branch in > git but I think we should be aiming straight for F-13 now. It'll be > out in a little over a month, is quite stable already and have will be > supported for another 14 months. +1 F13, btw, seems like a very solid release to me. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
I guess something was left out from the Speak-14 installation in this build. Launching gives the following warning "Cannot find cached 0sugar-launch implementation" Tries for some more time and then dies. Was fine in os116. --- On Fri, 4/9/10, Chris Ball wrote: > From: Chris Ball > Subject: New XO-1.5 10.2.0 build 119 > To: "Fedora OLPC" > Cc: "Devel" > Date: Friday, April 9, 2010, 4:27 PM > http://wiki.laptop.org/go/F11_for_1.5 > http://build.laptop.org/10.2.0/os119 > > Compressed image size: 678.36mb (+0.01mb since build 118) > > Description of changes in this build: > * kernel: allow negotiation of 5/10/15/30fps (#10106) > > With this change, Record should be able to record > audio+video together, > although you'll still need to VT switch away and back if > you get a black > Xv overlay as described in http://dev.laptop.org/ticket/10068. > > Package changes since build 118: > > -kernel-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > -kernel-firmware-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Sat, Apr 10, 2010 at 11:40 AM, Yioryos Asprobounitis wrote: > > > --- On Sat, 4/10/10, Bernie Innocenti wrote: > >> From: Bernie Innocenti >> Subject: Re: New XO-1.5 10.2.0 build 119 >> To: "Yioryos Asprobounitis" >> Cc: "Fedora OLPC" , "Chris Ball" >> , "Devel" >> Date: Saturday, April 10, 2010, 8:35 AM >> On Sat, 2010-04-10 at 01:47 -0700, >> Yioryos Asprobounitis wrote: > >> Repositories for end-of-life releases are just moved to >> permanent >> archives which are mirrored in fewer locations. For >> example: >> >> http://archive.kernel.org/fedora-archive/ > > Do you know of any place that has the Fedora 9 rpms? > People are looking for them to add new apps functions and hacks on Sugar-0.82 > machines but there are nowhere to be found. > If F9 repos were still available, F11 builds might not even be needed for the > XO-1. > The same thing will happen to XO-1.5 by the time that F11 builds will get > deployment status. > I would assume that deployments need a LTS release or a seamless upgrade. > They can not go by the 6-month release cycle. > So mirroring a snapshot of the latest F11 repos before taken down will be > important for the immediate future, till moving to F13-F14 or whatever is > decided. Has there been any discussion on whether CentOS was an option as a base for the distro? With RHEL/CentOS 6 hopefully within sight, that would give a nice target to provide both the combination of stability and long term support. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
Hi, > Do you know of any place that has the Fedora 9 rpms? People are > looking for them to add new apps functions and hacks on > Sugar-0.82 machines but there are nowhere to be found. If F9 > repos were still available, F11 builds might not even be needed > for the XO-1. I just booted an XO-1 running 8.2, and yum installing a package from Fedora still works. The URL used by yum.repos.d on that build is: http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-9&arch=i386 which returns a list of mirrors including: http://archive.kernel.org/fedora-archive/releases/9/Everything/i386/os/Packages/ So, I don't understand what the problem is. - Chris. -- Chris Ball One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
--- On Sat, 4/10/10, Bernie Innocenti wrote: > From: Bernie Innocenti > Subject: Re: New XO-1.5 10.2.0 build 119 > To: "Yioryos Asprobounitis" > Cc: "Fedora OLPC" , "Chris Ball" > , "Devel" > Date: Saturday, April 10, 2010, 8:35 AM > On Sat, 2010-04-10 at 01:47 -0700, > Yioryos Asprobounitis wrote: > Repositories for end-of-life releases are just moved to > permanent > archives which are mirrored in fewer locations. For > example: > > http://archive.kernel.org/fedora-archive/ Do you know of any place that has the Fedora 9 rpms? People are looking for them to add new apps functions and hacks on Sugar-0.82 machines but there are nowhere to be found. If F9 repos were still available, F11 builds might not even be needed for the XO-1. The same thing will happen to XO-1.5 by the time that F11 builds will get deployment status. I would assume that deployments need a LTS release or a seamless upgrade. They can not go by the 6-month release cycle. So mirroring a snapshot of the latest F11 repos before taken down will be important for the immediate future, till moving to F13-F14 or whatever is decided. > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
>> Finally, I guess you have thought of it, but by the >> time 10.2 will be out F11 repositories will be down >> and thus the builds totally frozen software-wise. > > I think it would have been better to rebase on F12 6 months ago. > Now it's way too close to the release date :-( I recommended F-12 which was in beta when this process started but was ignored. I noticed the other day that dsd has created a F-12 branch in git but I think we should be aiming straight for F-13 now. It'll be out in a little over a month, is quite stable already and have will be supported for another 14 months. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
--- On Sat, 4/10/10, Bernie Innocenti wrote: > From: Bernie Innocenti > Subject: Re: New XO-1.5 10.2.0 build 119 > To: "Yioryos Asprobounitis" > Cc: "Fedora OLPC" , "Chris Ball" > , "Devel" > Date: Saturday, April 10, 2010, 8:35 AM > On Sat, 2010-04-10 at 01:47 -0700, > Yioryos Asprobounitis wrote: > > Unfortunately Record.activity is not really working > yet. Filed #1931 with sugarlabs. > > Is this on the XO-1.5, or also on the XO-1? XO-1.5. Didn't test XO-1. My XO-1 has a broken camera. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Updated OpenChrome on Debian (was: Re: New XO-1.5 10.2.0 build 119)
On Sat, Apr 10, 2010 at 8:18 AM, Sascha Silbe wrote: > On Sat, Apr 10, 2010 at 07:12:18AM -0700, Jon Nettleton wrote: > >> This bug has been located and will be fixed in the next rpm of >> openchrome. I will post a link to an updated rpm also. > > BTW, is there a chance to get your updated versions of openChrome on a > Debian system somehow? Some git repo I could pull the changes from and > somehow mingle with the Debian source package? > The git repo I do my dev work in is http://github.com/linux4kix/openchrome.git This repo is not official in fact it is my playground to break things at will. Generally features live there while testing then get moved to trunk at http://svn.openchrome.org/trunk. If you want something somewhat stable I would suggest getting the src.rpm from http://koji.fedoraproject.org/koji/packageinfo?packageID=5229 and extracting it out and repackaging it as a .deb. I work with Xavier to give him patches that we want tested by the masses and also get pulled into the XO 1.5 builds. Hope that helps Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Updated OpenChrome on Debian (was: Re: New XO-1.5 10.2.0 build 119)
On Sat, Apr 10, 2010 at 07:12:18AM -0700, Jon Nettleton wrote: This bug has been located and will be fixed in the next rpm of openchrome. I will post a link to an updated rpm also. BTW, is there a chance to get your updated versions of openChrome on a Debian system somehow? Some git repo I could pull the changes from and somehow mingle with the Debian source package? CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Sat, Apr 10, 2010 at 1:47 AM, Yioryos Asprobounitis wrote: > Unfortunately Record.activity is not really working yet. Filed #1931 with > sugarlabs. > Also GIMP is freezing the XO-1.5 as soon as you open an image. Both in Gnome > and launched from Sugar. Hard reboot is the only way out. This bug has been located and will be fixed in the next rpm of openchrome. I will post a link to an updated rpm also. -Jon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
On Sat, 2010-04-10 at 01:47 -0700, Yioryos Asprobounitis wrote: > Unfortunately Record.activity is not really working yet. Filed #1931 with > sugarlabs. Is this on the XO-1.5, or also on the XO-1? I tested Record v65 yesterday on os129py and it was perfect. > ntpdate is missing from the builds. Easy to add but maybe should > be there to begin with. What is it needed for? Does NM use it on connection to synchronize the systrem clock? > Finally, I guess you have thought of it, but by the > time 10.2 will be out F11 repositories will be down > and thus the builds totally frozen software-wise. I think it would have been better to rebase on F12 6 months ago. Now it's way too close to the release date :-( > Is there anyway to mirror and keep them (without any updating) > somewhere till migration to F>11, so at least if a component > is needed can be found at that time? Repositories for end-of-life releases are just moved to permanent archives which are mirrored in fewer locations. For example: http://archive.kernel.org/fedora-archive/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New XO-1.5 10.2.0 build 119
Unfortunately Record.activity is not really working yet. Filed #1931 with sugarlabs. Also GIMP is freezing the XO-1.5 as soon as you open an image. Both in Gnome and launched from Sugar. Hard reboot is the only way out. Should not be included in the build till shorted out. ntpdate is missing from the builds. Easy to add but maybe should be there to begin with. Finally, I guess you have thought of it, but by the time 10.2 will be out F11 repositories will be down and thus the builds totally frozen software-wise. Is there anyway to mirror and keep them (without any updating) somewhere till migration to F>11, so at least if a component is needed can be found at that time? --- On Fri, 4/9/10, Chris Ball wrote: > From: Chris Ball > Subject: New XO-1.5 10.2.0 build 119 > To: "Fedora OLPC" > Cc: "Devel" > Date: Friday, April 9, 2010, 4:27 PM > http://wiki.laptop.org/go/F11_for_1.5 > http://build.laptop.org/10.2.0/os119 > > Compressed image size: 678.36mb (+0.01mb since build 118) > > Description of changes in this build: > * kernel: allow negotiation of 5/10/15/30fps (#10106) > > With this change, Record should be able to record > audio+video together, > although you'll still need to VT switch away and back if > you get a black > Xv overlay as described in http://dev.laptop.org/ticket/10068. > > Package changes since build 118: > > -kernel-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > -kernel-firmware-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 > +kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 > ___ > olpc mailing list > o...@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/olpc > ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New XO-1.5 10.2.0 build 119
http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.2.0/os119 Compressed image size: 678.36mb (+0.01mb since build 118) Description of changes in this build: * kernel: allow negotiation of 5/10/15/30fps (#10106) With this change, Record should be able to record audio+video together, although you'll still need to VT switch away and back if you get a black Xv overlay as described in http://dev.laptop.org/ticket/10068. Package changes since build 118: -kernel-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 +kernel-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 -kernel-firmware-2.6.31_xo1.5-20100331.1824.1.olpc.5944795.i586 +kernel-firmware-2.6.31_xo1.5-20100409.1311.1.olpc.03dde3f.i586 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
