Re: New joyride build 1420
Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1420/ -sugar-datastore.noarch 0:0.5-0.8.gite23a6f66eb +sugar-datastore.noarch 0:0.7.0-1 Where is the version number 0.7 taken from? In git master configure.ac still contains 0.5 and that is what make dist creates. Similarly Journal 80 seems to be in joyride but the latest version number in git master is 79 Is there a newer branch that master? Jani ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1422
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1422/ +olpc-utils.i386 0:0.53-1.olpc2 -olpc-utils.i386 0:0.56-1.olpc2 -xorg-x11-drv-cirrus.i386 0:1.1.0-5.olpc2 +xorg-x11-drv-cirrus.i386 0:1.1.0-6.olpc2 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/joyride-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1420
Jani Monoses wrote: Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1420/ -sugar-datastore.noarch 0:0.5-0.8.gite23a6f66eb +sugar-datastore.noarch 0:0.7.0-1 Where is the version number 0.7 taken from? In git master configure.ac still contains 0.5 and that is what make dist creates. Similarly Journal 80 seems to be in joyride but the latest version number in git master is 79 Is there a newer branch that master? Jani This is the update.1 process. http://wiki.laptop.org/go/Update.1_process When a fix(or a number of fixes) are targeted update.1 we cherry-pick from master to the update-1 branch and build the bundle from this branch. So the created bundle will show up on the branch update-1. HTH, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The reason we see icons flashing here and there in the mesh view.. i.e. xmas tree effect
On Thu, Dec 13, 2007 at 11:18:01PM -0500, Giannis Galanis wrote: THE TEST: 6 XOs connected to channel 11, with forwarding tables blinded only to them selves, so no other element in the mesh can interfere. The cache list was scanned continuously on all XOs using a script If all XOs remained idle, they all showed reliably to each other mesh view. Every 5-10 mins an XO showed as dead in some other XOs scns, but this was shortly recovered, and there was no visual effect in the mesh view. Could you provide a packet trace of one of these XO's in this test? (Install tcpdump and run ``tcpdump -i msh0 -n -s 1500 -w some filename''. I'm surprised that with only 6 laptops you hit this case so often. Ofcourse the RF environment in the OLPC is quite crowded, which could trigger this. Can you also run: http://people.collabora.co.uk/~sjoerd/mc-test.py Run it as ``python mc-test.py server'' on one machine and just ``python mc-test.py'' on the others. This should give you an indication of the amount of multicast packet loss.. Which can help me to recreate a comparable setting here by using netem. If you switched an XO manually to another channel, again it showed dead in all others. If you reconnected to channel 11, there is again no effect in the mesh view. If you never reconnected, in about 10-15 minutes the entry is deleted, and the corresponding XO icon dissapeared from the view. Therefore, it is common and expected for XOs to show as dead in the Avahi cache for some time for some time. THE BUG: IF a new XO appears(a message is received through Avahi), WHILE there are 1 or more XOs in the cache that are reported as dead THEN Avahi crashes temporarily and the cache CLEARS. At this point ALL XOs that are listed as dead instantly disappear from the mesh view. Interesting. Could you file an trac bug with this info, with me cc'd ? Sjoerd -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The reason we see icons flashing here and there in the mesh view.. i.e. xmas tree effect
On Fri, Dec 14, 2007 at 12:40:55AM -0500, John Watlington wrote: What worries me most about this is the revelation that we continue to rely on mDNS when connected to internet infrastructure. When in the presence of a school server, (or connected to a jabber server), mDNS should be shut down. The reason we shut _salut_, not MDNS down is that it can't work correctly in a group of laptops with two different multicast domains. As the Clique group for each laptop will be only in one of the two domains, so things don't always work as one would expect. Otherwise we risk a network meltdown I wonder what leads you to make this claim. Salut triggers some MDNS network chatter, but it should in no way be enough to cause a network melt-down. Also if salut (not mdns) is disconnected basically all the MDNS traffic should stop. (Nobody is quering for mdns information, so no requests should be sent out).. So shutting down avahi (and thus mdns) only makes things complicated for no good reason. Sjoerd -- Everything in this book may be wrong. -- Messiah's Handbook : Reminders for the Advanced Soul ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1420
On Dec 14, 2007 9:39 AM, Jani Monoses [EMAIL PROTECTED] wrote: Build Announcer Script wrote: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1420/ -sugar-datastore.noarch 0:0.5-0.8.gite23a6f66eb +sugar-datastore.noarch 0:0.7.0-1 Where is the version number 0.7 taken from? In git master configure.ac still contains 0.5 and that is what make dist creates. Similarly Journal 80 seems to be in joyride but the latest version number in git master is 79 Is there a newer branch that master? Hi Jani, 0.7.x (update-1 branch in git), is the release series for the Update.1 milestone. Work for future releases continue on master. I just bumped the configure version in master to 0.8.0, we had forgot to do it, if you see other modules in this situation please report it. Thanks! Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: The reason we see icons flashing here and there in the mesh view.. i.e. xmas tree effect
And what worries me even more is that we will further cripple the laptop by always turning off local-link collaboration every time we are able to contact *any* jabber server. I really don't want to have the MPP fiasco repeated Jabber servers on the local network, need to be able to identify themselves (even with mDNS or a predefined anycast address) and then and only then we can turn mDNS off. M. John Watlington [EMAIL PROTECTED] 12/14/2007 12:43 AM To Giannis Galanis [EMAIL PROTECTED] cc John Watlington [EMAIL PROTECTED], Michail Bletsas [EMAIL PROTECTED], Kim Quirk [EMAIL PROTECTED], Ricardo Carrano [EMAIL PROTECTED], [EMAIL PROTECTED], Robert McQueen [EMAIL PROTECTED], Simon McVittie [EMAIL PROTECTED], devel [EMAIL PROTECTED] Subject Re: The reason we see icons flashing here and there in the mesh view.. i.e. xmas tree effect What worries me most about this is the revelation that we continue to rely on mDNS when connected to internet infrastructure. When in the presence of a school server, (or connected to a jabber server), mDNS should be shut down. Otherwise we risk a network meltdown wad On Dec 13, 2007, at 11:18 PM, Giannis Galanis wrote: I had several tests related to the xmas tree effect we see in the mesh view. The effect is that some times XOs disappear + reappear to the same or different position, or simply disappear. More usually it happens for many XOs simultaneously. The results i have, clearly indicate that this is an issue an the Avahi daemon, which is used by the Salut telepathy service. The sugar interface displayes the information it receives from salut very reliably. This means that when a host dissapear from the avahi's host list, it vanished instantly from the mesh view, and the same when a new host arrives. The Avahi deamon runs below Salut and keeps receives information from other hosts in the network which also run Avahi deamon. It keeps a local cache with the recent hosts. At regular intervals(of 1-2 mins i think), it checks whether the hosts in the cache are alive. If not, they are recorded as failed The above check can be invoked by avahi-browse -t -r _presence._tcp continuously(instead of waiting for 1-2mins) After a certain timeout, a failed entry(dead host) will disappear from the cache, and instantly it will disappear from the mesh view. This timeouts is pretty long(several minutes), so a host(XO) has the chance to become alive again with no effect on the mesh view. This can occur when: a. the XO's avahi packets dont get through due to high mesh traffic. In this case the other XOs might either see is as alive, or dead according to the conditions. b.the XO's deliberately moved to another channel, or anyway disconnected. In that case, all othes XOs will see it as dead From a client's point of view, the two cases are treated almost the same. THE TEST: 6 XOs connected to channel 11, with forwarding tables blinded only to them selves, so no other element in the mesh can interfere. The cache list was scanned continuously on all XOs using a script If all XOs remained idle, they all showed reliably to each other mesh view. Every 5-10 mins an XO showed as dead in some other XOs scns, but this was shortly recovered, and there was no visual effect in the mesh view. If you switched an XO manually to another channel, again it showed dead in all others. If you reconnected to channel 11, there is again no effect in the mesh view. If you never reconnected, in about 10-15 minutes the entry is deleted, and the corresponding XO icon dissapeared from the view. Therefore, it is common and expected for XOs to show as dead in the Avahi cache for some time for some time. THE BUG: IF a new XO appears(a message is received through Avahi), WHILE there are 1 or more XOs in the cache that are reported as dead THEN Avahi crashes temporarily and the cache CLEARS. At this point ALL XOs that are listed as dead instantly disappear from the mesh view. But, of course, some of the dead XOs are expected to re-appear shortly. Specially those that are still in the same mesh channel, but merely failed to transmit its avahi packets due to traffic load. Note that if there is only 1 XO that looks dead, but returns, everything is normal. But, if there are 2,3.. XOs that look dead, when 1 returns, then: a. all(the dead ones) disappear from the view b. the 1 that returned will reappear right after in probably a different position. i.e. it will jump The avahi-browse command scans realtime the network(i.e. sends requests for all hosts in its cache list) and runs for a several seconds. If the above situation occurs, it freezes(this is what i meant by crashes). When it is restarted the cache is cleared from previously dead hosts. A typical situation that the xmas tree effect occurs: 20 XOs are running salut in channel 1. This incuded XOs conencted to medialab AP,
Re: The reason we see icons flashing here and there in the mesh view.. i.e. xmas tree effect
The test showed that the effect is not a result of a network failure. It occurs naturally, every time a new host arrives, while at the same time another host appears dead. Dead can also mean a host that simply disconnected fro the channel by user intervention. The best and simplest way to recreate the effect in any environment(noisy or not) is to: 1.Connect successfully 3 XOs in the same mesh. 2.Move successfully XO1,XO2 to another channel., and verify the show as failed when running avahi-browse in XO3 3.Reconnect at the same time XO1,XO2 to the initial channel. 4.While the XOs are trying to connect(30sec) check they still show are Failed when running avahi-browse in XO3 5.Observe the screen in XO3: the icons of XO1,XO2 will jump almost at the same time. To my best understanding, It is not related to a noisy envirnment Does not require a large number of laptops Can be recreated in 100% of the times you try the above. I believe that if the emulator you operate, uses the proper timeouts, you will see the effect yani On Dec 14, 2007 4:31 AM, Sjoerd Simons [EMAIL PROTECTED] wrote: On Thu, Dec 13, 2007 at 11:18:01PM -0500, Giannis Galanis wrote: THE TEST: 6 XOs connected to channel 11, with forwarding tables blinded only to them selves, so no other element in the mesh can interfere. The cache list was scanned continuously on all XOs using a script If all XOs remained idle, they all showed reliably to each other mesh view. Every 5-10 mins an XO showed as dead in some other XOs scns, but this was shortly recovered, and there was no visual effect in the mesh view. Could you provide a packet trace of one of these XO's in this test? (Install tcpdump and run ``tcpdump -i msh0 -n -s 1500 -w some filename''. I'm surprised that with only 6 laptops you hit this case so often. Ofcourse the RF environment in the OLPC is quite crowded, which could trigger this. Can you also run: http://people.collabora.co.uk/~sjoerd/mc-test.pyhttp://people.collabora.co.uk/%7Esjoerd/mc-test.py Run it as ``python mc-test.py server'' on one machine and just ``python mc-test.py'' on the others. This should give you an indication of the amount of multicast packet loss.. Which can help me to recreate a comparable setting here by using netem. If you switched an XO manually to another channel, again it showed dead in all others. If you reconnected to channel 11, there is again no effect in the mesh view. If you never reconnected, in about 10-15 minutes the entry is deleted, and the corresponding XO icon dissapeared from the view. Therefore, it is common and expected for XOs to show as dead in the Avahi cache for some time for some time. THE BUG: IF a new XO appears(a message is received through Avahi), WHILE there are 1 or more XOs in the cache that are reported as dead THEN Avahi crashes temporarily and the cache CLEARS. At this point ALL XOs that are listed as dead instantly disappear from the mesh view. Interesting. Could you file an trac bug with this info, with me cc'd ? Sjoerd -- Everything should be made as simple as possible, but not simpler. -- Albert Einstein ___ 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: olpc devel qlikview
On Dec 13, 2007 11:15 PM, John Watlington [EMAIL PROTECTED] wrote:
Can anyone tell me how a project owner is determined by git ?
http://dev.laptop.org/git?o=owner
It is set as whoever created the repository originally on d.l.o, IIRC.
--
Michael Burns * Student
Open Source {Education} Lab
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
New ship.2 build 652
http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build652/ -olpc-utils.i386 0:0.48.1-1.olpc2 +olpc-utils.i386 0:0.48.2-1.olpc2 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
My git repository is stuck with a lock problem
My git repository hosted on laptop.org seems to be stuck for the past three or four hours. Here are the messages I when I try to git push: [EMAIL PROTECTED] License.activity]$ git push updating 'refs/heads/master' from bb231162b87e27a389754b67bfafd8cdeafe03d0 to c3e252284fb8df59dc959ff64de7d0838b162d37 Also local refs/remotes/origin/master Generating pack... Done counting 3 objects. Deltifying 3 objects... 100% (3/3) done Writing 3 objects... 100% (3/3) done Total 3 (delta 0), reused 0 (delta 0) fatal: unable to create 'refs/heads/master.lock': File exists fatal: The remote end hung up unexpectedly error: failed to push to 'git+ssh://dev.laptop.org/git/projects/cclicensing' [EMAIL PROTECTED] License.activity]$ (I'm doing this push from a Fedora vserver on my desktop.) The network my XO was on had major problems, so I had to disconnect it after it hang after a 'git push' started. I guess the dev.laptop.org is still waiting for it to finish; but it will never finish. (I'm honestly rather supprised git can even get into a situation like this.) Who could fix this, and/or is there a way for fix it myself? (And is this the right place to ask?) Thanks! -- Asheesh. -- Admiration, n.: Our polite recognition of another's resemblance to ourselves. -- Ambrose Bierce, The Devil's Dictionary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New ship.2 build 653
http://xs-dev.laptop.org/~cscott/olpc/streams/ship.2/build653/ -olpcrd.i386 0:0.36-0 +olpcrd.i386 0:0.37-0 -- This email was automatically generated Aggregated logs at http://dev.laptop.org/~bert/ship.2-pkgs.html ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: multiple MTD partitions
On Fri, 2007-12-14 at 09:54 +0200, Artem Bityutskiy wrote: UBI/UBIFS is too large and difficult to implement their support in XO boot-loader. So I plan to use the following scheme: 1. Have 2 MTD partitions - mtd0 and mtd1. mtd0 is small (say, 10MiB), and has JFFS2 FS. It contains /boot, /boot-alt, and everything else which the boot-loader would like to have. mtd1 is large, and it spans up to the end of the flash chip. 2. When booting, the bootloader reads kernel, initrd and the other stuff from the JFFS2 FS on MTD 0. It has to be trivial as the boot-loader already can read JFFS2 FS. http://git.infradead.org/?p=openfirmware.git;a=commitdiff;h=a0b5a7b0c OpenFirmware boots from the partition named 'boot' in the RedBoot partition table. The rest are yours to play with as you see fit. -- dwmw2 ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Etoys] Smalltalk development on XO
Karl, Any comments are welcome. Thank you! Looks really good. I noticed a few issues with the code representation. Maybe add a link to http://squeakbyexample.org/ Oh, I meant to say any comments and corrections are welcome. Please edit and fix! -- Yoshiki ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: My git repository is stuck with a lock problem
On Dec 14, 2007, at 4:57 PM, Asheesh Laroia wrote: Who could fix this, and/or is there a way for fix it myself? (And is this the right place to ask?) Please try now. Cheers, -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: My git repository is stuck with a lock problem
On Fri, 14 Dec 2007, Ivan Krstić wrote: On Dec 14, 2007, at 4:57 PM, Asheesh Laroia wrote: Who could fix this, and/or is there a way for fix it myself? (And is this the right place to ask?) Please try now. Cheers, Sweet, thanks! All's well now. -- Asheesh. -- Hackers of the world, unite!___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
3dpong request for hosting
1. Project name : 3D Pong (suggestions welcome!)
2. Existing website, if any :
3. One-line description : 3D Action Game from 2007 Boston Game Jam
4. Longer description : See ThreeDPong on OLPC Wiki.
:
:
:
5. URLs of similar projects :
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 name SSH2 key URLE-mail
- --
#1 wadeb Wade Brainerd http://www.wadeb.com/wadeb.pub
[EMAIL PROTECTED]
#2
#3
...
If any developers don't have their SSH2 keys on the web, please attach them
to the application e-mail.
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.
If you choose the maintainer-owned tree model, but wish to set up some
shared trees where all of your project's committers can commit directly,
as might be the case with a discussion tree, or a tree for an individual
feature, you may send us such a request by e-mail, and we will set up the
tree for you.
8. Set up a project mailing list:
[ ] Yes, named after our project name
[ ] Yes, named __
[X] No
When your project is just getting off the ground, we suggest you eschew
a separate mailing list and instead keep discussion about your project
on the main OLPC development list. This will give you more input and
potentially attract more developers to your project; when the volume of
messages related to your project reaches some critical mass, we can
trivially create a separate mailing list for you.
If you need multiple lists, let us know. We discourage having many
mailing lists for smaller projects, as this tends to
stunt the growth of your project community. You can always add more lists
later.
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, projectname-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. Translation
[X] Set up the laptop.org Pootle server to allow translation
commits to be made
[ ] Translation arrangements have already been made at ___
12. Notes/comments:
I finally found time to update the game with sounds, better FX and a nice icon
by Tom Hannen, so I believe it's ready for distribution.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: New update.1 build 656
Should we be doing testing on this build, or on the latest joyride? Will all the changes made here be merged back with joyride eventualy? -ffm ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New update.1 build 656
On Dec 14, 2007 9:04 PM, ffm [EMAIL PROTECTED] wrote: Should we be doing testing on this build, or on the latest joyride? Will all the changes made here be merged back with joyride eventualy? The other way round: all the changes made in joyride will eventually make their way to a stable build (or be reverted). The update.1 builds are our first candidates for our next stable build series. Testing effort should gradually move from joyride to the stable builds as it freezes up. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
New joyride build 1428
http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1428/ -olpcrd.i386 0:0.36-0 +olpcrd.i386 0:0.37-0 -olpcupdate.i386 0:1.8-0 +olpcupdate.i386 0:1.9-0 -- 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: updated GStreamer RPMs
Hi, We're planning to rebase on Fedora 8 for Update 2, but it's good to be able to preview these ahead of time. Has this been proposed somewhere? I don't think I agree with it. I don't disagree strongly, but just enough that I'll stop someone from talking about it as if it's already been decided. ;-) (My reason for disagreeing is the standard progress vs. support dichotomy. I'd rather we kept the base OS as a known quantity but worked really hard on things like performance.) Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: New joyride build 1420
On Dec 15, 2007, at 8:12 , Chris Ball wrote: Hi, --- ohm.i386 0.1.1-5.9.20071213git.fc7 --- - Disallow all power management (suspend, dcon power) on pre-C machines. This isn't the comment that I associated with this build in my ChangeLog. It should say: ohm-0.1.1-5.9.20071213git.fc7.i386.rpm ohm-0.1.1-5.9.20071213git.fc7.src.rpm ohm-debuginfo-0.1.1-5.9.20071213git.fc7.i386.rpm ohm-devel-0.1.1-5.9.20071213git.fc7.i386.rpm * First shot at inhibit suspend when CPU is busy support. Needs tuning! -- Chris Ball [EMAIL PROTECTED] Thu Dec 13 17:18:05 EST 2007 My little dumb script only looks for a ChangeLog entry in the same directory as the RPM. But it also includes the most-recent changelog entry from the rpm: [EMAIL PROTECTED]:~$ rpm -qp --changelog /home/cjb/public_rpms/joyride/i386/ os/ohm-0.1.1-5.9.20071213git.fc7.i386.rpm * Mon Nov 26 2007 Chris Ball [EMAIL PROTECTED] - 0.1.1-5.9.20071126git.olpc - Disallow all power management (suspend, dcon power) on pre-C machines. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
