Re: Reporting bugs
Bert Freudenberg writes: I've had comments like this on some of my own reports. These are usually not reproducable, strange things. Having to follow through when this is far from my own area of expertise simply takes time I can't effort. There indeed is lack of interest on the part of the reporter, no denial here. I'm just saying that because of that, I stopped reporting those one-off bugs. Seeing comments like yours reinforces that decision. This is sad, but understandable. What is a bug reporter supposed to do about something that is very difficult to reproduce? Just not report it? I've hit a few bugs that I can't seem to reproduce. This does not mean the bugs are non-existant or that they won't someday destroy something like a child's journal content. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode/Floating Point pipeline
Edward Cherlin writes: I don't know about the internals of current activities in Python, but I know where you can find reams of array code in C, FORTRAN, and other languages in 3D graphics libraries (4 x 4 matrix multiplication especially), multimedia compression and decompression, cryptography (particularly RSA exponentiation, but also elliptic curve cryptography, ssh key exchange, and others), audio and image processing (lots of convolutions), font rendering (quadratic and cubic splines), and other computationally intensive domains. Nearly all of that is done with integer math. The more we do on this front now, the better for the older students when they come to modeling, numeric integration, linear programming, linear algebra, computational molecular biology, and so on and on and on. I don't think the Geode does computational molecular biology! Does anybody know how we handle signal processing in the Tamtam software synth? The Fast Fourier Transforms for going from time domain to frequency domain in the data visualization activity are a prime target. It's all multiply-accumulate except for the bit twiddling. The FFT is needlessly slow on the XO because the XO does not use FFTW and does not have pre-computed FFTW wisdom in /etc. I've been meaning to set up a login for some of the FFTW people so that they can benchmark and generally try things out. Maybe somebody can beat me to it. An even better idea would be to drop by their office (at MIT) with a XO. TODO: ensure that 3DNow! is used, and see if the Geode-specific instructions might be helpful. Spectral power wants a square root if I remember right; there is a Geode-specific instruction for that. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Signed build 623
On Oct 30, 2007, at 3:01 , C. Scott Ananian wrote: A signed image for build 623 is at: http://dev.laptop.org/~cscott/signed-623/ for those of you testing with security enabled. If I want to test with security enabled - can I still get out without a developer key? If not, what's the procedure to get a key? I've been holding back on that for fear of soft-bricking my XO ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode/Floating Point pipeline
My understanding is that you will not be able to achieve significant speed gains with FP scheduling. The Geode already has an out-of-order execution unit and no matter in what order you throw ops at the unit, it will take almost the same clocks to execute. So you can switch on -march=geode and shave 1% off from the length of the code and get speed gains because of more free cache and that's all. What you can do: - fix build scripts (that 1% speed gain will not hurt) - replace double with float - kill operations not needed (rewrite algorithms) - replace integer divide with mul/FP/3dnow where appropriate - put a lot of prefetch ops into the appropriate places (very important!!!) - measure real execution times and schedule FP ops ahead of time (even if they will not be needed) - use 3dnow ops (gcc does not support them) but you have to measure their real execution times as well (The last 3 requires inline asm.) If you decide to go into asm land and measure execution speeds then please let me know your results. What I am interested in is the latency of the FP/3dnow pipeline and the real execution speeds of PF2ID/PF2IW/FIST/FCOMI ops since there is a high chance that the geode databook does not match reality in that area. I would have been tested them but my login to a real XO stopped working. Brian Carnes wrote: The developers page on the wiki (http://wiki.laptop.org/go/Developers_program) mentions: compiler optimization: if you are a compiler wizard, we understand that the Geode lacks a specific back end code scheduler, which limits performance, particularly FP performance. We'd love to see work go on in this area which would help everyone. What aspects of this issue/request for help are still open? I'll go take a look at the OLPC build system tonight to see what is being used (late versions of GCC do have some Geode -mtune/-march modes), but would love to be hooked into whatever project is addressing this ...Or start my own project if I'm the first to step to the plate on this issue. If anyone knows any particularly lengthy floating-point dominated operations in the current software, let me know and we'll use them as our metric for improvement. Thanks, Brian ___ 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
Mass retargeting of releases
Apparently all tickets have been mass-moved from the former 1.0 milestone to 1.1, without leaving a trace in the individual ticket's changelogs. Since no tickets for Etoys are left in the upcoming milestone, can I go home now? Anybody care to explain what's going on? - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 168
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build168/devel_jffs2/ avahi-autoipd.i386 0:0.6.20-5.fc7 avahi-dnsconfd.i386 0:0.6.20-5.fc7 avahi-glib.i386 0:0.6.20-5.fc7 avahi.i386 0:0.6.20-5.fc7 avahi-tools.i386 0:0.6.20-5.fc7 avahi-ui.i386 0:0.6.20-5.fc7 avahi-autoipd.i386 0:0.6.20-5.olpc2 avahi-dnsconfd.i386 0:0.6.20-5.olpc2 avahi-glib.i386 0:0.6.20-5.olpc2 avahi.i386 0:0.6.20-5.olpc2 avahi-tools.i386 0:0.6.20-5.olpc2 avahi-ui.i386 0:0.6.20-5.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: ip4-address buddy property - still needed?
On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. Anyway The big issue for me is that once the ipv4 information is in a shipped release we're somewhat doomed to keep it in... But what your actually saying is that you want a graphical way to collect this information, not specifically that it has to be part of the information salut (or even telepathy) has.. Turning avahi-discover into an XO app, should be reasonably straight forward (it's a trivial application, using pygtk already). And it has all the information you need (and some more). Would that be a solution for your problem ? Sjoerd -- My geometry teacher was sometimes acute, and sometimes obtuse, but always, always, he was right. [That's an interesting angle. I wonder if there are any parallels?] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. In analyze-acivity, I wrote a python file called netdevice.py which return the network devices, IP, Netmask and MAC Address... Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. Yeah, we're killing the developer console... cheers. Ed.- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
Please check: http://wiki.laptop.org/go/Developer_Environment On 10/30/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ 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: ip4-address buddy property - still needed?
While I welcome the new activities and think it is great to integrate them into sugar, can we reconsider completely doing away with the dev console? It is /very/ useful to have the console open on an xo while the activity you are debugging is running behind it. Can't you have both the old console and the new activities? On 10/30/07, Eduardo Silva [EMAIL PROTECTED] wrote: Please check: http://wiki.laptop.org/go/Developer_Environment On 10/30/07, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On 10/30/07, Sjoerd Simons [EMAIL PROTECTED] wrote: On Fri, Oct 26, 2007 at 01:18:17PM -0400, Michail Bletsas wrote: At this point in time, having as much debug info available in the developer console without having to remember which command-line tool provides what, is crucial for collecting problem reports from non-expert users and I would request that the IPv4 information remains where it is. Apparently the developer console is going away. Or at least it's not part of the latest joyride builds. So you can't collect your info anymore this way. It's on the build actually but it's not working. It will be replaced shortly by a couple of activities. (Log and Analyze). Marco ___ 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: ip4-address buddy property - still needed?
On 10/30/07, Erik Blankinship [EMAIL PROTECTED] wrote: While I welcome the new activities and think it is great to integrate them into sugar, can we reconsider completely doing away with the dev console? It is /very/ useful to have the console open on an xo while the activity you are debugging is running behind it. Can't you have both the old console and the new activities? Once the new activities are in, please give them a try a report the usability issues you are finding with them on a ticket. We can rediscuss this with Eben and see how can we best solve the problems. Thanks, Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
An opportunity to help - printer configuration
The Give One, Get One program will put many XO laptops in situations unlike the design target. In particular, North American G1G1 purchasers won't be in clear school/village/community clusters. For the target country deployments, we have been assuming that printing will be done rarely (as paper is expensive), and where done, will be handled by the school server. That assumption does not hold for individual G1G1 purchasers. It would be useful if our developer community could test and document recipes for attaching XO to some common printers, especially USB printers. Obviously, it is easy with network printers, but I expect that the majority of G1G1 recipients won't have those. If you wish to help, please edit the page below with any recipes that you have developed. http://wiki.laptop.org/go/Printing Thanks! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Compiler optimization for Geode/Floating Point pipeline
Alex would love to help. - Jim On Mon, 2007-10-29 at 23:02 -0600, Rob Savoye wrote: On Mon, Oct 29, 2007 at 03:33:22PM -0700, Brian Carnes wrote: What aspects of this issue/request for help are still open? I'll go take a look at the OLPC build system tonight to see what is being used (late versions of GCC do have some Geode -mtune/-march modes), but would love to be hooked into whatever project is addressing this There is more info on geode optimizations for GCC and glibc at: http://wiki.gnashdev.org/wiki/index.php/Building_OLPC_Tools. There is some minor tweaking of the optimizer for the geode, it's mostly treated as a pentium class processor. While it could be better, with these patches it's still better than the default of pentium. Anyway, I'd love to work with folks that are also into shaving cycles whereever possible. - rob - ___ 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
Re: Reporting bugs
There is a balance here: I may not be hitting it the balance right. Any report of bugs is goodness; but if trac's signal to noise ratio goes bad, we can't see the forest for the trees. . A reproducible bug is much more valuable to us than ones that are not; a bug against current bits are much more valuable than old ones, exactly because we have a better chance to go fix it. Having developers spend time wading through bugs that there is no way to reproduce, either because the recipe for doing so, or insufficient information on what versions were being used. So if a bug clearly needs more information to be able to be chased, it seemed reasonable to me to request information from the reporter, wait for a few days, and then close it if the reporter does not bother to even acknowledge the request for more information. Is this reasonable, or not? - Jim On Tue, 2007-10-30 at 03:17 -0400, Albert Cahalan wrote: Bert Freudenberg writes: I've had comments like this on some of my own reports. These are usually not reproducable, strange things. Having to follow through when this is far from my own area of expertise simply takes time I can't effort. There indeed is lack of interest on the part of the reporter, no denial here. I'm just saying that because of that, I stopped reporting those one-off bugs. Seeing comments like yours reinforces that decision. This is sad, but understandable. What is a bug reporter supposed to do about something that is very difficult to reproduce? Just not report it? I've hit a few bugs that I can't seem to reproduce. This does not mean the bugs are non-existant or that they won't someday destroy something like a child's journal content. -- Jim Gettys One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 173
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build173/devel_jffs2/ Analyze-2.xo Log-2.xo Terminal-1.xo Terminal-2.xo Write-48.xo Write-49.xo --- Analyze-2 --- * New X Server Interface --- Log-2 --- * Drop presence and network interfaces --- Terminal-2 --- * Go to home user directory * Decrease font size --- Write-49 --- * Enable/disable the search functions based on the input (uwog) * Support for searching text (foddex, tiny bit of uwog) * Support custom keybindings (foddex) -- 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: New joyride build 173
I apologize if I missed the announcement on how activities get into the various new builds. In the past, we would assign trac tickets to J5. What do we do now? On 10/30/07, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build173/devel_jffs2/ Analyze-2.xo Log-2.xo Terminal-1.xo Terminal-2.xo Write-48.xo Write-49.xo --- Analyze-2 --- * New X Server Interface --- Log-2 --- * Drop presence and network interfaces --- Terminal-2 --- * Go to home user directory * Decrease font size --- Write-49 --- * Enable/disable the search functions based on the input (uwog) * Support for searching text (foddex, tiny bit of uwog) * Support custom keybindings (foddex) -- 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 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reporting bugs
Jim, it certainly is reasonable given the amount of manpower available. I only wanted to point out that blaming the reporter when closing a ticket gets you less bugs reported - something I though you might not have intended. Wording the reply differently could avoid that, to a certain extent at least. That said, I'd be happy to let this thread die and get back to coding ;) - Bert - On Oct 30, 2007, at 17:09 , Jim Gettys wrote: There is a balance here: I may not be hitting it the balance right. Any report of bugs is goodness; but if trac's signal to noise ratio goes bad, we can't see the forest for the trees. . A reproducible bug is much more valuable to us than ones that are not; a bug against current bits are much more valuable than old ones, exactly because we have a better chance to go fix it. Having developers spend time wading through bugs that there is no way to reproduce, either because the recipe for doing so, or insufficient information on what versions were being used. So if a bug clearly needs more information to be able to be chased, it seemed reasonable to me to request information from the reporter, wait for a few days, and then close it if the reporter does not bother to even acknowledge the request for more information. Is this reasonable, or not? - Jim On Tue, 2007-10-30 at 03:17 -0400, Albert Cahalan wrote: Bert Freudenberg writes: I've had comments like this on some of my own reports. These are usually not reproducable, strange things. Having to follow through when this is far from my own area of expertise simply takes time I can't effort. There indeed is lack of interest on the part of the reporter, no denial here. I'm just saying that because of that, I stopped reporting those one-off bugs. Seeing comments like yours reinforces that decision. This is sad, but understandable. What is a bug reporter supposed to do about something that is very difficult to reproduce? Just not report it? I've hit a few bugs that I can't seem to reproduce. This does not mean the bugs are non-existant or that they won't someday destroy something like a child's journal content. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 173
http://wiki.laptop.org/go/Build_system - Bert - On Oct 30, 2007, at 17:40 , Erik Blankinship wrote: I apologize if I missed the announcement on how activities get into the various new builds. In the past, we would assign trac tickets to J5. What do we do now? On 10/30/07, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build173/ devel_jffs2/ Analyze-2.xo Log-2.xo Terminal-1.xo Terminal-2.xo Write-48.xo Write-49.xo --- Analyze-2 --- * New X Server Interface --- Log-2 --- * Drop presence and network interfaces --- Terminal-2 --- * Go to home user directory * Decrease font size --- Write-49 --- * Enable/disable the search functions based on the input (uwog) * Support for searching text (foddex, tiny bit of uwog) * Support custom keybindings (foddex) -- 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: New joyride build 173
Short answer: put an .xo file in ~/public_rpms/joyride on dev.laptop.org. --scott On 10/30/07, Erik Blankinship [EMAIL PROTECTED] wrote: I apologize if I missed the announcement on how activities get into the various new builds. In the past, we would assign trac tickets to J5. What do we do now? On 10/30/07, Build Announcer Script [EMAIL PROTECTED] wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build173/devel_jffs2/ Analyze-2.xo Log-2.xo Terminal-1.xo Terminal-2.xo Write-48.xo Write-49.xo --- Analyze-2 --- * New X Server Interface --- Log-2 --- * Drop presence and network interfaces --- Terminal-2 --- * Go to home user directory * Decrease font size --- Write-49 --- * Enable/disable the search functions based on the input (uwog) * Support for searching text (foddex, tiny bit of uwog) * Support custom keybindings (foddex) -- 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 -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IMPORTANT] build and release process explanation
On Oct 30, 2007, at 17:55 , Ivan Krstić wrote: * please send an e-mail to [EMAIL PROTECTED] Why email? Email tends to be a black hole, whereas using a Trac ticket allows to track progress and makes sure things are not forgotten. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Reporting bugs
On 10/30/07, Jim Gettys [EMAIL PROTECTED] wrote: There is a balance here: I may not be hitting it the balance right. Any report of bugs is goodness; but if trac's signal to noise ratio goes bad, we can't see the forest for the trees. . A reproducible bug is much more valuable to us than ones that are not; a bug against current bits are much more valuable than old ones, exactly because we have a better chance to go fix it. Having developers spend time wading through bugs that there is no way to reproduce, either because the recipe for doing so, or insufficient information on what versions were being used. So if a bug clearly needs more information to be able to be chased, it seemed reasonable to me to request information from the reporter, wait for a few days, and then close it if the reporter does not bother to even acknowledge the request for more information. Maybe you need a new tag/goal/milestone/whatever for marking bug reports that need to collect duplicates until you can see a pattern. Wading through these bugs could then be a weekly event rather than a daily event. (not to be forgotten though; eventually you may see a pattern) Dealing with rare/unpredictable things is never easy. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
[IMPORTANT] build and release process explanation
Hi all, I wanted to additionally clarify what's happening in terms of release engineering and build process as we approach shipping. All former FRS tickets, as you might have noticed, were moved to what is now Update.2. Many of these are not bugs; they're tasks and enhancements, or relatively minor defects. We can't fix all of them for Update.1; it's not realistic. So we need to cherry-pick tickets from Update.2 that we know have a reasonable chance of _actually_ being fixed by this coming Friday. We proposed in the past that this is done by tagging the bugs with 'killjoy?' (and then 'update.1?'), as a bit of an overreaction to previous chaos in determining what goes into the builds. Until Friday, we'll lift this requirement. Subsystem owners are responsible for figuring out which bugs of those that were retargeted for Update.2 can be fixed for Update.1, retargeting them accordingly in Trac, and getting them fixed by Friday. Do this judiciously. Retargeting in bulk what we can't do in time won't help anyone. In terms of how builds are going to work -- we'll be using the joyride system: http://wiki.laptop.org/go/Build_system If you don't yet have a real shell on dev.laptop.org, please alert us immediately. RPMs and .xo bundles that you place in your drop box, as described on the wiki page above, will get picked up by the joyride build system and added to the next (hourly) build. Joyride will install your particular packages over the base OLPC system assembled with pilgrim, like in the old build process. AFTER we hit the Update.1 freeze on Friday, several things will happen: * The current joyride build at the end of Friday will become the Update.1 candidate build. * New RPMs inserted into ~/public_rpms will _not_ get automatically inserted in the build. Don't try it. * Any new code pushes require approval from the release engineering team. Again: anything new after Friday (bugs, code, etc) _requires_ approval. To obtain it, please send an e-mail to [EMAIL PROTECTED]. A release engineering team member will reply and CC devel@ or sugar@, whichever is relevant, with the approval or denial. Please let us know if you have questions, and thanks for bearing with us through the madness of the last stretch. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Music on the XO
Seth Woodworth wrote: Slightly off of the conversational thread here but: Information on the specific output spectrum capabilities might improve transcoding of audio files into smaller file sizes. If there is no, or poor quality, auditory response below or above a given threshold, it might be worth snipping off various frequencies, or otherwise optimizing how materials are encoded to take advantage of this. The speakers start rolling off at about 600 Hz and are virtually worthless below 400 Hz. The hardware has a one-pole highpass filter at about 400 Hz (I forget the exact frequency but it doesn't matter much) in order to reduce the amount of useless LF energy that is presented to the speakers. The rolloff is only in the speaker path; the headphone path has flat response across the audio band. In my experience, equalization doesn't improve the sound from the speakers very much. They sound tinny and weak no matter what you do. Taming the big peak in the 4 Khz range is of some value, but most program material has little information in that region, so the perceived improvement is small. Boosting the bass makes things worse - the speakers don't have enough air-moving capacity (cone diameter times linear motion range) to render low frequencies, and sending them more signal just slams the mechanical structure against its physical limits, causing distortion and possible damage. Bottom line - don't sell your Klipschorns. Is Jamendo, or anyone else, studying this? And Re: above conversation. Yes, I would love to see ethnologists get involved. The at the moment I don't believe is a lack of effort on anyone's part, but a lack of available material. Go to most university's music libraries and you will still find plenty of content in vinyl format as opposed to cd-audio or digital formats. Getting recordings made or existing recordings released into the public domain is an important project, and one of the main topics of a What should Wikipedia do with $100 Million dollars thread about a year back. I believe that just about everyone is on the same page here as far as what they would *like* to see on the OLPC. In the meantime I think that the current selections are far better than nothing.. Seth On 10/28/07, *Jean Piché* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: If I may summarize, what you are saying is that: a) Given that this is about education, OLPC should be taking the cultural high road in terms of bundled music. yes. b) The perception that acceptable licensing terms will be difficult to impossible to obtain should not get in the way of a) yes. ___ Devel mailing list Devel@lists.laptop.org mailto:Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ 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
Teleconference information for software status meeting (tonight, 2100 EDT)
Hi, We'll be having the weekly software call on the phone tonight, *not* IRC. Please send any agenda items. Mitch Bradley will be chairing. DIAL IN: From the United States: 866-213-2185 From Outside the United States: 1-609-454-9914 access code: 8069698 problems? Call customer care 800-526-2655 or 205-206-2301 Thanks! - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [IMPORTANT] build and release process explanation
On Oct 30, 2007, at 3:44 PM, C. Scott Ananian wrote: The details here might be in flux for our first joyride-based build, but we'll do our best to keep everyone informed. After some internal discussions, we will not be using joyride directly for the update.1 build. The instructions in my original e- mail still stand fully: joyride should be used by everyone to get their packages in, but we will actually assemble them into the final update.1 build outside of joyride. More details on this along with a concrete plan will be provided tomorrow sometime after the morning release engineering meeting. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ 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
New joyride build 177
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build177/devel_jffs2/ sugar-artwork.i386 0:0.34-0.31.20071019git811b41812a sugar-base.i386 0:0.1-0.3.20071016git7364e0078e sugar-artwork.i386 0:0.34-0.37.20071030git320c350df2 sugar-base.i386 0:0.1-0.4.20071030gited1f1b416d sugar.i386 0:0.65-0.88.20071026git176262f2e9 sugar.i386 0:0.65-0.89.20071030git8c89bfaed7 Analyze-2.xo Analyze-3.xo Log-2.xo Log-3.xo --- sugar-artwork.i386 0.34-0.37.20071030git320c350df2 --- * Just log a warning instead of aborting when sizes are negative (benzea) --- sugar-base.i386 0.1-0.4.20071030gited1f1b416d --- * Improved mime handling. (marco) --- Analyze-3 --- * Fix PyXRES --- Log-3 --- * Read check permission -- 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: log-collect / log-send
Hi Guys, 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. Would be better focus to develop just a main class to collect this information and different front-ends as a console script and the UI interface under the log activity. In this way we can avoid to duplicate code. Giannis, where is your source code?, can be cool if you and Pascal can merge a final python class. 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. both can be useful, but using just ONE collector ;) cheers. Eduardo. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: log-collect / log-send
Eduardo, There is a wiki page with some similar info: http://wiki.laptop.org/go/Developer_Environment I just realized that this page is created and edited by you So you have written scripts for this purpose as well? I have attached my two scripts. The are written in bash, but they are not commented netstatus gathers network info like: mac ip eth0,msh0,eth1,etc dns jabber server MPP,AP,schoolserver,linklocal gabble/salut netlog gathers the following: output from netstatus info file with build,firmware,model messages Xorg.0.log (thanx Jim for the comment in the trac) presenceservice.log gabble.log salut.log yani On 10/30/07, Eduardo Silva [EMAIL PROTECTED] wrote: Hi Guys, 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. Would be better focus to develop just a main class to collect this information and different front-ends as a console script and the UI interface under the log activity. In this way we can avoid to duplicate code. Giannis, where is your source code?, can be cool if you and Pascal can merge a final python class. 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. both can be useful, but using just ONE collector ;) cheers. Eduardo. netlog Description: Binary data netstatus Description: Binary data ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
System Software Meeting Minutes - 2007-10-30
Present: Jim, Kim, Mitch, cjb, c_scott, dilinger, dwmw2, Jordan,
Bernie, m_stone, ...
Topic - focused bug triage with particular emphasis on update.1
delivery, then a discussion of vserver and containment issues.
1396 Update.2 Ebook reader should suspend on idleness
Fixed - but needs to be turned on with the policy files
(Touch a file in the filesystem to turn it on.)
- CJB to turn it on, but only for = C2 systems.
2679 Update.2 Suspend on idle
- cjb to work on this after other ones that are lower-level
- cjb to supply a list of those other ones
2765 Update.1 EC needs programmable delay to turn off DCON chip (XM-killjoy)
- Reassigned to cjb to try doing it in OHM
- We need to do tinderbox tests to determine the power impact
- jg to check up on that tomorrow
1752 Update.2 USB wireless suspend/resume failure at setup phase
- Closed
2353 Update.2 Hang (USB, DCON) going to suspend
- Close as fixed
2401 Update.2 rsmith Wakeup event is repeated continuously (EC and kernel)
- The recipe given by MitchCharity has been reproduced by Mitch Bradley
- Not a show-stopper because the system recovers if you press the
button again
- We don't want spin firmware for Update.1 unless a more serious
problem surfaces
2699 Update.1 kernel usb storage does not write dirty blocks properly
while unmounting
- Important - reproducible, serious, probably fix-able
- dilinger to work on with high priority
2833 Update.2 camera fails in os547
- Works now because we reverted to an older gstreamer
- Left open but deferred to Future to see what happens upstream with
gstreamer and kernel
3470 rsmith No indication of low battery; laptop just shut down - No
definite recipe for reproducing
3610 rsmith Mystery shutdown without red warning LED - No definite
recipe for reproducing
4370 hardware No indication of low battery, laptop just shut down
- kim to collect all similar bugs
3579 Wireless hang after setconfig
- Closed, fixed by hardware changes
3978 Journal getting blank
- Might be fixed as of build 616
- Expecting to land with datastore fixes
4032 Touchpad not that easy to use
Longstanding bug - could be a kernel locking issue, could be
resistive interference
- Would be nice to be able to turn off the resistive area
- jg to file new tickets for specific improvement opportunities
1407 Force recalibration when power situation changes
- Move to update.1 and make it a blocker
4184 JFFS2 Dirent Anomaly
- We have several workarounds for this, and a solid fix if we can
remove vserver
4223 hardware Spinlock lockup on resume (LOOK) {This is the potential
memory corruption thing}
- Retest without vserver
4431 WLAN disappears after some number of suspend/resumes
- Closed
4466 EC hang after large number of suspend/resumes (MP Start)
- Low priority now
4217 Wireless/USB kernel panic on resume
- Closed as duplicate
4401 rsmith Sugar battery capacity does not update (There is a patch for
this; perhaps downgrade)
- Reassign to kim for testing
4439 rsmith HAL doesn't understand our battery class anymore. (Patch
available, also needs EC fix)
Fix apparently available, needs testing
- Can test latest stable kernel, but also awaiting new EC bits
4490 pdflush takes 80% cpu on 622
- Dup of 4184
Summary of Containment Issues:
* With vserver, we have an existing system implementation, but the
activities
are only partially converted and have not been adequately tested.
* The vserver kernel patch is unstable. The systems team
unanimously believes
that it can't be fixed quickly.
* The UID-based containment scheme has been designed but not yet
implemented.
The system-level implementation has no obvious roadblocks and thus
might not
take too long, but the activity conversion issue still remains.
* We lack adequate resources for converting and testing activities.
* The datastore needs modification to work across the isolation barrier.
* c_scott and Ivan believe that, if we fail to ship filesystem
isolation for
Update.1, it won't be economical ever to do so (because it will break
backwards compatibility).
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
phpmyfaq -- requesting your input
Kim, dev, anyone, - I put a general page up at http://wiki.laptop.org/go/Phpmyfaq for the purpose of capturing information and helping to take as much drain as possible off of developers; there are some general thoughts there. - Please consider visiting the page and putting down what you think are the most commonly asked questions on IRC, etc. The time you take to do this may be time you don't have to spend answering questions inline Notes: - Perhaps whoever sets topic in IRC might consider including url to faq instance. at the moment it is a single phpmyfaq instance. not sure at what point it makes sense to have multiples. depends on categorization. - If anyone happens to be from germany and knows the phpmyfaq folks, or if anyone knows the fantastico folks, maybe we can make it easier to manage multiple instances (the main reason would be to have separate top ten lists within categories, where there may not be the need for global search -- or maybe some clever person can figure out how to have a meta search across multiple instances). -- Todd Kelsey A brief 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 On 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 Did Apple design this? - The first words uttered by Noura, a woman in her twenties, when she saw the xo laptop for the first time on a recent plane flight. Tunes on MySpace: http://profile.myspace.com/index.cfm?fuseaction=user.viewprofilefriendID=191736094 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Music on the XO
On Tue, Oct 30, 2007 at 08:04:22AM -1000, Mitch Bradley wrote: The speakers start rolling off at about 600 Hz and are virtually worthless below 400 Hz. For your collective interest, the speakers can reproduce DTMF tones reliably provided the levels are set down from maximum. At lunch today on a B2 with build-debian, the dtmfdial package was used to transmit tones over a ham radio for making an IRLP request. The DTMF tones include 697 Hz for the top row. In listening to podcasts, certainly headphones sound better. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Music on the XO
Mitch Bradley writes: The speakers start rolling off at about 600 Hz and are virtually worthless below 400 Hz. Music activities should thus default to a bassoon. The odd thing about a bassoon is that the fundamental frequency is nearly absent. The ear-brain system fills in this frequency, making the bassoon sound very low pitched without actually containing much of the very low frequencies. At the other extreme, a sine wave is worst case. Recorders produce this, and flutes nearly do. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
