On Sat, 2010-04-10 at 01:47 -0700, Yioryos Asprobounitis wrote: Is this on the XO-1.5, or also on the XO-1? I tested Record v65 yesterday on os129py and it was perfect. What is it needed for? Does NM use it on connection to synchronize the systrem clock? I think it would have been better to rebase on F12 6 months ago. Now it's way too close to the release date :-( 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/

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

--- On Mon, 4/12/10, Bernie Innocenti <bernie(a)codewiz.org&gt; wrote: 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.

--- On Mon, 4/12/10, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: 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.

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

On Mon, Apr 12, 2010 at 2:04 PM, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: 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

Hi, 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 <cjb(a)laptop.org&gt; One Laptop Per Child

Hi, 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/Pa... So, I don't understand what the problem is. - Chris. -- Chris Ball <cjb(a)laptop.org&gt; One Laptop Per Child

On Sat, 2010-04-10 at 13:29 -0700, Jon Nettleton wrote: 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/

On Mon, 2010-04-12 at 23:54 +0100, Peter Robinson wrote: 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 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/

On Tue, Apr 13, 2010 at 2:31 AM, Bernie Innocenti <bernie(a)codewiz.org&gt; wrote: Not exactly. Agreed. RH updates those sort of components regularly to ensure support. 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 Nothing stopping these being fixed in RHEL/CentOS. RHEL updates this regularly as well and actively moves to the current version. I believe RHEL-5 has firefox 3.5 Mention what about it? We don't use any of the latest NM features, its stable and the maintainer actively assists and accepts patches. You are not alone, you should see my BZ queue. 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 :-) One word. PackageKit. Then its agnostic for all the distributions. 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

--- On Fri, 4/16/10, Bernie Innocenti <bernie(a)codewiz.org&gt; wrote: 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?

On Fri, Apr 16, 2010 at 9:20 PM, Bernie Innocenti <bernie(a)codewiz.org&gt; wrote: 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. 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! 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. 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. See point above. 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! 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. :-) People are slowly coming around, and I'm slowly bribing people :-D We pay for support (RHEL you need subscriptions, and that is support) but the support I refer to above is from me logging bugzilla tickets under my standard BZ account (my gmail address) so is not any different to anyone else because quite simply I've never needed to pull out the "I have paid support fix this now" ticket because it gets fixed so quickly by just logging it in BZ (recently got a bug acked and a patch posted for RHEL-4 24 hours after I posted the bug!) 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. 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. 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 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. Cheers, Peter

On Sat, Apr 17, 2010 at 2:52 AM, Bernie Innocenti <bernie(a)codewiz.org&gt; wrote: 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. 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, And there is a perfect reason for a stable distro such as RHEL or CentOS :-) Peter

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

On Sat, Apr 10, 2010 at 1:47 AM, Yioryos Asprobounitis <mavrothal(a)yahoo.com&gt; 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. -Jon

On 04/09/2010 10:27 PM, Chris Ball wrote: Congrats to this new build. I am missing the German translations. I can not select it in the language section of the control panel and /usr/share/locale/de is empty. There seem to be some more languages missing. Someone any ideas... Thanks, Simon

On 04/12/2010 06:27 PM, Chris Ball wrote: Oh, ok. Thanks for the pointer. Regards, Simon

On 12 April 2010 14:51, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: Which burnin package are you referring to? olpc-runin-tests-0.9.15-1.noarch? Thanks, Daniel

On Mon, Apr 12, 2010 at 11:10 AM, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: Yes that is the one.

On Mon, Apr 12, 2010 at 8:52 PM, Mikus Grinbergs <mikus(a)bga.com&gt; wrote: Everything helps, and this is also relevant for the XO-1. Peter

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

On Mon, Apr 12, 2010 at 2:34 PM, Daniel Drake <dsd(a)laptop.org&gt; wrote: 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

On 12 April 2010 19:13, Peter Robinson <pbrobinson(a)gmail.com&gt; wrote: 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