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
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_35f5b46b&hl=en";>http://docs.google.com/Doc?docid=dhbxftbn_35f5b46b&hl=en Loving the World | http://docs.google.com/Doc?id=dhbxftb
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_35f5b46b&hl=en";> http://docs.google.com/Doc?docid=dhbxftbn_35f5b46b&hl=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: 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: Activation (eth0) > started... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) scheduled... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) started... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) scheduled... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) complete. > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) starting... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0/ > wireless): access point 'xo' is unencrypted, no key needed. > Nov 12 17:58:41 localhost NetworkManager: Deactivating device > eth0. > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0): > cancelling... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > cancellation handler scheduled... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0): > waiting for device to cancel activation. > Nov 12 17:58:41 localhost NetworkManager: 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: SUP: response was 'OK' > Nov 12 17:58:41 localhost NetworkManager: SUP: sending command > 'AP_SCAN 1' > Nov 12 17:58:41 localhost NetworkManager: SUP: response was 'OK' > Nov 12 17:58:41 localhost NetworkManager: SUP: sending command > 'ADD_NETWORK' > Nov 12 17:58:41 localhost NetworkManager: SUP: response was '0' > Nov 12 17:58:41 localhost NetworkManager: > real_act_stage2_config(): Activation (eth0/wireless): couldn't send > wireless configuration to the supplicant. > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > failure scheduled... > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) complete. > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0) > cancellation handled. > Nov 12 17:58:41 localhost NetworkManager: Activation (eth0): > cancelled. > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > started... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) scheduled... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) started... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) scheduled... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 1 of 5 (Device Prepare) complete. > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) starting... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0/ > wireless): access point 'xo' is unencrypted, no key needed. > Nov 12 17:58:42 localhost NetworkManager: Deactivating device > eth0. > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0): > cancelling... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > cancellation handler scheduled... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0): > waiting for device to cancel activation. > Nov 12 17:58:42 localhost NetworkManager: SUP: sending command > 'INTERFACE_ADD eth0 wext/var/run/wpa_supplicant ' > Nov 12 17:58:42 localhost NetworkManager: SUP: response was 'OK' > Nov 12 17:58:42 localhost NetworkManager: SUP: sending command > 'AP_SCAN 1' > Nov 12 17:58:42 localhost NetworkManager: SUP: response was 'OK' > Nov 12 17:58:42 localhost NetworkManager: SUP: sending command > 'ADD_NETWORK' > Nov 12 17:58:42 localhost NetworkManager: SUP: response was '0' > Nov 12 17:58:42 localhost NetworkManager: > real_act_stage2_config(): Activation (eth0/wireless): couldn't send > wireless configuration to the supplicant. > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > failure scheduled... > Nov 12 17:58:42 localhost NetworkManager: Activation (eth0) > Stage 2 of 5 (Device Configure) complete. > No
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: 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: > 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: > connecting... > > 1194431620.967008 DEBUG s-p-s.telepathy_plugin: > 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
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 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: 0x85f1e14 (telepathy_plugin+TelepathyPlugin at 0x82c8fb0)>: connecting... > 1194431620.967008 DEBUG s-p-s.telepathy_plugin: 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_connectio
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: 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
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: [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: 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: 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: T-shirt ideas / feedback
Seth, Some pretty nice ideas on that page. I put on the wiki an alternative design for the 10million shirt inspired by yours: 10 million laptops per 10 million children what do you think? 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 > > ___ 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: 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.org"as 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 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: 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: 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: 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
Geode LX Optimizations?
Hi, I'm playing with a Geode LX -based board for a small Linux-based home router/voip box (Soekris net5501). I'm hand-rolling a variant of Ubuntu 7.10 onto a CF card at the moment while I play around with the thing and decide how I'm going to configure it. I can get the thing up and running pretty well with a tuned configuration of the vanilla 2.6.23.1 kernel (I haven't yet checked to see if any of the geode kernel patches in the dev.laptop.org repo are not applied in 2.6.23.1, but it would be easy to apply them if not). What I'm looking at now is the gcc/glibc optimization work. It looks like the gcc changes to support -march=geode are in the 4.3 dev branch, so I can probably build that and use it (assuming I don't run into any serious regressions there) to do optimized builds of kernel, glibc, openssl, asterisk, and any performance-important asterisk deps (codecs, etc). I'm having a little trouble making sense of the geode-perf work on glibc, not being a glibc hacker. Has anyone yet either pushed this upstream (I couldn't find references to it in glibc cvs) or come up with a relatively simple patching process against glibc 2.6.1 (or higher) to apply the geode optimization work? On the assumption that the geode-perf git repo is about as user-friendly as it gets, anyone have some pointers on applying the work manually? I'm comfortable with patching things up, I have some good C/perl/sh skills, I'm just not at all familiar with the glibc source and build tools. If I can get this going, I'm planning to roll all of this effort up into some debian packages others can use (at least on gutsy-based installs). Of course, if there's an easier answer, like "Distro X already has geode-specific patches applied to everything", and the distro has some reasonable mechanism for bootstrapping into a smaller device (under Ubuntu, I'm using debootstrap to put a minimal install into a chroot environment, building stuff inside there, then rsyncing it to the CF card to try it on the hardware), I'm all for that solution too. I'm not subscribed yet, please CC me :) Thanks, -- Brandon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Xiph-dev] What's the status of Xiph codecs support in the Helix project?
Comments inline Ivo Emanuel Gonçalves wrote: > Hello lists, > > Personally, I have not yet had an opportunity to test the different > components in the Helix project. As such, most of what I know comes > from Wikipedia. > > In Wikipedia, it is stated that the Helix DNA Client supports Vorbis > and Theora, but apparently, not Speex. Is it this true? This is true. > How hard > would it be to port an implementation of Speex to the Helix Client? Not that hard. > Is anyone working in it? Not at the moment. I'm essentially the maintainer of the Xiph related code and haven't had the time lately to add speex support. At a minimum I'm hoping to do a new release with the Theora Beta 1 decoder in the next week or so. > What about Ogg Skeleton, which is now a > requirement for Theora videos served under the video/ogg media type? > Has this been formally made a requirement yet? It seems like this is still being hashed out on the xiph lists. I have yet to comment on the proposal because I haven't completely groked the whole thread yet. For now Skeleton is not supported. > In Wikipedia, it is stated that the Helix DNA Server only supports > streaming of MP3 and Real Media formats. Why?? Because streaming of Ogg has not been implemented yet. > The Ogg format was > created mostly for streaming. Ogg was created mostly for _HTTP_ streaming. The Helix server is traditional RTSP streaming server. >That means that streaming Vorbis and > Theora is (in theory) an easy process to implement for developers. Not true. Since Ogg allows arbitrary chaining of streams, implementing something that handles all of the various cases is quite difficult. Ogg's ability to chain segments together that have different numbers of streams in them are particularly taxing on the Helix Media Engine implementation. > Then there's also streaming through RTP. Vorbis, Speex, and Theora > may be streamed through RTP. Implementing this has been on my list of things to do. This is non-trivial especially if I want to properly handle chained streams. > > With the Helix software becoming part of the XO laptop (the OLPC > project) it is highly important that free formats work properly in > Helix, but that doesn't seem to be the case right now. Since you haven't even used the Helix code I find it difficult to accept your criticism that it isn't working properly. The code works great for the codecs and modes of playback that I have implemented. My primary focus was to get the most robust local playback of Theora & Vorbis files that I could. Making the ogg file format plugin work with the Helix Server and supporting Speex were secondary goals. I plan on adding Speex, and RTP delivery when I get a chance. Since there isn't a compliance document for ogg support and no specified minimal codec support, I think it is a stretch to say that Helix doesn't support free formats properly. Ogg is woefully under specified especially in the chained and multi-stream cases. Having a document that strictly outlines how to handle funky chained files (ie. audio-only, followed by audio/video, followed by a segment with 2 video streams) as well as files with say 2 audio tracks or 2 video streams would be of great help and would provide a way for all of the implementations out there to converge on a single interpretation. This has been a side project of mine for several years. I haven't spent much time on it lately because I have gotten little to no feedback on it . I've pretty much interpreted that as any of several things; users are happy with the current code, they don't care about this work, or they are unhappy but don't post anything to the list so I can fix it. In all of these cases there isn't much incentive to work on the code since there is no outside feedback. Also since there really isn't a minimum bar for claiming compliance, spec compliance isn't a motivator either. Aaron > > -Ivo > > ___ > Xiph-dev mailing list > [EMAIL PROTECTED] > http://lists.helixcommunity.org/mailman/listinfo/xiph-dev ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Console Mode, DOS Emulator on OLPC
Hello, I also volunteer - I believe as well that a console mode + a standard X windows, as suggested by the first poster, could have advantages. If you agree, a different runlevel could be used for that, ie the olpc could be switched easily between sugar mode and non sugar mode - call it salt or pepper if you want :) Actually, it could be a usefull distinction - the bootloader could start the kernel in either runlevel, depending on a special key combination, so that legacy educational applications could run without any problem or any complex operation, without interfering at all with anything else. Ex: press some button at boot time, and you are presented with the dos mode, where you can run your legacy applications as you always did. Press another button and you have a standard x-windows, so if you have a remote server with existing specific apps (math/chem), just log there, export the display and you're set, without python eating power/memory for tasks where it is not required. I too can see that being put into a good use, because there are several important DOS application for sign language actually used in Brazil, and many X applications in highscools and universities around where I live. I've been experimenting with such hacks. I'll try to release a good prototype soon. Guylhem On 9/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > I suppose that I have effectively opened my mouth and inserted foot, so > perhaps I should volunteer to start a bit of work in this direction. > > Any other volunteers? We'll work something out. ;-) > > --elijah > > > On Tue, 25 Sep 2007, Jim Gettys wrote: > > > Date: Tue, 25 Sep 2007 20:35:46 -0400 > > From: Jim Gettys <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Cc: Mitch Bradley <[EMAIL PROTECTED]>, devel@lists.laptop.org > > Subject: Re: Console Mode, DOS Emulator on OLPC > > > > On Tue, 2007-09-25 at 18:57 -0500, [EMAIL PROTECTED] wrote: > >> > >>> Subject: Re: Console Mode, DOS Emulator on OLPC > >>> > >>> OLPC does not support VGA/EGA/CGA graphics, so the display code for all > >>> those old programs will not work. > >> > >> > >> IIRC xdosemu provides vga support within an X window. > >> > >> I sympathize with folks who want to run ancient dos educational apps on > >> the OLPC - it'd be great if xdosemu were available as an activity-like > >> bundle for folks who need it. > > > > Seems like a good idea? Any volunteers? It isn't high enough on the > > priority list that we'll get to it anytime very soon. Would be a good > > way for someone to learn how to "sugarize" a simple application. > > - Jim > > > >> > >> [Same goes for C64 emulators... there are still folks in chemistry and > >> biology and physics who have useful code that runs on the Commodore > >> machines.. even at Big 10 universities. ;)] > >> > >> --e > >> > >> > 1. There are large number of DOS education application suitable for > teacher and students. > 2. Most DOS applications are designed for slow PC below 100 MHz. > 3. There are many abandonware/freely available 20 years old DOS > applications/tools on the Internet, such as TurboC, TurboPascal, TurboBasic > etc. > >> > >> ___ > >> 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: [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
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: 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: 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: [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: [Fwd: Status of Ethiopian support]
Hello Bernardo, Thanks for the report. >Sergey's Compose file for am_ET is already upstream, and it >is required for XIM-baded composition to work in all applications. This is the quesion #1 - does OLPC have requirement for Ethiopean to work in non-gtk apps? Are there such apps/activities in the standard image? >Furthermore, the Compose works by pressing a vowel, followed >by a consonant, which seems to be a less convenient way >of producing glyphs (see below) > >AI: Sergey said he'll check if CONSONANT+VOWEL is possible >with XIM. I see two options here: 1. The current one, when "dead" character is vowel. In that case, it only works as "VOWEL+CONSONANT". 2. We can make CONSONANT "dead" characters, but in that case entering CONSONANT itself would require either two presses of the consonant - or simply disabling XIM. Which way would you prefer? >GTK contains an Amharic input method which is currently outdated. >I'm in contact with the author, Daniel Yacob, who'll soon port >his latest patch to the current version of GTK. >This probably means we'll have to fork the gtk2 package too. >I'm unable to tell how important these changes would be for users. The important question - is that GTK IM using same layout/set of compose rules (just with reverted CONSONANT+VOWEL composition) as XIM? Are we working off the same standard? >Additionally, it seems this IM requires the "us" keyboard. >I couldn't get it to work with the "et" keyboard loaded. >Daniel says it shouldn't happen. It is no wonder IMHO, because it is using ASCII characters produced by 'us' XKB layout. Since 'et' layout produces unicode characters, the "left part" of the composition rules does not work. See the composition rules here: http://svn.gnome.org/viewcvs/gtk%2B/trunk/modules/input/imam-et.c?revision=11895&view=markup Cheers, Sergey ___ 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: DejaVu fonts (Was: Ethiopean)
Is it in the latest _stable_ build? Should I wait for the new one? Or should I rather risk installing today's devel build? Sergey On 8/24/07, Jim Gettys <[EMAIL PROTECTED]> wrote: > Also note that we need Pango 1.18 (just released) for Ethiopian to work; > J5 says this is now in our builds. > > On Fri, 2007-08-24 at 10:01 -0400, Bernardo Innocenti wrote: > > Sergey Udaltsov wrote: > > > > > Would you try the Ethiopian XIM in en_US locale (replacing Compose file)? > > > > 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? > > > > 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. > > > -- > Jim Gettys > One Laptop Per Child > > > ___ 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: 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: 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, 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
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: 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: 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: Devel Digest, Vol 21, Issue 42
I do not believe it would be compromising the spirit of the program to help a sovereign nation to do what *they* choose to do. My understanding of the purpose of the program is that it is not intended as a platform to tell developing nations what to do -- but is meant as an offer of a useful product that they can use how they wish. If a sovereign nation decides that they are interested in Microsoft Office, and they are on the point of choosing something other than the xo, for this reason -- then I would respect their choice, and as an issue of supporting the end user (not Microsoft), I believe it would still be legitimate to try and find a back up, as a development issue, to abiword and google docs -- if this would make the difference between a country adopting or not adopting the xo. I certainly believe that any sovereign nation will choose what they wish, (in many cases, unfortunately and sadly, and not in the best interests of their people). I simply prefer to suggest that the xo is the best choice, one reason being (among others) that it is freely available, freely copiable, free to study, free to modify, etc., and that it is THE best choice! :-) MS Office is none of these things, but go ahead and make a bad choice, if you wish ;-) I do not believe that the project would be ruined by people choosing to do what they want on the machines. I think it is exactly that freedom and openness that makes it very strong. Again, I certainly believe in your freedom to make poor choices! ;-) However, choosing anything to do with MS is choosing tyranny and closedness (is that a genuine word? :-)) over the freedom and openness of the OLPC. Typically the first thing I say about OLPC is that it is *not* a panacea, but is one way to make the world better, and if someone criticizes it, usually I say something like "that is great -- please get involved!" You obviously haven't seen B. Gate's criticism of the OLPC. :-) And I'm sorry -- I would gratefully accept the help of any Microsoft employee who would be willing to help, including Bill Gates. And you'd probably accept the help of Burmese military officials in helping govern a country, perhaps? Or accept the help of North Korea to liberate South Korea? Sorry, but I choose linux and support of OLPC for good reasons. I do not support MS for good reasons. If B. Gates wants to help, START with ethical investments and clean up his act (and genuinely help people, rather than just PR stunts). If B.Gates wants to genuinely help, he can GPL Windows and Office source code for starters ;-), especially if he supports what you call 'freedom' and 'openness'. It would seem you do not apply ethical standards, and would accept 'help' from KKK, mafia, criminal organizations, drug lords, heck, anybody who wants to!? An EXCELLENT reason to support OLPC is to provide people with choices, opportunities, freedom, etc. that are DENIED by MS. MS products are designed for something called 'vendor lockin', which perhaps you are not aware of and should study. Your acceptance of 'help' from MS, would be acceptance of MS ethical standards, which are abysmal, vendor lockin, etc., to say the least. Accepting 'help' from MS, is like accepting 'help' from a drug pusher to get off drugs. For a drug pusher, it's 'just business you know, nothing personal'. Sorry developers, I will continue this rant privately, with any and all concerned. We now return to our irregularly scheduled programming...:-) Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
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
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 w
Application: XO Quiz
1. Project name : XO Quiz 2. Existing website, if any : http://wiki.laptop.org/go/XO_Quiz, http://www.linuxuser.at/xoquiz 3. One-line description : Image Quiz-Game where questions are answered by clicking on the appropriate part of the image. 4. Longer description : We try to connect education, fun and features of the xo in as many ways as possible. : - Modular Structure (Exchangeable categories via Mesh and Schoolserver) : - Kids can easily create and share new questions, as well as rate other contributions. : - Flashcard System: http://en.wikipedia.org/wiki/Flashcard 5. URLs of similar projects : http://www.worldofwhere.com 6. Committer list Please list the maintainer (lead developer) as the first entry. Only list developers who need to be given accounts so that they can commit to your project's code repository, or push their own. There is no need to list non-committer developers. Username Full nameSSH2 key URL E-mail - -- #1 crazy-chris Chris Hager http://www.linuxuser.at/crazychris.ppk.pub [EMAIL PROTECTED] 7. Preferred development model [X] Central tree. Every developer can push his changes directly to the project's git tree. This is the standard model that will be familiar to CVS and Subversion users, and that tends to work well for most projects. [ ] Maintainer-owned tree. Every developer creates his own git tree, or multiple git trees. He periodically asks the maintainer to look at one or more of these trees, and merge changes into the maintainer-owned, "main" tree. This is the model used by the Linux kernel, and is well-suited to projects wishing to maintain a tighter control on code entering the main tree. 8. Set up a project mailing list: [X] Yes, named after our project name [ ] Yes, named __ [ ] No 9. Commit notifications [ ] Notification of commits to the main tree should be e-mailed to the list we chose to create above [ ] A separate mailing list, -git, should be created for commit notifications [X] No commit notifications, please 10. Shell accounts As a general rule, we don't provide shell accounts to developers unless there's a demonstrated need. If you have one, please explain here, and list the usernames of the committers above needing shell access. 11. Notes/comments: The project is split into two parts: 1. Building a sufficcient database with the help of contributers 2. Building the fairly simple python application The preview page for submitting new questions and playing the contributions is already online at linuxuser (not indexed, not public yet). I hope to start building the python application these days. Comments, critics, ideas, work-hours... all highly appreciated :-) Best greetings from Vienna! Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
