Giannis Galanis | 1 Feb 01:05 2008

Re: Salut/avahi/meshview issues

On Jan 31, 2008 10:54 AM, Ricardo Carrano <carrano <at>> wrote:

I believe our current salut/avahi issues are described in the following points:

1. I was under the impression that when a peer switches channels it sends a "goodbye signal". And in fact only anorthodoxically removed peers(after crashes/poweroffs by pressing the button etc) would delay to disappear from mesh views.  The 10min TTL is not unreasonable, but it should only be used for a routine check. In fact peers that leave/arrive should inform the mesh instantly. In that case the 10min TLL will only affect only the mesh points with noisy links that their "goodbye" signals will get lost. And these connections are less priority anyway. Also we could send 2/3 "goodbye" signals to "ensure" delivery.

Mm, it seems that some dbus signal or the respective processing by the PS lacks. Is there a NM dbus signal when we change channels? This should be easy to determine. 

It must be very easy for the PS to detect a channel change, or anyway when the XOs leaves the channel. The point is whether avahi supports such notifications, so the other peers can instantly remove the entry.

2. We should definitely decrease the timeout window between a lost peer being detected, and the actual disappearance from the mesh view. This used to be 10min, now it is 20min, but really, to my experience, if a peer is for more than 1-2min away he aint coming back.

For what you describe this does not seem related to the protocol itself, right? I believe it is important to achieve our goals without making the protocol more chatty.

This timeout is client specific, and doesnt affect the protocol itself at all. There reason this timeout exists(to my knowledge anyway), is that sometime a peer seems indiscoverable, but in fact it is just the effect of a poor link. So the peer rejoins shortly after. The effect would be XOs would move around the mesh view. To solve this issue, we wait for several minutes, before actually removing the XO.
To my opinion the more we hide from the user, the more she gets confused. Keeping the icon in the mesh view while the connections is down, just messes things up.
I also remember that there was the idea of keeping the "lost" icon in the mesh view, but notifying the user somehow, like change its outline to a dotted line or smth. But, this is a UI issue

3. Should we make the above TTL and timeout to be user specific, or custom anyway?. Will there be a problem if two XOs have different TTL? I would assume that it wont. The idea is that it is a waste of our resources to try to calculate the ideal values of TTL and timeout by asking the collabora team to fix, and fix again. Whereas we can make the test here in 1cc, and find ourselves which suits as best. Is it easy to implement such a patch?

I believe it  is useful to have  some controls  in order to help  tuning things up.  But not all of them need to be translated in user friendly controls. I believe your question would be how we could change this setting ourselves. Did I get it right?

Exactly. By no means we need to have this controls user friendly. We only need the ability to tune them dynamically our selves for testing and evaluating purposes.

Devel mailing list
Devel <at>
Jason Rock | 1 Feb 01:16 2008

Activity hosting application: Time

1. Project name             : Time
2. Existing website, if any :,
3. One-line description     : An Activity that can be used to explore different aspects of telling time.

4. Longer description       : A clock that displays the time in "natural", analog, and digital times to teach children how to tell time.
                            : Each of the clock's will have drag-able parts and the rest will update with the one that is selected
                            : A game will be built into the clock that teaches the children to find the analog time based on the digital time or vice-versa

5. URLs of similar projects : None that I know of

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 URL                    E-mail
      --------          ---------                      ------------                         ------
   #1 Jrock     Jason Rock                  attached                   jrock <at>

   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

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
   [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 Pootle server to allow translation commits to be made

   [ ] Translation arrangements have already been made at _______________

12. Notes/comments:

Attachment ( application/octet-stream, 547 bytes
Devel mailing list
Devel <at>
Build Announcer v2 | 1 Feb 02:15 2008

New joyride build 1621

Changes in build 1621 from build: 1620

Size delta: -0.26M

-kernel 2.6.22-20080131.1.olpc.a11c76ae59ffaf4
+kernel 2.6.22-20080131.2.olpc.f150813900a7eec
-olpc-library-core 1-21
+olpc-library-core 1-22
+olpcsudo 1.1-0
-olpc-library-common 1-20
+olpc-library-common 1-21
-sudo 1.6.8p12-14.fc7

--- Changes for olpc-library-core 1-22 from 1-21 ---
  + fix spelling of Ben Schwartz's name in credits

--- Included olpcsudo version 1.1-0 ---

--- Changes for olpc-library-common 1-21 from 1-20 ---
  + fix pattern error that was breaking l10n for library categories

This mail was automatically generated
See for aggregate logs
See for a comparison
Giannis Galanis | 1 Feb 03:14 2008

Re: jabber for non-wireless XO ?

can you please specify:
which jabber you tried to connect to?
which build are you running?

On Jan 20, 2008 7:42 PM, Mikus Grinbergs <mikus <at>> wrote:
I don't have any wireless.  I do have a wired ethernet connection to
a LAN (which in turn uses a proxy to reach the internet).

Even when I specify in sugar-control-panel the name of a real
server, my XO is not accessing jabber (the field in olpc-netstatus
is shown blank).  I believe my proxy can correctly pass requests for
ports 5222-5223.  Does telepathy work with a wired ethernet?  Does
it have a problem if the connection is through a proxy?


Devel mailing list
Devel <at>

Devel mailing list
Devel <at>
Jim Gettys | 1 Feb 04:11 2008

What's left for Update.1

For comment and discussion, here are the showstoppers I know of for
getting Update.1 finished.  If you think there are others, please speak
up now (and modify the subject line to start another thread).

Activity developers: note we'll be asking you to upload updated
activities to pick up all the recent flurry of translation work very

 1 - wireless firmware and driver support 
		(to fix problems with WEP and WPA)
 2 - q2d11 OFW - to fix battery problems
 3 - update activities to pick up translation work, Spanish 
	in particular, but not missing other languages we may need.
 4 - UI fix for registration with the school server.
 5 - switch to gabble from salut at school.
 6 -testing and fixing anything critical!

If we don't want to hold up an RC2 to pick up translation, then we
should anticipate an RC4 might be necessary (as we may have issues that
come up with updated activities).

4 - we previously (without Dave Woodhouse being available to add to the
discussion) thought we could/should punt #6135 and release note.
However, talking with him about what we should really fix given his
experience in Mongolia, the lack of positive confirmation that the
laptop actually was registered is a real issue.  The teachers are not
familiar with English (or computers), and the subtlety of a menu entry
going away isn't good enough.

I think we need to seriously discuss about possibly/probably being
update.1 fodder is the "kids arrive at school in the morning" problem.

5 - Use of mesh in large, crowded environments
If everyone arrives at school running local link and resumed quickly,
the network might melt from mdns mesh traffic's interaction with the
mesh's implementation of mutlicast.  We've upped the multicast bitrate
for multicast as a band aid, until we can dynamically adjust the
bitrate.  But the fundamental issue comes that in large, dense school
environments, can't expect multicast to scale far enough, and should be
using unicast to a presence server (jabber in our current case) to
handle this problem.

Dave Woodhouse has suggested may be to try to get a response to the
school server's anycast address, and if we get a response from a school
server, switch from Salut to Gabble for presence service automatically.

This is also somewhat mitigated by having working power management, as
machines that have suspended due to idle stop sending mdns packets, and
the kids presumably will want internet access and switch over when they
arrive.  But I'm not very confident that this will always work in large

Another temporary solution would be to have Ohm ask NM to reconnect if
the machine is suspended for more than some interval, say, 30 minutes.


Jim Gettys
One Laptop Per Child
Build Announcer v2 | 1 Feb 05:15 2008

New joyride build 1622

Changes in build 1622 from build: 1621

Size delta: 0.13M

-ohm 0.1.1-6.6.20080119git.fc7
+ohm 0.1.1-6.7.20080119git.fc7

--- Changes for ohm 0.1.1-6.7.20080119git.fc7 from 0.1.1-6.6.20080119git.fc7 ---
  + Don't undim the backlight on idle-wake-from-wireless; it's distracting.
  + Don't dim/undim the screen on B4s.
  + Since power button and lid raise are unreliable, wake from sleep on "empty sci".
  + Increase timeout before suspend from 30s to 60s.
  + If mtime on /dev/tty[12] is in the future, treat as invalid and don't stop suspend.

This mail was automatically generated
See for aggregate logs
See for a comparison
Edward Cherlin | 1 Feb 07:09 2008

Re: Staffing of an OLPC Booth at PyCon, volunteers needed

On Jan 31, 2008 10:10 AM, Mike C. Fletcher <mcfletch <at>> wrote:
> Edward Cherlin wrote:
> > 2008/1/29 Noah Kantrowitz <kantrn <at>>:
> >
> ...
> >> We are holding open an OLPC booth, as someone had  mentioned that they
> >> wanted one. Can anyone confirm this?
> >>
> >
> > A number of OLPC volunteers will be at PyCon, myself included. Does that work?
> >
> We're told by the PyCon organizers that they require an official request
> and a commitment to staff the booth throughout the conference hours in
> order to get the space reserved.

I will make sure the booth is staffed at all times. I have done booth
duty and staff management at other conferences, such as Linux World.
Send volunteers my way, and we will work out a schedule.

> They have the entire Expo hall
> "bookable", so we're competing with people paying for the privilege of
> displaying their "wares".  We need to get the request in ASAP to avoid
> losing the booth (i.e. yesterday-ish).
> We'd probably need 5-6 people to man the booth throughout the conference
> days without asking someone to spend the whole conference behind the
> desk.  I'm certainly willing to take a half-day or more.  We should have
> a good selection of XO's available.  Would be nice if we had a table,
> maybe a couple of posters and the like, but realistically I don't have
> enough time booked for OLPC before the conference to get that done.
> If we can get 5-6 volunteers to commit to it I'm willing to put together
> an official request and move forward.
> Take care,
> Mike

Let's do it.

There will be a number of XOs circulating and in the booth.

I can bring a current Live CD. If we can get a few packs of discs and
the use of a gang burner during tutorial time, we will be all set.

Does anybody have access to a poster printer? Walter says we might be
able to get a banner.

We should compose a flyer with information on Python on the XO,
including Pippy and Sugar resources, and pointers to mailing lists,
important Wiki pages, and the like.

Can somebody bring a demo string-pull power unit? We had one at a
recent BayPiggies meeting.

Can anybody think of suitable schwag that we can get donated? Tiny
rubber snakes to take with you on the plane? ^_^


Edward Cherlin
End Poverty at a Profit by teaching children business
"The best way to predict the future is to invent it."--Alan Kay
Build Announcer v2 | 1 Feb 08:15 2008

New joyride build 1623

Changes in build 1623 from build: 1622

Size delta: 0.00M

-rainbow 0.7.8-1.olpc2
+rainbow 0.7.9-1.olpc2

--- Changes for rainbow 0.7.9-1.olpc2 from 0.7.8-1.olpc2 ---
  + Relax the size restrictions on the tmpfsen that Rainbow mounts for
  + Symlink ~/.fontconfig -&gt; ~/.instance to ease
  + Rework build scripts to use mock for snapshot builds.
  + Normalize the package name to lower case everywhere.

This mail was automatically generated
See for aggregate logs
See for a comparison
Tomeu Vizoso | 1 Feb 13:41 2008

prevent data loss in running activities


as tracked in tickets #4088 and #6014, there are two situations where
the user can loose data inadvertently:

- user shutdowns from the system menu,

- laptop shutdowns unexpectedly because the laptop runs out of power or
the user pressed the power button.

Most activities are saving their state in the background when the user
switches to another activity, so in most cases the data loss will be
limited to the current active activity, since the last explicit or
implicit save. But this is probably not enough, as exposed by the
reporter of #6014.

In order for activities to save their state before the system cleanly
shuts down, we could use XSMP. We really don't need all that is in that
spec, specially the stuff about local and global state (our state is
always global).

We would need a session manager that synchronizes how clients save their
state and exit cleanly before the shutdown happen. That session manager,
be in its own process, matchbox (if there is already one in there) or
the sugar shell.

We could use an existing implementation of XSMP like gnome-session, but
people seem to agree in that its code is horrible and a complete
replacement is needed.

Follow two tentatives at rewriting gnome-session:

Also, there has been some discussion in freedekstop lists about ditching
XSMP and establishing a new standard based on D-Bus.

Has been suggested at some point that activities save before suspend. Is
this really needed? Do we want to make longer the time we need for
suspending? If OHM would wake up when the battery reaches a critical
level in order to initiate a clean shutdown, then we wouldn't need to
consider this as an special case.

Summarizing, I see three possibilities:

- Adopt a full-fledged implementation of XSMP and ask activities to
support just the save-on-shutdown part of it. (Giving a nice wrapper at
least for python activities).

- Implement a subset of XSMP in a new session manager implementation.

- Add a couple of D-Bus methods and signals to OHM/HAL, the sugar shell
and the activity service enough to support what we need.

Note that I'm talking about the short term here. What we should aim for
given the scarce resources we have, not what we ideally would do.



Michail Bletsas | 1 Feb 16:15 2008

Re: #6279 HIGH Retriag: cannot see Linksys AP

what channel is your AP on?
if it is not on 1,6 or 11 can you put it on one of them and report?

Devel mailing list
Devel <at>