OLPC News 2007-11-17
1. Nationwide: This week we launched Give One Get One (See laptopgiving.org). eBay reports the fastest ramp-up they have ever seen. 2. Changshu: Richard Smith and Gary Chiang found the root cause of many if not all of our hardware suspend/resume problems. They were caused unexpected interrupts being generated by the embedded controller (EC) just as the laptop was going to sleep; the problem can be corrected with a firmware upgrade. We will continue to test to ensure that we can suspend and resume for a million cycles. This development ends a four-month struggle to identify and fix major problems associated with suspend and resume. 3. Mass Production: We had a glorious end to a near sleepless few weeks for many. On Friday, we made a firmware fix to arguably our most troublesome blocker bug. This suspend/resume bug could have limited our battery life (between charges) when using collaborative applications and mesh (details below). Thanks to all who helped from OLPC, Quanta, Red Hat, AMD, plus many individual contributors; special thanks to Richard Smith, John Watlington, Gary Chaing, and Mary Lou Jepsen. The Pentagram designed OLPC boxes, both the five-pack and single-pack look great, and are in stark contrast to all the other boxes in the factory. 4. Firmware: Mitch Bradley fixed some bugs in the OFW JFFS2 driver. They impact olpc-update, so we will need a new firmware release—Q2D05—for the update. Mitch also installed the school-server software and did some OFW network update testing. There is an issue with the way that OFW associates with the mesh—currently OFW-based updates only work with infrastructure mode. He sorted out some issues surrounding keyboard tags in manufacturing data and specified a new SK manufacturing data tag to report the SKU number. This will let us identify G1G1 machines in the data we get back from Quanta, so we can generate developer keys for those machines. 5. Schedules: Many thanks to C. Scott Ananian who has led the team to get to build a new in-house build system; as a result, we have a better handle on the process, repeatability, and tracing to source files. Some issues such as security and mesh sharing are taking longer than expected to stabilize, so we are evaluating the impact on the Update.1 release schedule. 6. Testing: Dafydd Harries and Robert McQueen from Collabra visited OLPC's Cambridge office for a week of larger-scale mesh testing and debugging; lots of good progress was made. David Woodhouse was also in town, working with Marvell, CozyBit, Ricardo Carrano, Marcelo Tosatti, and Michail Bletsas to help debug Ticket 4470 (WLAN hang). We have a much better understanding of this bug (See below) and hope to begin testing a work around soon. Simon Schampijer spent a number of hours at the local Starbuck's testing various browser versions and settings with T-Mobile service. He has narrowed down some slow response issues to a specific version of our browser and is working with both Mozilla and T-Mobile to get to the root cause. Alex Latham spent another week in suspend/resume testing as well as latest-build tests and various combinations of OS and kernel to help identify problem areas. Ricardo is working on a test bed to recreate Ticket 1863 (the LazyWDS bug) and help understand association problems with various access points (Linksys mostly). He has also provided data related to the amount of beaconing traffic from XOs. 7. Suspend/resume: As mentioned above, Richard Smith and Gary Chaing solved the mystery of our suspend and resume problems (Ticket 1835) that were bedeviling us in the factory. A well placed SCI just before MAIN_ON goes low (i.e., during the suspend code) hangs the system. The (primary) source of this SCI is from an wake up event generated by traffic from one of the PS2 devices. The wonderful news is that this is a firmware problem with the embedded controller, so our hardware manufactured to date will work correctly once the firmware is upgraded. A test bed of 41 laptops executed over 20,000 cycles without a single 1835 error. 8. Sugar/activities: Simon Schampijer worked with Michael Stone on Rainbow integration for the Browse activity and with Bernie Innocenti on a change in the X11 symbol tables that caused the View Source key to stop working. Bernie has requested to revert this change upstream. Another bug was fixed in the full-screen mode. Tomeu Vizoso fixed some bugs in the DataStore related to security, USB sticks, and activity custom metadata properties. He also helped to track down some bugs in Browse related to downloads and bugs in the Journal in regard to bundle installation, updating of relative dates in the list view and usability of the search entry. Reinier Herres has been working on the Calculate activity. It can now parse Unicode, thus its internationalization is somewhat improved. Reinier also wrote a patch to enable exit from full-screen in the the Browse activity. He also wrote a patch to display those activities where a
New joyride build 299
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build299/ -olpc-utils.i386 0:0.44-1.olpc2 +olpc-utils.i386 0:0.45-2.olpc2 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: JFFS2 file sizes
On Thu, 26 July 2007 08:37:26 +0100, David Woodhouse wrote: On Wed, 2007-07-25 at 20:04 -0400, Jim Gettys wrote: Jffs2's compression is OK, but as the block size of the compression blocks is relatively smaller than a gzipped archive, for large objects it's less efficient than gzip. The same is true even more dramatically for bzip2. .bz2 images are usually smaller than .gz images. But when compressing only 4k chunks, bzip2 almost always fares worse than gzip. Dave Woodhouse may be able to give typical numbers (he wrote jffs2, and we're fortunate to have him working on OLPC).. And individually gzipped small files may not do much better than jffs2. You could use 'mkfs.jffs2' to spit out a JFFS2 image matching any given directory, which should give a fairly good estimate of size. As discussed on IRC last night, it's something like 68 bytes for every 4KiB page, plus the zlib-compressed size of that page. ...aligned to a 4-byte boundary. One of the improvements we want to make to JFFS2 is switching to 16KiB 'pages'. It means a bit of mucking around with the Linux page cache, since we're no longer keeping data in chunks of precisely the same size it'll be wanted in. But it should give us better compression and also speed up mounting and take a lot less RAM for metadata (since we'll have ¼ the nodes to keep track of.) Compression should improve by 2-5% if my memory can be trusted. Has been a while since I did the tests. Jörn -- Public Domain - Free as in Beer General Public - Free as in Speech BSD License- Free as in Enterprise Shared Source - Free as in Work will make you... ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Hello all, Thank you for your emails. 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. I have opened the following ticket . See here - http://dev.laptop.org/ticket/2800 I have not assigned the ticket to any one nor set a time line for it as of now. Please feel free to set those. 2) Output Analog/Digital: The USB is an interesting idea as I had discussed with Mitch. I could simply make a board using a USB to parallel kind of a chip. I will be getting down to doing something similar shortly. Anybody would suggest to explore audio out for a similar purpose ? 3) Other ideas for sensor input : Mitch and Wad had suggested regarding exploring some basic medical applications using the Analog Input port. For example maybe be able to measure pulse rate ... I am quite excited about these ideas and plan to think about things to do on these lines too. Any initial suggestions ? regards, Arjun On 8/11/07, Mitch Bradley [EMAIL PROTECTED] wrote: Hal Murray wrote: - some parallel port (or similar) should be made available, for children to play with in physics. I remember playing with a PC parallel port with some simple software to turn leds on and off. When you are a kid, being able to send commands to projects you create is great (think about modern legos, but using simpler stuff like leds, motors, etc) : it translate the virtual part ie the software you create on the computer to the real world where you make leds blinks in sequence, or a motor move. ... There are USB connectors. ... USB to printer port adapters are also available. I've never played with one. Prices are under $40. There are also things like this with 24 GPIO lines. USBIO24R http://www.elexol.com/ US distributor: http://www.orteches.com/ $75 ... There is also the microphone input and audio output for A/D and D/A. I think the XO hardware supports a DC coupled mode. We should work on a collection of hacks to demonstrate how they work and a list of which ones are known to work. OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost gadgets to plug into the mic port - temperature sensor, intrusion detector, etc. He plans to document them and set up a framework for documenting other similar hacks. We also talked about an OLPC digital gadget prototyping dongle with a USB-equipped microcontroller like those available from, for example, Atmel. Those chips cost a dollar or two and Arjun can get all the other parts really inexpensively in India where he lives. -- Arjun Sarwal One Laptop Per Child [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
FWIW, yesterday I setup LANG=am_ET.UTF-8 in /etc/sysconfig/i18n and rebooted. Sugar was not even able to start (I am using the latest stable image). Pure X server starts ok. There were errors during the boot process as well (some services reported FAILED startup). If anyone is interested, I could provide more details. So I had to fallback to en_US.UTF-8. It seems it will take some preparation to get to the stage when we could actually perform real (not fake) test of the Ethiopian keyboard input in Ethiopian locale. Sergey On 8/23/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: Sergey Udaltsov wrote: When you replace simplified fonts with the full version: are you able to input Ethiopean with the code provided? I assumed it would, but now I installed the dejavu-fonts RPM and the Ethiopean glyphs still don't display neither in the Write activity, nor in the Web activity. On my F7 box, there must be some fontconfig magic that makes them work. But I couldn't figure out how. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
Bernardo, Would you try the Ethiopian XIM in en_US locale (replacing Compose file)? Sergey On 8/24/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: Sergey Udaltsov wrote: FWIW, yesterday I setup LANG=am_ET.UTF-8 in /etc/sysconfig/i18n and rebooted. Sugar was not even able to start (I am using the latest stable image). Pure X server starts ok. There were errors during the boot process as well (some services reported FAILED startup). If anyone is interested, I could provide more details. The same happened to me too. Seems like a severe bug in glibc's locale description. For example, the sort comand would output lines sorted by length instead of alphabetically! I'll try again with fedora devel's RPM. If it doesn't work, then I guess we should file a bug upstream. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: More 16 vs 24 bpp profiling
On 09/11/2007 01:32 PM, Bernardo Innocenti wrote: The 16bpp codepath has to be broken somewhere if it takes twice the time to copy half the bits :-) It strikes me that we don't see any time spent in pixman_fill_mmx(), even though it's not inlinable. For some reason, pixman thinks it cannot accelerate 16bpp fills with MMX, at least on the Geode. Might be worth investigating... -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Fwd: Status of Ethiopian support]
My uninformed guess would be that 2 would be best. But I'm forwarding your question to Lidet for a reliable opinion. It that case, my Compose file would have to be swapped (the left part of the rules). No problem, once we make that decision. My guess is that the GTK IM has additional usability refinements. That's ok. The main thing is that it should not have _different_ rules. I thought IM's would work with raw keycodes (positional), not keysyms translated through the current keyboard layout. Apparently you are kind of wrong;) general. I'm merely trying to coordinate the integration without a specific technical background. You are doing fine. We all learn things as we go:) No need to apologize. Cheers Sergey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LANG=am_ET causes funny collating order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernardo Innocenti wrote: I also tried the latest F8 glibc package, Define latest. It should work in 2.6.90-17. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHBwye2ijCOnn/RHQRAtaYAJ4sTTj4h/CPD9vpxdMbVqHBhTzn4gCgoYhJ aNekBq094JSCVP2LpceF8Aw= =oxhz -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Journal and Tubes Minutes from 9/18/07
Le mardi 18 septembre 2007 à 21:41 +0200, J.M. Maurer a écrit : * Bug 2463, when the initiator of a shared activity leaves, others can no longer join, even though it looks like they can from the neighborhood mesh view. * If we had fully understood this bug earlier, it would have been good to shut down the activity when the initiator left, and then figure out a better solution for FRS. The way it works now is just really confusing and will cause complaints and support calls. The longer term solution needs to allow another laptop to advertise the shared activity if the first one leaves. Ah, so then I can't test this one https://dev.laptop.org/ticket/3445 in sugar while implementing support for it in AbiCollab, is that correct? Saves me a lot of time knowing that :) Yes and No. #2463 is only when using Salut (link-local), there is no problem with Gabble as there is a server where the muc is stored. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: new FRS blocker 4418 - no sound in tamtam
It would appear that nothing's able to play sounds; see my latest followup: https://dev.laptop.org/ticket/4418 On Tue, 23 Oct 2007 22:23:23 -0400 Walter Bender [EMAIL PROTECTED] wrote: Is pippy able to play sounds? -walter On 10/23/07, Andres Salomon [EMAIL PROTECTED] wrote: On Wed, 24 Oct 2007 02:54:56 +0200 Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On 10/24/07, Andres Salomon [EMAIL PROTECTED] wrote: I've noticed this as well; note that the MIC LED comes on *after* X starts, while sugar is being initialized. We also see the following message on the console: [ 91.166430] snd-malloc: invalid device type 0 I'm not sure what userspace is doing yet to trigger that, but if the sugar folks could isolate it, that'd be helpful. Strace FTW? I suspect the sugar startup sound because it went on git master and not on the trial-3 branch. I'm unable to test on a XO right now but it should be easy to verify by deleting the sound file: /usr/share/sugar/data/startup.flac Marco Well, the sugar startup sound is what's triggering it (moving startup.flac out of the way causes the MIC LED to not come on).. However, tamtam still appears to be broken (and the MIC LED comes on when we start tamtam). ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
The feature, although not usable by the activities, it has other benefits. By observing the buddy list, you acquire instant information of the network connection go the users: when connected to channel 1 for example: 169.254.x.x address are in link-local 172.18.x.x are connected to schoolserver when connected to a jabber server: 169.254.x.x are connected through an MPP 18x.x.x are media lab 172.18.x.x are connected to schoolserver in olpc etc It is information continuously used in network testing, also useful from the users prespective: 1. in the case of connecting to multiple jabber servers, the user should be able to tell which XO in the neighbout view belongs to the same school 2. get the geopraphical location of another user In future versions of the neighbor view, or through other activities, the user should be able to filter for specific XOs according to location, or school(in the case he's connected to many servers). Two children in the same school should be able to recognize each other even if they are connected through a jabber server, other then the one in the school. It can also be useful for locating an XO in case of theft. I have also added a ticket(4405) for adding the public id in the buddy list properties. It is a small part of data(both IPs, private and public), which can be harmfully incorporated in the telepathy services. Please let me know if you agree, yani On 10/25/07, Jim Gettys [EMAIL PROTECTED] wrote: It seems, from your discussion like unless someone grumbles today, this should be removed immediately. And it removed within a week, even if someone grumbles... - Jim On Thu, 2007-10-25 at 10:15 +0100, Simon McVittie wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 We still have one set of OLPC-specific patches to Salut (the link-local collaboration backend) that has been rejected upstream, which is the one that adds support for the deprecated ip4-address buddy property. This was used during a transitional period to enable simple TCP-based collaboration for activities that didn't use Tubes; Sjoerd is reluctant to keep this patch set, because it's meant to have gone away by now! Is anyone still using this property? If not, can we kill it? It was added in Trial-2, and it was meant to be gone by Trial-3 but was left in just in case, so it really ought to disappear. When it does, we can delete some code from Salut and Presence Service. Places it's exposed in the APIs, which I propose to get rid of: PS D-Bus API: Buddy.GetProperties() returns a dict that contains ip4-address: 10.0.0.1 (or whatever), and Buddy.PropertyChanged signal includes a dict that can contain the same sugar.presence: Buddy has a GLib property ip4-address (aka buddy.props.ip4_address) and can emit it in its property-changed signal The Read activity appears to be the only thing in my jhbuild that uses ip4-address (#4297). It should be ported to either stream tubes (when they're ready in Salut, which should be this or next week) or D-Bus tubes (now). Gabble already supports stream tubes, so stream-tube support can be implemented on a branch and tested against Gabble. Porting from plain TCP to stream tubes should be very straightforward; I hope to produce a proof-of-concept patch for Read later today. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHIF7HWSc8zVUw7HYRAvp6AJ9G/Xiw27pPPMm0g02vhXzRhzUxqwCfW27Z nh1B/wqe7GD/xf/YaOPVaw8= =42L7 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: log-collect / log-send
Pascal, I have been working on something similar. It is a console script that gather networks related logs, and will be available in the next joyride. At the moment it includes: var/log/messages var/log/xorg.0.log /home/olpc.sugar.logs/presenceservice /home/olpc.sugar.logs/gabble /home/olpc.sugar.logs/salut and the following info: build firmware model time mac ips of all interfaces network topology jabber server salut or gabble The gzipped tar is ~20kb which is pretty low. However, other tests(for specific activites for ex.) will require other logs. I believe that a complete log activity should have a list of options like: network logs kernel logs activities logs all logs ...so the user can choose according to the problem also, the activity should be able to enable All Logs, from the .xinitrc, .sugar.debug files, or perhaps the full kernel logs. I was planning to add the above features in my script, but a sugar activity is better than a console script. Since we are working on the same thing we can use each other's help, and create a single application. yani On 10/29/07, Pascal Scheffers [EMAIL PROTECTED] wrote: I've created a rough-cut log-collector, it's in d.l.o/git/project/log- activity/log-collect.py For now, it just outputs some system info, tell me what's missing or what would be interesting to include? I don't know yet how to list installed activities... would that be just `ls /usr/share/activities/`? Or is there a package list? And then the main purpose: sending logs to OLPC, either using http- post or email or usb-stick or... but what logs should I collect? Just all of them? ~/.sugar/default/logs/* and /var/log/* ? Or should it be more selective? And some information from the journal, perhaps? What about privacy/sensitive information? Will there be any in the logs or system info? - Pascal Current log-activity.py output: bios-version: Q2C18 uptime: 434169.21 430235.72 wireless_mac: 00-17-C4-05-2A-58 uuid: 8A401F4E-E312-47F9-96C8-A488C99BDA2F localization: ?? kernel_version: Linux version 2.6.22-20071018.1.olpc.d4414541d2be66a ([EMAIL PROTECTED]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 PREEMPT Thu Oct 18 11:44:14 EDT 2007 diskfree: 716 MB laptop-info-version: 0.1 memfree: 63496 kB serial-number: SHF7250025C disksize: 1024 MB keyboard: ??-??-?? olpc_build: OLPC build joyride 58 (stream joyride; variant devel_jffs2) country: USA board-revision: B4 motherboard-number: QTFLCA72400063 POWER_SUPPLY_NAME=olpc-battery POWER_SUPPLY_TYPE=Battery POWER_SUPPLY_STATUS=Full POWER_SUPPLY_PRESENT=1 POWER_SUPPLY_HEALTH=Good POWER_SUPPLY_TECHNOLOGY=LiFe POWER_SUPPLY_VOLTAGE_AVG=6792960 POWER_SUPPLY_CURRENT_AVG=0 POWER_SUPPLY_CAPACITY=97 POWER_SUPPLY_CAPACITY_LEVEL=Full POWER_SUPPLY_TEMP=2508 POWER_SUPPLY_TEMP_AMBIENT=4300 POWER_SUPPLY_ACCUM_CURRENT=8390 POWER_SUPPLY_MANUFACTURER=BYD POWER_SUPPLY_SERIAL_NUMBER=5d0d0100daff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] Retry frame transmission when libertas driver is busy.
On Fri, 02 Nov 2007 12:54:35 -0700 (PDT) Ashish Shukla [EMAIL PROTECTED] wrote: The driver silently discards frames when some command is pending -- returns NETDEV_TX_OK to kernel. The following patch fixes this problem. This significantly improves file transfers while scanning (ticket #3341). Signed-off-by: Javier Cardona [EMAIL PROTECTED] So, uh.. This patch is from Javier, but was originally written by Ashish? Did I get the attribution right? :) Is this simply a workaround to make the driver more reliable with the (broken) p0 firmware, or is it an actual fix (ie, is the proper behavior to be returning NETDEV_TX_BUSY rather than dropping packets)? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
RE: MP Build... FYI
Actually, I had asked our test engineer in CSMC to prepare 625 for the factory suspend/resume test tomorrow. They are doing this right now. It means we should have both 624 and 625 test image to be ready tomorrow. We can make decision which image we want to use in the factory suspend/resume test after we confirm the test result of the 4 machines that were failed with DCON problem before. Best Regards, Arnold Kao Quanta Computer Inc. Tel : 886-3-327-2345 EXT:18958 Fax : 886-3-328-9780 -Original Message- From: Richard Smith [mailto:[EMAIL PROTECTED] On Behalf Of Richard A. Smith Sent: Sunday, November 04, 2007 1:46 PM To: John Watlington Cc: Kim Quirk; Jim Gettys; Arnold Kao (高顯宗); Mary Lou Jepsen; devel; Andres Salomon Subject: Re: MP Build... FYI John Watlington wrote: Quanta wants assurance that the software workaround which was broken in #4479 is fixed. Richard's testing is necessary to confirm this. It is also essential that the kernel fix which is theoretically the only difference between 624 and 625 be part of the production test code to further confirm this. If Quanta sees this problem AT ALL in the production testing, there will be pressure to halt until further hardware/software fixes are found. I'm getting a slightly different story. I was trying to meet with people yesterday to discuss the whole mfg testing procedure so I knew what was going on and what I would need to do to get the new kernel into the Run-In image. Arnold tells me that he thinks its too late to get the DCON workaround kernel into the Run-In image. He suggestion was that if we see a DCON problem that we pull the machine out of the rack, update the kernel and then re-add it back into the testing. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MP Build... FYI
On Sun, 04 Nov 2007 10:55:05 -0500 Jim Gettys [EMAIL PROTECTED] wrote: I'm still confused/concerned In particular, I have memories of a change for manufacturing test to cause the systems to wake up on multi-cast, to enable the mass suspend/resume testing of units. It went into 624 and 625. The DCON power cycle thing is in all builds, but the proper register init path is only in 625. Andres, did this ever go by chance into the 62x series of builds (as opposed to being a separate kernel RPM? If so, at which build did it go in? My understanding of the situation is: 623 - last fully tested MP build 624 - first attempt at DCON power cycle hammer code, missing a case. 625 - most recent build, only intended for manufacturing test and burn-in, with working DCON power cycle hammer code. - Jim On Sun, 2007-11-04 at 02:27 -0500, Mary Lou Jepsen wrote: thanks arnold. - Mary Lou On Sun, 2007-11-04 at 14:40 +0800, [EMAIL PROTECTED] wrote: Actually, I had asked our test engineer in CSMC to prepare 625 for the factory suspend/resume test tomorrow. They are doing this right now. It means we should have both 624 and 625 test image to be ready tomorrow. We can make decision which image we want to use in the factory suspend/resume test after we confirm the test result of the 4 machines that were failed with DCON problem before. Best Regards, Arnold Kao Quanta Computer Inc. Tel : 886-3-327-2345 EXT:18958 Fax : 886-3-328-9780 -Original Message- From: Richard Smith [mailto:[EMAIL PROTECTED] On Behalf Of Richard A. Smith Sent: Sunday, November 04, 2007 1:46 PM To: John Watlington Cc: Kim Quirk; Jim Gettys; Arnold Kao (高顯宗); Mary Lou Jepsen; devel; Andres Salomon Subject: Re: MP Build... FYI John Watlington wrote: Quanta wants assurance that the software workaround which was broken in #4479 is fixed. Richard's testing is necessary to confirm this. It is also essential that the kernel fix which is theoretically the only difference between 624 and 625 be part of the production test code to further confirm this. If Quanta sees this problem AT ALL in the production testing, there will be pressure to halt until further hardware/software fixes are found. I'm getting a slightly different story. I was trying to meet with people yesterday to discuss the whole mfg testing procedure so I knew what was going on and what I would need to do to get the new kernel into the Run-In image. Arnold tells me that he thinks its too late to get the DCON workaround kernel into the Run-In image. He suggestion was that if we see a DCON problem that we pull the machine out of the rack, update the kernel and then re-add it back into the testing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: MP Build... FYI
On Sun, 04 Nov 2007 14:06:57 -0500 Chris Ball [EMAIL PROTECTED] wrote: Hi, I'm still confused/concerned In particular, I have memories of a change for manufacturing test to cause the systems to wake up on multi-cast, to enable the mass suspend/resume testing of units. Andres, did this ever go by chance into the 62x series of builds (as opposed to being a separate kernel RPM? If so, at which build did it go in? There's been a miscommunication: while the ChangeLog for 624 says * libertas wake on network data (whatever that means), such a patch was not in the build. The only difference between 623-624 was one patch that modified the DCON, and the only difference between 624-625 was another single DCON patch. Jim's description of each build is correct. Sigh. Looks like the wrong kernels ended up the builds. The main differences between them are the wake-on-broadcast patch, and some additional delays in the dcon workaround code. Hopefully that shouldn't make a difference... The wake on broadcast patch went into a mfgtest kernel branch so that it could be used independently by Quanta (since it is not appropriate for a release). The 6xx builds use the trial-3 series of kernels, which did not see this patch. - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
Simon, I think the email i send you is incomplete, my connection was poor and gmail must have saved the wrong draft. But, 1-2-3, is what i intended to send you. I also meant to ask, How many times do you try _init_connection before you assume the connection is down? I hope so. I have a tarball with the patch, but I'm still waiting for Update.1 approval (it's unclear whether I can build RPMs for Joyride before I get Update.1 approval or not). If you're at 1CC, could you please annoy the ApprovalForUpdate people in person until they either look at their bugs, or confirm whether I'm still allowed to build RPMs in Koji? I can definitely try to arrange this. But, can you please send me the tarball to test it in the mean time? 2. We need to be able to restart PS. As you say this is not possible, but if we restart sugar will PS restart as well? Yes, that's right (the D-Bus session bus will exit, which causes D-Bus services like PS to exit too unless they've specifically asked not to). I see you assigned the bug about need to be able to cope with PS restarts to yourself. Unless you're planning to implement the necessary Python code in sugar.presence yourself, please don't. I don't think it's feasible to implement correct handling of PS restarts in sugar.presence for Update.1, so unless the release engineering team specifically tell me to, I won't be addressing that bug until a later release. Ok, i will reassign the bug to presenceservice. As long as restarting sugar works, we can stick to that for now. 3. We need to force gabble to run. We have several instances of 4193 (almost all XOs connected to schoolserver,AP are running salut). Or at least to force trying to connect to jabber server. Please see my comments on #4193 regarding steps to take to debug (I think it's #4193 I commented on - I can't remember bug numbers, and Trac is down at the moment). In summary: * try resolving the server with getent hosts jabber.laptop.org * try pinging it with ping jabber.laptop.org * try connecting via TCP with telnet jabber.laptop.org 5222 (type hello and press Enter, if all goes well you should get disconnected with an error message that mentions XML not well formed) The bug is indeed 4193. I have replied to your post, but as the trac is down you probably havent seen it. I made all three tests: $getent hosts jabber.laptop.org 2001:4830:2446:ff00:201:6cff:fe07:68ec jabber.laptop.org - frequent reply 18.85.46.41 jabber.laptop.org --rare reply $ping jabber.laptop.org PING jabber.laptop.org (18.85.46.41) 56(84) bytes of data. 64 bytes from jabber.laptop.org (18.85.46.41): icmp_seq=1 ttl=63 time= 67.4 ms ... $telnet jabber.laptop.org 5222 blabla... connected hello replied with an xml packet with xml-not-well-formed included so it seems that it is a PS issue. Perhaps it is not waiting long enough, or doesnt make enough tries when trying to connect. I have reassigned the bug to presenceservice. If any of these steps fail, Gabble won't be able to connect either, and there's nothing Gabble can do about it - talk to the Network Manager maintainer instead, since that's the component responsible for getting network connectivity and DNS on the XO. If you check the Gabble log you'll probably find that Gabble is trying to connect, but failing because either it can't resolve jabber.laptop.org in DNS, or it can't get a TCP connection there. That was my diagnosis of two of the cases you mentioned in your bug with 3 sets of logs (which may have been #4193?). In the third case it looked as though you hadn't waited long enough for the log to indicate success or failure. 4. The process of trying to connect to the jabber server, is done by telepathy-gabble, or by the presence What I meant here is, Does the PS check if jabber server is accessible, and then runs telepathy-gabble?, or this is one of the tasks of telepathy-gabble?, which as I see you replied to Depends what you mean. The Presence Service is responsible for choosing when to try to connect (at which time it calls the Connect() D-Bus method on Gabble), but it's Gabble that actually opens a TCP socket to the Jabber server and tries to talk to it. You can see this in the PS log, for instance: 1194431620.966651 DEBUG s-p-s.telepathy_plugin: ServerPlugin object at 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0): connecting... 1194431620.967008 DEBUG s-p-s.telepathy_plugin: ServerPlugin object at 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0): Connect() succeeded (note that Connect() succeeded is a bit misleading - it just means that the connection manager has said OK, I'll try, rather than that it has actually been able to connect.) In the telepathy-gabble log you'll then see something like this: ** (telepathy-gabble:25330): DEBUG: do_connect: calling lm_connection_open Going to connect to olpc.collabora.co.uk
Re: update script
On Wed, 07 Nov 2007 18:59:54 -0500 Bernardo Innocenti [EMAIL PROTECTED] wrote: Hello Bert, could you change the diff format to something like side-by-side or unified? The default confuses e-mail clients because it looks like quoting. +1 on diff -u.. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: When will be CVS replaced by modern version control system?
On Fri, Nov 09, 2007 at 10:52:30AM +0100, Karel Zak wrote: And sure it is not very convenient for developpers, because developpers typically do not want to think about this stuff and would be happy to have their IDE directly plugged into production or user systems. But that's basic maintenance discipline that makes everyone else's life easier. I think the best way (for Fedora project) is Tom Mraz's suggestion: use stupid central CVS as a storage for patch files and locally use scripts that convert these patches as code to/from real DVCS. I've been doing something like that, but only for the packaging (i.e. no exploded trees.) I have a local CVS-git conversion of the Fedora CVS tree which I use for things like: 1. Being able to quickly see the history of a package and changes between packaging in different versions of that package without having to go through the CVS server (which is on another continent than the one I am on -- I guess the latency from the US is probably not too bad.) 2. Visualising branches with gitk, to make it easier to see where F-7/F-8 branches have forked off from devel, etc. 3. Maintaining trivial patches for the ARM port such as the one in BZ#245441 (when a new upstream release comes out, just run 'git pull' and be done.) 4. Maintaining not-so-trivial patches, such as patches to make packages build cross, or patches to make packages build with uClibc instead of glibc. There are a number of observations to be made about keeping local changes to packages: - For patches in category (3), you could argue that these should just be merged upstream, and that would remove the need to make maintainance of separate patches easier. The truth is that they aren't always merged quickly, and giving arch teams unrestricted CVS access only solves part of the problem (e.g. what if you want to commit a patch that solves an issue but you're not sure whether the maintainer will like it, but he isn't responding -- you'll still have to maintain the patches separately somehow for some time.) - Also, the patches in category (4) are unlikely to be merged into Fedora any time soon, and the We can stick with CVS because we don't have to make life easier for forks because those people should just be working on upstream Fedora instead argument doesn't really apply, because we have enough local changes that you wouldn't even _want_ to have in Fedora. ;-) - Besides, the existence of OLPC-2 branches for various packages suggests that we _do_ want to accommodate forks to a limited extent. Note that in a distributed VCS, the OLPC-2 specific stuff wouldn't have to live on the main Fedora VCS server, and could very easily live on a separate box. (Whether this is desirable for the OLPC-2 stuff or not is a separate issue, I'm just saying that it is easily possible in a DVCS.) (And whether the result can still be called Fedora or not is also a separate issue.) - [ Also, putting our cross/uClibc patches in a VCS that understands branches makes it easier for us to keep those sets of patches on different branches, i.e. keep them separate, and only merge them the moment you want to build a package. ] If you have a need to maintain local changes to packages, IMHO you're _much_ better off if you keep them in a VCS that is connected to the upstream Fedora VCS in some sense. I _could_ just have checked out Fedora CVS, committed that into my own CVS tree, and started hacking on that, but then I would just be making life a lot harder for myself, as that would make pulling in new upstream changes hell, and would probably lead to a permanent fork. As an example, Fedora's rpm packaging looks somewhat like this in gitweb: http://git.wantstofly.org/?p=fedora/rpm.git;a=summary The tags in the upper half correspond with tags in CVS. The heads on the bottom correspond with each of the branches in CVS -- note how that in the git conversion, different branches live in one repository, and are merely different versions of the same thing, instead of living in separate subdirectories in the same module. To see the individual commits, click on 'shortlog' next to the branch name (under 'heads'.) In gitk, it ends up looking something like this: http://www.wantstofly.org/~buytenh/fedora-git-rpm.png Note that it is really easy to see: - where F-7/F-8 forked off from devel - whether there have been patches applied to F-7 or F-8 that haven't been committed to devel yet or vice versa - etc. Two more examples (gcc and glibc) are here: http://git.wantstofly.org/?p=fedora/gcc.git;a=summary http://git.wantstofly.org/?p=fedora/glibc.git;a=summary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: wireless troubles, part 1: unencrypted AP
Hi Pascal, Have you tried a single click with a USB mouse (instead of the touchpad). There is an issue right now on the touch pad. -- Ricardo Carrano -- Original Message --- From: Pascal Scheffers [EMAIL PROTECTED] To: devel@lists.laptop.org Sent: Mon, 12 Nov 2007 20:34:28 +0100 Subject: wireless troubles, part 1: unencrypted AP I installed joyride-258 on my B4 with firmware Q2D04, and my wireless doesn't function anymore. Problem 1: I cannot connect to my completely open, unencrypted access point 'XO'. The AP is a Linksys BEFW11S4, other computers can and will connect to it. I double click the AP in the neighborhood and then see in /var/log/ messages: Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) started... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0/ wireless): access point 'xo' is unencrypted, no key needed. Nov 12 17:58:41 localhost NetworkManager: info Deactivating device eth0. Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0): cancelling... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) cancellation handler scheduled... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0): waiting for device to cancel activation. Nov 12 17:58:41 localhost NetworkManager: info SUP: sending command 'INTERFACE_ADD eth0 wext/var/run/wpa_supplicant ' Nov 12 17:58:41 localhost kernel: [ 111.044167] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Nov 12 17:58:41 localhost NetworkManager: info SUP: response was 'OK' Nov 12 17:58:41 localhost NetworkManager: info SUP: sending command 'AP_SCAN 1' Nov 12 17:58:41 localhost NetworkManager: info SUP: response was 'OK' Nov 12 17:58:41 localhost NetworkManager: info SUP: sending command 'ADD_NETWORK' Nov 12 17:58:41 localhost NetworkManager: info SUP: response was '0' Nov 12 17:58:41 localhost NetworkManager: WARN real_act_stage2_config(): Activation (eth0/wireless): couldn't send wireless configuration to the supplicant. Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) failure scheduled... Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) complete. Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0) cancellation handled. Nov 12 17:58:41 localhost NetworkManager: info Activation (eth0): cancelled. Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) started... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) scheduled... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) started... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) scheduled... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) Stage 1 of 5 (Device Prepare) complete. Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) Stage 2 of 5 (Device Configure) starting... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0/ wireless): access point 'xo' is unencrypted, no key needed. Nov 12 17:58:42 localhost NetworkManager: info Deactivating device eth0. Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0): cancelling... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) cancellation handler scheduled... Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0): waiting for device to cancel activation. Nov 12 17:58:42 localhost NetworkManager: info SUP: sending command 'INTERFACE_ADD eth0 wext/var/run/wpa_supplicant ' Nov 12 17:58:42 localhost NetworkManager: info SUP: response was 'OK' Nov 12 17:58:42 localhost NetworkManager: info SUP: sending command 'AP_SCAN 1' Nov 12 17:58:42 localhost NetworkManager: info SUP: response was 'OK' Nov 12 17:58:42 localhost NetworkManager: info SUP: sending command 'ADD_NETWORK' Nov 12 17:58:42 localhost NetworkManager: info SUP: response was '0' Nov 12 17:58:42 localhost NetworkManager: WARN real_act_stage2_config(): Activation (eth0/wireless): couldn't send wireless configuration to the supplicant. Nov 12 17:58:42 localhost NetworkManager: info Activation (eth0) failure scheduled... Nov 12 17:58:42 localhost NetworkManager:
Re: when an xo loses connection, how long does it take to disappear from other's neighbor view?
Yes, i have seen this ticket in the past. To detect whether an XO is actually there or not, is a simple task to accomplish, and I am currently working on a simple script that will give a list of the properly connected XOs, along with the temporarily disconnected. It is a very useful idea to display this information in the neighbor view, in terms of a dotted line, or a grey color perhaps. The problem is that the bugs are dealt with according to priority, and generally enhancements although very practical, can cause other bugs, or take several builds until they work properly. Since we are in code freeze, a quick solution must be implemented to solve the current situation, ie that it takes up to an hour for a disconnected xo to dissapear(just reported as #4735). yani On Nov 7, 2007 5:49 PM, Eben Eliason [EMAIL PROTECTED] wrote: 1. We need to fix the timeout for icons to disappear. Can we try Guillaume's patch? I hope so. I have a tarball with the patch, but I'm still waiting for Update.1 approval (it's unclear whether I can build RPMs for Joyride before I get Update.1 approval or not). If you're at 1CC, could you please annoy the ApprovalForUpdate people in person until they either look at their bugs, or confirm whether I'm still allowed to build RPMs in Koji? Just a mention, since this thread is getting a lot of attention. There is an added visual element which should be in play here, according to the design. There should be an intermediate state before XOs disappear from the view, as outlined in: http://dev.laptop.org/ticket/3657 2. We need to be able to restart PS. As you say this is not possible, but if we restart sugar will PS restart as well? Yes, that's right (the D-Bus session bus will exit, which causes D-Bus services like PS to exit too unless they've specifically asked not to). I see you assigned the bug about need to be able to cope with PS restarts to yourself. Unless you're planning to implement the necessary Python code in sugar.presence yourself, please don't. I don't think it's feasible to implement correct handling of PS restarts in sugar.presence for Update.1, so unless the release engineering team specifically tell me to, I won't be addressing that bug until a later release. 3. We need to force gabble to run. We have several instances of 4193 (almost all XOs connected to schoolserver,AP are running salut). Or at least to force trying to connect to jabber server. Please see my comments on #4193 regarding steps to take to debug (I think it's #4193 I commented on - I can't remember bug numbers, and Trac is down at the moment). In summary: * try resolving the server with getent hosts jabber.laptop.org * try pinging it with ping jabber.laptop.org * try connecting via TCP with telnet jabber.laptop.org 5222 (type hello and press Enter, if all goes well you should get disconnected with an error message that mentions XML not well formed) If any of these steps fail, Gabble won't be able to connect either, and there's nothing Gabble can do about it - talk to the Network Manager maintainer instead, since that's the component responsible for getting network connectivity and DNS on the XO. If you check the Gabble log you'll probably find that Gabble is trying to connect, but failing because either it can't resolve jabber.laptop.org in DNS, or it can't get a TCP connection there. That was my diagnosis of two of the cases you mentioned in your bug with 3 sets of logs (which may have been #4193?). In the third case it looked as though you hadn't waited long enough for the log to indicate success or failure. 4. The process of trying to connect to the jabber server, is done by telepathy-gabble, or by the presence Depends what you mean. The Presence Service is responsible for choosing when to try to connect (at which time it calls the Connect() D-Bus method on Gabble), but it's Gabble that actually opens a TCP socket to the Jabber server and tries to talk to it. You can see this in the PS log, for instance: 1194431620.966651 DEBUG s-p-s.telepathy_plugin: ServerPlugin object at 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0): connecting... 1194431620.967008 DEBUG s-p-s.telepathy_plugin: ServerPlugin object at 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0): Connect() succeeded (note that Connect() succeeded is a bit misleading - it just means that the connection manager has said OK, I'll try, rather than that it has actually been able to connect.) In the telepathy-gabble log you'll then see something like this: ** (telepathy-gabble:25330): DEBUG: do_connect: calling lm_connection_open Going to connect to olpc.collabora.co.uk Trying 195.10.223.134 port 5222... ** (telepathy-gabble:25330): DEBUG: tp_base_connection_change_status: was 4294967295, now 1, for reason 1 **
Re: Presence service bugs/enhancements
6. The jabber servers should be switchable(to change from one to the other) in a neater way then accessing the config file and rebooting. This can probably be invoked by sending smth like ..xmlns:stream= http://etherx.jabber.org/streams; to=jabber.laptop.orgas i noticed in the log files. If it is simple to apply, can you describe how it can be done properly?(not on trac) No, you can't send a new stream:stream element to the server to magically turn it into a different server :-) Gabble needs to be told to open a new TCP connection to the new server and do XMPP over that, and drop its old connection. This is entirely possible; Gabble already supports connecting to many servers simultaneously, if this is ever needed. It would be possible to add API to the Presence Service to drop its connection to the current server and connect to a different server. What are the requirements for this task? Is there a UI requirement that we should be supporting? I'd guess that this would be part of the same UI that handled switching between Gabble and Salut? This would be the requirement CP1.3 (Set which jabber/school server), right? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut (link-local) protocol changing - don't expect interop between versions
Since you are updating the presence service, it is a could opportunity to fix the switch from salut to gabble. When internet connectivity is detected, salut should stop, and gabble should start right after. However, this doesnt work properly even on latest builds, especially when the XO connects through schoolserver. It has even been documented(bug 4193) that an XO was connected to medialab AP and was still running Salut. The neighbor view included several XOs and could share properly. It is pretty high priority to make this work properly. Also, when connected to a school server, it is faster to communicate with others in the mesh through salut, then through jabber. So it can be useful for the user to force salut even when jabber is available. yani On 10/18/07, Simon McVittie [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a heads-up for anyone who isn't already aware: We're replacing the Salut (link-local collaborative backend) rMulticast protocol with a better version, over the next week or so (bug #4044). This is an incompatible change; there may in fact be more than one incompatible change involved, if we have to change the protocol further when it's had larger-scale testing. As a result, until further notice, Salut is not expected to be compatible between different versions. Please do not report bugs in link-local (serverless) collaboration unless all participants in the activity are running exactly the same snapshot of Salut (e.g. the same XO image). We'll freeze the network protocol again between now and the 1.0 freeze. The improved rMulticast protocol either fixes, or will enable us to fix, #3294, #3969, #3465, #3338 and possibly #4127; we might also take the opportunity to improve the mDNS part of the protocol. Checking the version on an OLPC: rpm -q telepathy-salut Checking the version in jhbuild: ls -d source/telepathy-salut-*, see which one has the latest date in the directory name Regards, Simon on behalf of the OLPC Telepathy team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHF4ZmWSc8zVUw7HYRAqtDAJ9AWv5rE8jZzl84zlZW+MRLd6zxqACfRD3z OgPyBcBGKb1tZjbY+PT432I= =ouwQ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
I'm afraid I'm totally ignorant of the subject. How is the Xlib compose handling supposed to work in applications? Would it also work in Write.activity? First, you should replace Compose file (in /usr/share/X11/locale/en_US.UTF-8). In addition, setting GTK_IM_MODULE=xim should explain gtk+ apps they have to use XIM. That's about it IIRC. By the way, the am_ET.UTF-8 locale appears to work with glibc 2.90 from Fedora Development. We'll need to backport a fix or upgrade glibc if we want Ethiopian support in the OLPC. Sure! We cannot progress if we do not have that locale properly working. Sergey ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: LANG=am_ET causes funny collating order
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernardo Innocenti wrote: What was the fix? I think we'll need to backport the patch to F7's glibc for fork the package off in OLPC-2. Lot's of changes in at least three completely different places. Just use the F8 glibc, it can only be better. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHB7um2ijCOnn/RHQRAiEPAJ4q0tu2Z/r3UnY8ooS60HsCqlqCugCgnROf n7IKeHGO4lyjIHI8yH9eK4c= =vtGE -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [PATCH] GEODE: decouple sleep/resume from powerdown/powerup (take 2)
On Sun, 23 Sep 2007 22:19:58 -0400
Bernardo Innocenti [EMAIL PROTECTED] wrote:
This patch merges the fb_powerup and fb_powerdown hooks in a single
operation fb_power with an additional state parameter ranging
from 0 (running) to 3 (poweroff).
diff --git a/drivers/video/geode/lxfb_ops.c b/drivers/video/geode/lxfb_ops.c
index b2ecb4d..b380238 100644
--- a/drivers/video/geode/lxfb_ops.c
+++ b/drivers/video/geode/lxfb_ops.c
@@ -829,33 +829,42 @@ static void lx_restore_regs(struct fb_info *info,
struct geoderegs *regs)
[...]
-int lx_shutdown(struct fb_info *info)
+int lx_power(struct fb_info *info, int state)
{
struct lxfb_par *par = info-par;
- if (lx_power_on == 0)
- return 0;
-
- writel(DC_UNLOCK_CODE, par-dc_regs + DC_UNLOCK);
- lx_save_regs(info, saved_regs);
- lx_graphics_disable(info);
+ if (state 0 || state 3)
+ return -EINVAL;
- lx_power_on = 0;
- return 0;
-}
+ /* Going into power save */
+ if (state = 2 lx_power_state 2)
+ lx_graphics_disable(info);
-int lx_powerup(struct fb_info *info)
-{
- struct lxfb_par *par = info-par;
+ /* Powering down */
+ if (state = 3 lx_power_state 3) {
+ writel(DC_UNLOCK_CODE, par-dc_regs + DC_UNLOCK);
+ lx_save_regs(info, saved_regs);
+ }
- if (lx_power_on == 1)
- return 0;
+ /* Restoring from power save */
+ if (state 3 lx_power_state = 3) {
+ lx_restore_regs(info, saved_regs);
+ writel(0, par-dc_regs + DC_UNLOCK);
+ }
- lx_restore_regs(info, saved_regs);
- writel(0, par-dc_regs + DC_UNLOCK);
+ /* Powering up */
+ if (state 2 lx_power_state = 2)
+ lx_graphics_enable(info);
- lx_power_on = 1;
+ lx_power_state = state;
return 0;
Jordan claims that we don't want to be calling lx_{save,restore}_regs
for state 2... I'll let him explain.
}
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5a82c83..0acbd27 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -661,11 +661,8 @@ struct fb_ops {
/* restore saved state */
void (*fb_restore_state)(struct fb_info *info);
- /* Shut down the graphics engine to save power */
- int (*fb_powerdown)(struct fb_info *info);
-
- /* Power it back up */
- int (*fb_powerup)(struct fb_info *info);
+ /* Change the power state of the graphics engine (0 = fully on, 3 =
fully off */
+ int (*fb_power)(struct fb_info *info, int state);
Jordan and I discussed using fb_blank() rather than adding an additional API.
Basically, my feeling is that fb_blank is already doing (or should be doing)
what we want to be doing (disabling misc hardware bits that are not needed
when the video processor is no longer pulling images from the GPU). So, we
might as well just be calling fb_blank from the dcon's sleep/freeze functions.
Jordan prefers the fb_power* stuff. We can argue about it later, with
upstream.
Also, the fb_power() API really needs a stricter definition of power levels.
--
Andres Salomon [EMAIL PROTECTED]
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Power manager specification... (request for comments).
The laptop should generally not act differently depending whether there is external power. Too many people seem to be assuming that any form of external power is AC power (i.e. a national power grid). In the presence of limited external power, e.g. a car battery, a human powered charger, a solar charger, a 220V gasoline generator, or a flaky power grid that comes and goes, the laptop should never go out of its save power mode. Feeding it power to charge its battery should not cause it to consume more power than it otherwise would! E.g. the screen brightness should never depend on whether there's external power. E.g. when closing the lid, with or without external power, the laptop should turn off the keyboard and touchpad and screen and backlight and USB and SD and NAND, and force a suspend to RAM. (At least until suspend-to-NAND is implemented.) Whether closing the lid turns off the wireless chip is not a concern of mine. If the wireless is left enabled for mesh forwarding, a closed=suspended laptop should not awaken because a packet arrives. You want the laptop to *stay* suspended when closed; if an application like eToys or Web is active, it will otherwise never go idle (animating the screen and burning up the battery). Hmm, I wonder if X could declare that a physically closed laptop's screen has become hidden behind another window (i.e. the front application goes into the background). If this won't stop every existing app from trying to update its window, then fix those applications to stop drawing in the background! [Can we create a null activity for testing, which clears the screen and then does nothing but obscure the other running activities? This would allow testing of the above, without physically closing the screen.] Closing the cover and suspending should always sync all filesystems first. Ideally it should not only sync them, but mark them as clean (the first write after resuming would have to mark them dirty again). Regarding how to do idle (is this suspend to RAM?), I think OLPC should really try doing what it has always claimed to want to do: suspend the CPU when nothing in the kernel is scheduled to happen for a second or two (or more). The only way to see how well it works is to try it. And if it doesn't work well, we'll learn what hardware improvements are needed to make it work well (for Gen 2's even lower power consumption). Kludging up specific applications and ohm to try to guess when no process will want to be running is overly complex and error-prone. If the kernel doesn't already know the answer, it ought to. The reason it was hacked into the ebook reader for a demo is because at that time, the rest of the system wasn't smart enough to stop running when it had nothing to do. John ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: DejaVu fonts (Was: Ethiopean)
Bernardo, When you replace simplified fonts with the full version: are you able to input Ethiopean with the code provided? Sergey On 8/22/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: (I'm moving to devel@ so we don't need to Cc too many people) Bernardo Innocenti wrote: Sergey Udaltsov wrote: I cannot tell you which font was used by my Ubuntu - I just see those glyphs rendered more of less correctly (see attached). If you're interested, I can provide you with the list of fonts I have installed. I see them just fine in Firefox on my F7 development machine, but not on the laptop. Weird... It turns out that the DejaVu font has the Ethiopian glyphs, but there's also a simplified font called DejaVuLGC which is what we're shipping on the OLPC. I just talked with Walter and J5 and we agreed that it makes no sense to ship a huge font with all glyphs when we're already going to have a custom images for each country where we can easily add language specific fonts. But now I looked at DejaVu to see how bigger it is and it seems to me that it's not worth it after all: -rw-r--r-- 1 root root 448K 2007-08-11 07:42 DejaVuLGCSans.ttf -rw-r--r-- 1 root root 557K 2007-08-11 07:42 DejaVuSans.ttf The RPMs for the complete DejaVu font are even *smaller*: -rw-r--r-- 1 root root 2.0M 2007-08-11 07:43 dejavu-fonts-2.19-1.fc8.noarch.rpm -rw-r--r-- 1 root root 3.3M 2007-08-11 07:42 dejavu-lgc-fonts-2.19-1.noarch.rpm (but that's because DejaVuLGC also comes with Condensed variants). So, is there another reason why we couldn't just switch to it? Currently, we're shipping arabic and thai fonts in all builds. If the DejaVu support for these languages is good enough, we could save even more space. -- // Bernardo Innocenti \X/ http://www.codewiz.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Salut (link-local) protocol changing - don't expect interop between versions
Since you are updating the presence service, it is a could opportunity to fix the switch from salut to gabble. When internet connectivity is detected, salut should stop, and gabble should start right after. However, this doesnt work properly even on latest builds, especially when the XO connects through schoolserver. It has even been documented(bug 4193) that an XO was connected to medialab AP and was still running Salut. The neighbor view included several XOs and could share properly. It is pretty high priority to make this work properly. Also, when connected to a school server, it is faster to communicate with others in the mesh through salut, then through jabber. So it can be useful for the user to force salut even when jabber is available. yani On 10/18/07, Simon McVittie [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Just a heads-up for anyone who isn't already aware: We're replacing the Salut (link-local collaborative backend) rMulticast protocol with a better version, over the next week or so (bug #4044). This is an incompatible change; there may in fact be more than one incompatible change involved, if we have to change the protocol further when it's had larger-scale testing. As a result, until further notice, Salut is not expected to be compatible between different versions. Please do not report bugs in link-local (serverless) collaboration unless all participants in the activity are running exactly the same snapshot of Salut (e.g. the same XO image). We'll freeze the network protocol again between now and the 1.0 freeze. The improved rMulticast protocol either fixes, or will enable us to fix, #3294, #3969, #3465, #3338 and possibly #4127; we might also take the opportunity to improve the mDNS part of the protocol. Checking the version on an OLPC: rpm -q telepathy-salut Checking the version in jhbuild: ls -d source/telepathy-salut-*, see which one has the latest date in the directory name Regards, Simon on behalf of the OLPC Telepathy team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net iD8DBQFHF4ZmWSc8zVUw7HYRAqtDAJ9AWv5rE8jZzl84zlZW+MRLd6zxqACfRD3z OgPyBcBGKb1tZjbY+PT432I= =ouwQ -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Ethiopian installation instructions
Bernardo I do not see the part regarding the input methods up there. I think there should be 2 parts: one for GTK IM (probably void, since it is enabled by default with the locale), another for XIM - modifying xorg.conf (or using setxkbmap) and setting GTK_IM_MODULE/QT_IM_MODULE. What do you think on this? Cheers, Sergey On 9/13/07, Bernardo Innocenti [EMAIL PROTECTED] wrote: mako suggested me to document a procedure for installing Ethiopic support on laptops: http://wiki.laptop.org/go/Ethiopian_Setup You may find the installation steps a bit convoluted, but, what the hell, if it was that easy we'd have it in the builds already :-) Of course, feel free to enhance the page. Any feedback welcome. -- // Bernardo Innocenti - http://www.codewiz.org/ \X/ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: T-shirt ideas / feedback
I confess that two months ago in the midst of an ear infection, fever and writing phd dissertation i registered some ridiculous domain names, such as oxpp, for one (whatever) per person. And it made me giggle because I realized it sounds like ox pee pee. (sorry if i've offended anyone). I really wish someone would write a mesh enabled tic tac toe activity. Or make a bluetooth touchscreen keychain tic tac toe, as a fundraiser. Or at least an app that would run on palm devices for yuppie commuters to play tic tac toe with their styli. or a cross between tic tac toe and scrabble (sorry i mean scribble, the open source sc__) and spin the bottle. (kissing on both cheeks is an acceptable form of greeting in some countries) i just keep thinking about the x and the o that's all. I mean, that is the prototypical game, involving x's and o's, that a significant number of humans in the known universe have played (as well as some dolphins) Yes SJ i wikified it: http://wiki.laptop.org/go/Tic_tac_toe publish early, publish often! On Oct 26, 2007 1:46 AM, Edward Cherlin [EMAIL PROTECTED] wrote: Nice, but why not One (billion) Laptop(s) Per (billion) Child(ren)? On 10/24/07, Seth Woodworth [EMAIL PROTECTED] wrote: Hello everyone, isforinsects here. There have been a couple suggestions for t-shirts floating around on the wiki and elsewhere. http://wiki.laptop.org/go/T-shirts I think that it's a great way to build community, and increase awareness so I mocked up a few ideas in InDesign. http://wiki.laptop.org/go/Image:Shirt_10_million.png (more to come) There are several great ideas on the wiki page, and all of them could become shirts via cafepress if anyone so cared. It would also become a slight revenue stream for OLPC community building if sold via cafepress or similar web-printing outfits. Does anyone have feedback on design and/or any ideas for implementation? I'm not going to go start a store somewhere unless the community is into the idea. Seth ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Edward Cherlin Earth Treasury: End Poverty at a Profit http://wiki.laptop.org/go/Earth_Treasury Sustainable MBA student Presidio School of Management ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Todd Kelsey Good Green Fun: http://www.cftw.com/xoroids/ Willy Wonka Wonderful! - http://wiki.laptop.org/go/Image:StartOfMP.jpg Love Poem for people of Middle East: http://welcome.cftw.com Tour of laptop | http://wiki.laptop.org/go/608-demo-notes About Me/CFTW | http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en; http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en Loving the World | http://docs.google.com/Doc?id=dhbxftbn_36cx4kj7 Fascinating for me to sit here and realize the interplay and influence that music can have -- it is a part of my life, yet I haven't continued as I could, partly out of thinking there are more important things. but it has it's place. i am sitting at olpc offices, and someone is playing pink floyd, and I think music is a gift of creativity that can inspire an atmosphere of creativity, and the range of such echoes is infinite. - Me Free tunes by me: http://www.cftw.com/music ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: some first impressions
Arjun, I composed an email that got longer with ideas, and sj must be rubbing off on me because i stopped just short of clicking Send, and actually made a wiki page. What I have no idea of how to do is actually to link back from a wiki page to an email discussion for context. Regardless, you might find it amusing to sometime look at this wiki page for some silly ideas that were inspired by your query for ideas, some of which have analog components: http://wiki.laptop.org/go/Wildlife Highlights: *Mimic, Parrot Activity, Tag Team Wildlife Research* *Open Source Mindstorm* *Brain Machine Interface* *Batchat* *Whalechat/Dolphin Dongle* *Xo scuba* *Xo snorkel* *Earth, Wind, Fire, Water* *XOEWS - XO Early Warning System* *Generation XO* *Lunchbox generator* *g1g1 solar* On Aug 15, 2007 5:00 AM, Arjun Sarwal [EMAIL PROTECTED] wrote: Hello all, Thank you for your emails. 1) eToys: It would be very nice to have support for Analog Input in eToys. You could use my code - See http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=audioGrab.py;hb=HEAD (getting samples) and http://dev.laptop.org/git?p=projects/measure;a=blob_plain;f=buttons.py;hb=HEAD (toggling between AC/DC modes and controlling bias voltage etc.) Or I could easily provide you with a class that you could use. I could make functions in that class that could simply return to you the required values. For example there could be a function that you could call to return avg voltage or rms voltage, select between ac/dc modes, set bias_on, set bias_off. Let me know if I can help in any way. I have opened the following ticket . See here - http://dev.laptop.org/ticket/2800 I have not assigned the ticket to any one nor set a time line for it as of now. Please feel free to set those. 2) Output Analog/Digital: The USB is an interesting idea as I had discussed with Mitch. I could simply make a board using a USB to parallel kind of a chip. I will be getting down to doing something similar shortly. Anybody would suggest to explore audio out for a similar purpose ? 3) Other ideas for sensor input : Mitch and Wad had suggested regarding exploring some basic medical applications using the Analog Input port. For example maybe be able to measure pulse rate ... I am quite excited about these ideas and plan to think about things to do on these lines too. Any initial suggestions ? regards, Arjun On 8/11/07, Mitch Bradley [EMAIL PROTECTED] wrote: Hal Murray wrote: - some parallel port (or similar) should be made available, for children to play with in physics. I remember playing with a PC parallel port with some simple software to turn leds on and off. When you are a kid, being able to send commands to projects you create is great (think about modern legos, but using simpler stuff like leds, motors, etc) : it translate the virtual part ie the software you create on the computer to the real world where you make leds blinks in sequence, or a motor move. ... There are USB connectors. ... USB to printer port adapters are also available. I've never played with one. Prices are under $40. There are also things like this with 24 GPIO lines. USBIO24R http://www.elexol.com/ US distributor: http://www.orteches.com/ $75 ... There is also the microphone input and audio output for A/D and D/A. I think the XO hardware supports a DC coupled mode. We should work on a collection of hacks to demonstrate how they work and a list of which ones are known to work. OLCP just had a summer intern, Arjun Sarwal, who developed some low-cost gadgets to plug into the mic port - temperature sensor, intrusion detector, etc. He plans to document them and set up a framework for documenting other similar hacks. We also talked about an OLPC digital gadget prototyping dongle with a USB-equipped microcontroller like those available from, for example, Atmel. Those chips cost a dollar or two and Arjun can get all the other parts really inexpensively in India where he lives. -- Arjun Sarwal One Laptop Per Child [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Todd Kelsey Good Green Fun: http://www.cftw.com/xoroids/ Willy Wonka Wonderful! - http://wiki.laptop.org/go/Image:StartOfMP.jpg Love Poem for people of Middle East: http://welcome.cftw.com Tour of laptop | http://wiki.laptop.org/go/608-demo-notes About Me/CFTW | http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en;http://docs.google.com/Doc?docid=dhbxftbn_35f5b46bhl=en Loving the World | http://docs.google.com/Doc?id=dhbxftbn_36cx4kj7 Fascinating for me to sit here and realize the interplay and influence that music can have -- it is a part of my life, yet I haven't continued as I could, partly out of thinking there are more
New joyride build 302
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build302/ -Web-73.xo +Web-74.xo -olpc-library-common.noarch 0:1-2 +olpc-library-common.noarch 0:1-3 --- olpc-library-common.noarch 1-3 --- * fixed missing dependency on sugar --- Web-74 --- * #4720: new index page for browse (erikos) -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
