olpc May 2010

olpc@lists.fedoraproject.org

14 participants
22 discussions

New XO-1.5 10.2.0 build 124
by Chris Ball 14 May '10

14 May '10

http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.2.0/os124 Compressed image size: 677.10mb (-0.55mb since build 123) Description of changes in this build: * Upgrade to q3a39. * kernel: EC wakeup timer access * olpc-utils, #10152, #10158: Fix sound in totem, use totem to play videos * sugar*: Merge Bernie's work on 3G modem support for Sugar * SDL_Pango, #9994: Add SDL_Pango to build for Tuxmath activity * Pull F11 updates. Package changes since build 123: -NetworkManager-0.7.2.996-1.fc11.i586 +NetworkManager-0.7.2.997-1.fc11.i586 -NetworkManager-glib-0.7.2.996-1.fc11.i586 +NetworkManager-glib-0.7.2.997-1.fc11.i586 -NetworkManager-gnome-0.7.2.996-1.fc11.i586 +NetworkManager-gnome-0.7.2.997-1.fc11.i586 +SDL_Pango-0.1.2-10.i586 -bootfw-q3a38-1.unsigned.i386 +bootfw-q3a39-1.unsigned.i386 -elfutils-libelf-0.145-1.fc11.i586 +elfutils-libelf-0.147-1.fc11.i586 -exim-4.69-10.fc11.i586 -kernel-2.6.31_xo1.5-20100504.1641.1.olpc.7223ce6.i586 +kernel-2.6.31_xo1.5-20100505.1840.1.olpc.b072a92.i586 -kernel-firmware-2.6.31_xo1.5-20100504.1641.1.olpc.7223ce6.i586 +kernel-firmware-2.6.31_xo1.5-20100505.1840.1.olpc.b072a92.i586 -libpurple-2.6.6-2.fc11.i586 +libpurple-2.7.0-1.fc11.i586 -olpc-runin-tests-0.9.19-1.noarch +olpc-runin-tests-0.9.20-1.noarch -olpc-utils-1.0.22-1.fc11.i586 +olpc-utils-1.0.22-2.fc11.i586 -ppp-2.4.4-12.fc11.i586 +ppp-2.4.4-13.fc11.i586 -quota-3.17-6.fc11.i586 +quota-3.17-7.fc11.i586 +ssmtp-2.61-14.fc11.i586 -sugar-0.84.15-1.fc11.i586 +sugar-0.84.16-1.fc11.i586 -sugar-artwork-0.84.1-3.fc11.i586 +sugar-artwork-0.84.2-1.fc11.i586 -sugar-presence-service-0.84.0-2.fc11.noarch +sugar-presence-service-0.84.1-1.fc11.noarch +sugar-toolkit-0.84.10-1.fc11.i586 -sugar-toolkit-0.84.9-2.fc11.i586 -taglib-1.6.1-2.fc11.i586 +taglib-1.6.3-1.fc11.i586 -tzdata-2010i-1.fc11.noarch +tzdata-2010j-1.fc11.noarch -xapian-bindings-python-1.0.18-1.fc11.i586 +xapian-bindings-python-1.0.20-1.fc11.i586 -xapian-core-libs-1.0.18-1.fc11.i586 +xapian-core-libs-1.0.20-1.fc11.i586

1 0

Re: [Sugar-devel] Sugar 0.88 packages
by Bernie Innocenti 13 May '10

13 May '10

El Thu, 13-05-2010 a las 20:23 +0200, Tomeu Vizoso escribió: > This implies that we are using the old process because nobody has come > with a concrete proposal for changing it. AFAICS, the discussion has > stalled because of lack of interest from its proponents. Once we agree > on specific changes, the process docs in the wiki will be updated and > it will come into effect. Ok, you're clearly in denial :-( > And I'm supposed to track patches in the ml myself? I thought we > wanted to reduce the load on the maintainers because we had few? All the maintainers have to do is reply with: Acked-by: name <email> Then, the poster will commit the patch or find someone who will. You've probably seen this happen a few times on sugar-devel too. In other projects, the maintainer is the only person who has commit access to their tree, so they go ahead and merge the patch directly. > I have noticed that several of the patches that I have reviewed this > week could have been approved by now if somebody would have > pre-reviewed them. You're obviously disregarding the reviews done in the list. Almost every patch posted was reviewed (either successfully or not). > > iirc, you were opposed only to let any contributors approve patches for > > Sugar modules with missing or unresponsive maintainers. > > I don't understand what you mean, can you rephrase? My initial proposal to unstuck the review process was to let any existing Sugar contributor approve patches posted by others. You'll certainly remember this, because you commented that only those who are able to appreciate the maintenance burden of a patch are to decide on it. That's fine, as long as there are enough maintainers to review patches in a reasonable amount of time. If this is not the case, we could tune our requirements for becoming a maintainer so that we'll have more. There are many solutions to the problem of maintainer shortage, just pick your favorite one. Except, maybe, halting development until the planets come to the right alignment and maintainers of your liking start to fall from the sky. > How can you vote before you have a proposal? Or the proposal is "do > whatever the linux kernel does"? Would you like me to open a bug in trac and attach the proposal to it so you can review it? We've discussed the email-based review process once on IRC, in which you agreed and asked to post the proposal to sugar-devel@, then a second time on the thread following Sasha's summary. There was also a third time, on the "Patchwork" thread. In all cases, you claimed to be in favor for the general idea except for some minor points which I believe have been addressed. Tomeu, please, let's not start over from the beginning. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

1 0

Re: [Sugar-devel] Sugar 0.88 packages
by Bernie Innocenti 13 May '10

13 May '10

El Thu, 13-05-2010 a las 19:30 +0200, Tomeu Vizoso escribió: > Are your patches in this queue? > > http://bugs.sugarlabs.org/query?status=accepted&status=assigned&status=new&… > > If not, please read the code review process in the wiki and make sure > you follow it. Does this imply that we're giving up on the new email-based review process? Some maintainers have already adopted it and there seemed to be general consensus on it, except maybe for some procedural details. > Also, today I tried to review a patch of you in trac that had > bitrotten because you hadn't updated it after review on the ml. Please > make sure this doesn't happen by updating the attached patches or by > pasting a link to the thread in archives. What's the ticket number? > There's quite a bit of things that non-maintainers can do to speed up > this process, but unfortunately my last call for help was ignored. If > people really care about this, please do reviews so that when the > maintainer gets to it it can just make a quick read and set the flag > to r+. It would also helped if submitters read the code guidelines in > the first place, of course. Almost all the patches I've seen posted to the list where promptly reviewed by one or multiple people. Please, don't ask contributors to also file a bug in Trac, attach the patch and set the "r+" keyword before you can merge otherwise good patches. > Note that I'm still waiting for your replies to the comments on your > post "[PATCH 1/2] This fixes part of > http://bugs.sugarlabs.org/ticket/1876". (And again, make sure that > trac has a reference to the outcome of that review). I'll give it a look today. > > Ideally, some of the existing contributors would step up and become > > maintainers of specific modules or releases. I'm available to maintain > > the 0.88 branch unless someone else wants to and I offered to become a > > review peer for all the sugar-* modules. > > Thank you, that's a very generous offer. Why don't you start by > pre-reviewing the patches in the queue so current maintainers see you > have the required experience? That way you win twice: speed up the > queue and become a maintainer yourself. Perhaps you haven't noticed that I'm *already* pre-reviewing plenty of patches. Only, I do it on sugar-devel@, which is what we had agreed to do a few weeks ago after discussing it extensively on IRC with you. iirc, you were opposed only to let any contributors approve patches for Sugar modules with missing or unresponsive maintainers. What shall we do to resolve the current uncertainty quickly? Shall we vote the new review process with Selectricity? > > BTW: I did some testing yesterday with F11-XO1-0.88 and results are very > > encouraging. I'm seeing some issues related to font-size and window > > borders. We need to figure out why these things work well in > > sugar-emulator in 1200x900 and not on the XO-1. I tried upgrading > > Metacity, but it did not seem to help. > > Can you get some screenshots? (But please create a new thread) Ok, I'll do it when I announce the build. Maybe it will happen by this weekend. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

1 0

Sugar 0.88 packages
by Bernie Innocenti 13 May '10

13 May '10

Hello Peter & Sebastian, looks like the two of you have been effectively maintaining the Sugar packages for some time. For our next XO-1 & XO-1.5 builds, I've been back-porting the Sugar 0.88 packages to Fedora 11. As soon as we start doing some QA, we're going to apply a certain number of fixes for critical bugs that are not yet in any released source tarballs. Would you like me to go on and apply any relevant patches also to the devel and F-13 branches in CVS? Let me know if you'd rather want me to run each individual patch through you instead of committing them directly. Either way is equally fast and easy on my side. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

3 4

One family's solution to XO-1 touchpad
by Mikus Grinbergs 13 May '10

13 May '10

I've placed a couple XO-1s (one CSN748, one SHC842 - both build 802B1) with an ordinary family for use by their 5 and 6 year olds (in Texas). Those daughters had lots of trouble using the touchpad -- jumpy cursor; hard to control the cursor position; recalibration of touchpad (automatic or manual) did not last long. The family added external wireless mice. Now their daughters are very happy with the XO-1 cursor behavior. mikus

1 0

Re: Prueba de Modem 3G en imagen Py140
by Bernie Innocenti 13 May '10

13 May '10

[cc += danw, fedora-olpc] El Wed, 12-05-2010 a las 12:35 -0300, Daniel Castelo escribió: > I tested again "Onda" Modem and for my surprise worked fine. I plug in > again and didn't work. Conclusion, sometimes works and sometimes > doesn't. I'm seeing this problem as well on my laptop with Fedora 12 and 13, using various Huawei modem models. It could be a NetworkManager issue, unless all modems share the same firmware bugs. Dan, what do you think? Even if the actual problem lies elsewhere, it would help if NM could provide useful diagnostics about what went wrong. > I send to you the dmesg output in both cases. I see nothing odd here. In both cases, the mass-storage device is being switched to a communication device and 3 ttyUSB ports are configured. It's an "option" modem, like the Huawei. > > I send to you teltonika, samsung and alcatel dmesg and log/messages > output. We're missing the contents of /var/log/messages for the "Onda" modem in the non-working case. > I could sent this information to the list, but what do you think is > the best place, sugar devel or olpc devel? > Heh, good point :-) When in doubt, I usually post to all relevant lists. In this case, it's neither an OLPC nor a Sugar issue, but it may interest both. It's more likely a Fedora-OLPC issue, for which there's a specific list (already on cc). > > On Tue, May 11, 2010 at 7:03 PM, Bernie Innocenti <bernie(a)codewiz.org> > wrote: > On Mon, 2010-05-10 at 16:03 -0300, Daniel Castelo wrote: > > > Los que pude probar en la imagen py180 y no se soportan son: > > * Teltonika U3G15L > > * Samsung SGH-Z810 > > * ONDA MSA602HS > > * Alcatel X030 > > > Hmm... unfortunately I don't have any of these to test. Can > you find out > the USB vendor and product codes of these modems with "lsusb"? > > Also, can you run "dmesg >dmesg.out" a few seconds after > plugging in one > of the bad ones and send me the output? > > If something appears in /dev/ttyUSB*, then it means that > usb_modeswitch > did its magic and the problem is in NetworkManager. If > so, /var/log/messages would help determine what's wrong. > > (let's move this thread to the sugar-devel list, so other > people can > participate) > > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > > > > > -- > Ing. Daniel Castelo > Plan Ceibal - Área Técnica > Avda. Italia 6201 > Montevideo - Uruguay. > Tel.: 601.57.73 Interno 2228 > E-mail : dcastelo(a)plan.ceibal.edu.uy -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/

1 0

alsa issue
by Yioryos Asprobounitis 07 May '10

07 May '10

Does anyone has an idea what this dmesg might mean? "[ 554.236469] cs5535audio 0000:00:0f.3: setting latency timer to 64 [ 554.243623] Failure reading codec reg 0x7e,Last value=0x7e805368 [ 554.249827] Failure reading codec reg 0x7e,Last value=0x7e805368" This shows up during alsaconf in Puppy linux on the XO-1, and although alsaconf finishes without errors there is no sound or card detected by the mixer at the end. More info is available but I'm afraid I might be a bit off the focus of this list. So if this rings a bell pls let me know, if not...

1 0

New XO-1.5 10.2.0 build 123
by Chris Ball 05 May '10

05 May '10

http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.2.0/os123 Compressed image size: 677.65mb (-13.75mb since build 202) Description of changes in this build: * Update to Q3A38. * olpc-runin-tests: Launch problem fix from rsmith. * kernel: enable user-level access to EC permanent timer * Pull F11 updates. Package changes since build 202: -coreutils-7.2-7.fc11.i586 +coreutils-7.2-8.fc11.i586 +elfutils-libelf-0.145-1.fc11.i586 -elfutils-libelf-0.146-1.fc11.i586 -kernel-2.6.31_xo1.5-20100430.1441.1.olpc.6a2d568.i586 +kernel-2.6.31_xo1.5-20100504.1641.1.olpc.7223ce6.i586 -kernel-firmware-2.6.31_xo1.5-20100430.1441.1.olpc.6a2d568.i586 +kernel-firmware-2.6.31_xo1.5-20100504.1641.1.olpc.7223ce6.i586 -olpc-runin-tests-0.9.18-1.noarch +olpc-runin-tests-0.9.19-1.noarch -tar-1.22-5.fc11.i586 +tar-1.22-6.fc11.i586

1 0

F11-for-XO1.5 Release 10.1.1 Release Candidate 1
by Chris Ball 03 May '10

03 May '10

http://wiki.laptop.org/go/F11_for_1.5 http://build.laptop.org/10.1.1/os202 Compressed image size: 691.40mb (+13.72mb since build 122) Hi everyone, We're closing in on our next release for manufacturing, which will be called "10.1.1". Please test this XO-1.5 release and report back any bugs using the bugtracker at <http://dev.laptop.org/1.5>. This signed release is based on os122, plus the following: * update to Q3A38 * olpc-powerd: fix a network idleness detection bug * close F11 updates and switch to static repos on mock.laptop.org -- this marks the start of manual change control. Package changes since build 122: -bootfw-q3a37-1.unsigned.i386 +bootfw-q3a38-1.unsigned.i386 -olpc-powerd-20-1.fc11.i586 +olpc-powerd-21-1.fc11.i586

1 0

Record-76 in os122
by Mikus Grinbergs 03 May '10

03 May '10

Disclaimer: I am not asking for help; I am sharing my experience. Tried Record-76 with os122 -- it appears to record correctly, and plays back correctly within Record-76. Photo panel - I'm satisfied with this capability. Now the screen image when the XO-1.5 is indoors looks acceptably bright. Video panel - recording/playback within Record-76 worked. Synchronization of picture & sound was correct. Was able to play back video clip with Browse - but picture was only thumbnail size. Etoys appeared to open the video clip as text - perhaps a problem with etoys. [Helix called as a choice from the palette on the Journal entry for the video clip failed to open the URL - perhaps I have an obsolete version of helix, for which the parameters_passed_on_invocation_from_Journal do not work correctly). Audio panel - recording/playback within Record-76 worked. Could play back the audio clip using Browse or Helix. Etoys could not open the audio clip - perhaps a problem with etoys. mikus

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

olpc May 2010