date:20080512

Re: New network scripts/tools for testing

2008-05-12 Thread Guillaume Desmottes

Le samedi 10 mai 2008 à 00:44 -0400, Giannis Galanis a écrit :
 The past couple of weeks I have been working on developing several
 Network testing scripts,
 that make testing a more pleasant experience!
 

Awesome!
I'm sure this will make debugging of PS/Telepathy issues a lot easier.

Thanks a lot


G.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New joyride build 1938

2008-05-12 Thread Build Announcer v2

http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1938

Changes in build 1938 from build: 1935

Size delta: -0.13M

-telepathy-glib 0.7.7-1.olpc2
+telepathy-glib 0.7.8-1.olpc2

--- Changes for telepathy-glib 0.7.8-1.olpc2 from 0.7.7-1.olpc2 ---
  + New upstream version

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Acoustic Measure Problem

2008-05-12 Thread Tomeu Vizoso

On Fri, May 9, 2008 at 5:47 PM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
  There is a much larger point here, though.  I would love to get more
  (any!) feedback from teachers about my code, so I know what's important in
  the field.  Until you mentioned this page, I had no idea that it existed.
  ~ I'm sure many other developers feel the same way.  It seems that the
  teachers want to give us feedback too, but somehow, the loop is not closing.

  We need to connect this feedback loop.  We need a way to get complaints
  back from the field into the hands of developers, like I've suggested in
  #6950.  We've talked about translating Trac, but if Trac is too
  complicated, then perhaps we need to set up an RT list:
  [EMAIL PROTECTED]  Maybe also a simple webform at
  inconvenientes.laptop.org, for those with web access but no e-mail.  Then
  we need to tell the teachers that these things exist, and make them
  understand that we really do want to hear about what they don't like.

  I want to hear complaints about my software, and then I want a way to open
  a dialogue with those who are having problems.  This is the first step
  toward improving open systems.

I like your suggestions, two questions:

- What would be done with the info submitted? Could there be an
automatic process or someone would need to manually triage and send to
trac/mailing lists?

- How we could get back to the submitter?

Thanks,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

New faster build 1938

2008-05-12 Thread Build Announcer v2

http://xs-dev.laptop.org/~cscott/olpc/streams/faster/build1938

Changes in build 1938 from build: 1935

Size delta: 0.00M

-telepathy-glib 0.7.7-1.olpc2
+telepathy-glib 0.7.8-1.olpc2

--- Changes for telepathy-glib 0.7.8-1.olpc2 from 0.7.7-1.olpc2 ---
  + New upstream version

--
This mail was automatically generated
See http://dev.laptop.org/~rwh/announcer/faster-pkgs.html for aggregate logs
See http://dev.laptop.org/~rwh/announcer/joyride_vs_update1.html for a 
comparison
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Acoustic Measure Problem

2008-05-12 Thread Benjamin M. Schwartz

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomeu Vizoso wrote:
| On Fri, May 9, 2008 at 5:47 PM, Benjamin M. Schwartz
| [EMAIL PROTECTED] wrote:
|  There is a much larger point here, though.  I would love to get more
|  (any!) feedback from teachers about my code, so I know what's important in
|  the field.  Until you mentioned this page, I had no idea that it existed.
|  ~ I'm sure many other developers feel the same way.  It seems that the
|  teachers want to give us feedback too, but somehow, the loop is not
closing.
|
|  We need to connect this feedback loop.  We need a way to get complaints
|  back from the field into the hands of developers, like I've suggested in
|  #6950.  We've talked about translating Trac, but if Trac is too
|  complicated, then perhaps we need to set up an RT list:
|  [EMAIL PROTECTED]  Maybe also a simple webform at
|  inconvenientes.laptop.org, for those with web access but no e-mail.  Then
|  we need to tell the teachers that these things exist, and make them
|  understand that we really do want to hear about what they don't like.
|
|  I want to hear complaints about my software, and then I want a way to open
|  a dialogue with those who are having problems.  This is the first step
|  toward improving open systems.
|
| I like your suggestions, two questions:
|
| - What would be done with the info submitted?

It would be translated and given to the engineer responsible for that
subsystem.

| Could there be an
| automatic process or someone would need to manually triage and send to
| trac/mailing lists?
There are many possibilities.  I think my favorite, at the moment, is to
create a simplified version of the trac webform,  perhaps a complete
parallel installation of Trac, at inconvenientes.laptop.org.  Presumably
we would make no registration required (or use the included OpenID once
that's live).  Therefore, users would be immediately be shown the problem
submission web form.  This form would contain fields for title, component,
the problem text, and uploads, without confusing users with severities or
owners.  Submissions could also be made by e-mail.

The process would then be the same as when someone submits an untriaged
trac bug.  The only difference is that the owner cannot expect the
submitter to respond further on that bug, due to lack of internet
connectivity and higher priorities than bug discussion.

| - How we could get back to the submitter?

If the submitter uses e-mail, Trac will CC them automatically.  If the
submitter uses the webform, they can be asked to bookmark that page, or
subscribe to its RSS feed.

Eventually, I would very much like to see direct support for non-realtime
messaging in Sugar.  Then [EMAIL PROTECTED] can be represented
as a specific buddy in the mesh view, and people can send messages to it
directly through the messaging interface, whatever form that may take.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKEHsUJT6e6HFtqQRAmwsAJwPr/b6Z7qaLXGCvnEubfGKmJCMqACghqsM
3GfoNiJOIbuH2hTDnKHjtaU=
=74qE
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: very simple datastore reimplementation

2008-05-12 Thread Tomeu Vizoso

On Fri, May 9, 2008 at 7:34 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote:
 On Fri, May 9, 2008 at 6:11 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
   On Fri, May 9, 2008 at 2:15 PM, Jim Gettys [EMAIL PROTECTED] wrote:
   FUSE is great, but...
  
   It means interoperability must be an explicit planned-in-advance action:
   if a datastore is already on a removable device in your pocket, and you
   need to access something on a foreign system, you are stuck unless there
   is some minimal level of human interpretability of the file system...
  
   Instead, you have to dig up a system with FUSE/olpcfs installed, and
   then copy the files to a conventional file structure.
  
   This is the use case that's hard to get around.
  
   Ok, I think I see now where is the misunderstanding.
  
   In the first post in this thread, I tried to explain that this
   proposal would use removable devices in the same way they are used in
   other systems and that the DS would have nothing to do with them:

  I think expanding the space available to the DS through usb devices or
  sd cards is a use case we should take in consideration when designing
  the DS, even if we don't plan to support it right now.

Sure, but we already know that we need a DS that supports different
backends with different on-disk layouts, right? Unless we can find an
equally efficient, robust and transparent layout that works in all
file systems including vfat.

In many areas, we have over-engineered because we tried to achieve
long-term goals in a short period of time with very few resources.
This has been one of the reasons why we have failed to deliver a
satisfactory solution to more basic goals.

I'm not against discussing the future, but I would like to advocate
for doing the basics well before investing too much effort in the
turing prize features.

Thanks,

Tomeu
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

RE: Acoustic Measure Problem

2008-05-12 Thread Greg Smith (gregmsmi)

Hi Ben,

I value your technical achievements and your contributions on the list
so thanks for raising the topic! 

I believe Tomeu is a polyglot and he keeps track of user feedback in
addition to being a great engineer.

On the Acoustic Measure + Mesh problem, I may know who posted that and
can send you his e-mail off list. You can also post to their wiki
comments page and to the Peru list [EMAIL PROTECTED] No one has
complained when I post there in pidgin Spanish, but I can find someone
to translate if you prefer. 

In terms of connecting users and developers, I hope that will become a
core competency of OLPC. I think its central to unlocking the potential
of the open source community.

If we get this right (many users co-developing many applications with
many developers) OLPC will have an unrivalled  development capacity.
Until then we're up against the Mythical Man Month (MMM) and so are
the users.

I've worked on the XO user - engineering communication problem for 6
months but I don't know the complete answer yet. I'm open to your
suggestions but there are already many places where people communicate.
Too many for developers to watch them all (MMM again). E.g. there are
two forums (en.forum.laptop.org and olpc news), OLPC Wiki, many e-mail
lists, [EMAIL PROTECTED], user generated sites, etc.

I think we get good feedback from English speakers on the wiki and
e-mail lists. If you want more English feedback you can try starting a
thread asking for input about your activity on the forum:
 http://en.forum.laptop.org/

The forum managers asked for more engagement from the development
community in a recent Support Gang meeting.

The main non-English input I have seen is coming in via user blogs. I
have a list of them on my talk page:
http://wiki.laptop.org/go/User_talk:Gregorio

Many non-English users are just starting to use computers. They don't
yet post to e-mail lists or Wiki pages. Some will but it takes pushing
and you need a site in their language. I doubt they will use Trac. 

For non-English contacts one solution is to find a lead bilingual
technical contact who is close to the users. Help that person and you
can develop a good source of feedback.
 
Be careful what you wish for :-). Development wont be able to keep up
with all the user input if we see a flood of feedback (Uruguay and Nepal
are just getting underway). One solution is to assign a lead person from
the list to spend a fraction of their time focused on each major site.
Those people can build relationships and monitor user input then extract
major themes for the devel list. Also, if a developer wants input on an
activity or design they can ask the lead contact.

I have relationships now with teachers in Peru and Uruguay if you have a
question for them send it over. Waveplace in the Caribbean and Nepal are
also easy to contact. 

Hopefully the communication systems will grow organically. We can help
get it started and try to direct it so it doesn't overwhelm users or
developers. 

The key is to offer value and support as the first step. Then ask
questions later. 

The other main point is to get the users involved before you develop the
software. If you have a great idea, just go for it. However, if you want
input from users, its better to get buy in for your application in
advance and build the user relationship up front.

In any case, its real work to get meaningful user feedback and one to
one interaction is still the best. Try working with this teacher in Peru
to get a sense of what it will take. Let us know how it goes and let me
know if I can help get you started.

HTHs. 

Thanks,

Greg S
 
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Tomeu Vizoso
Sent: Monday, May 12, 2008 8:36 AM
To: [EMAIL PROTECTED]
Cc: Greg Smith (gregmsmi); devel@lists.laptop.org
Subject: Re: Acoustic Measure Problem

On Fri, May 9, 2008 at 5:47 PM, Benjamin M. Schwartz
[EMAIL PROTECTED] wrote:
  There is a much larger point here, though.  I would love to get more
  (any!) feedback from teachers about my code, so I know what's 
 important in  the field.  Until you mentioned this page, I had no idea
that it existed.
  ~ I'm sure many other developers feel the same way.  It seems that 
 the  teachers want to give us feedback too, but somehow, the loop is
not closing.

  We need to connect this feedback loop.  We need a way to get 
 complaints  back from the field into the hands of developers, like 
 I've suggested in  #6950.  We've talked about translating Trac, but if

 Trac is too  complicated, then perhaps we need to set up an RT list:
  [EMAIL PROTECTED]  Maybe also a simple webform at  
 inconvenientes.laptop.org, for those with web access but no e-mail.  
 Then  we need to tell the teachers that these things exist, and make 
 them  understand that we really do want to hear about what they don't
like.

  I want to hear complaints about my software, and then I want a way to

 open  a dialogue with those who are

RE: Acoustic Measure Problem

2008-05-12 Thread Greg Smith (gregmsmi)

Hi Guys,

Our e-mails crossed in the ether :-)

If you get traction for this idea and the list is OK with it, I can ask
some teachers if they will use it.

Thanks,

Greg S

-Original Message-
From: Benjamin M. Schwartz [mailto:[EMAIL PROTECTED] 
Sent: Monday, May 12, 2008 9:11 AM
To: Tomeu Vizoso
Cc: [EMAIL PROTECTED]; Greg Smith (gregmsmi); devel@lists.laptop.org
Subject: Re: Acoustic Measure Problem

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tomeu Vizoso wrote:
| On Fri, May 9, 2008 at 5:47 PM, Benjamin M. Schwartz 
| [EMAIL PROTECTED] wrote:
|  There is a much larger point here, though.  I would love to get more
|  (any!) feedback from teachers about my code, so I know what's 
| important in  the field.  Until you mentioned this page, I had no
idea that it existed.
|  ~ I'm sure many other developers feel the same way.  It seems that 
| the  teachers want to give us feedback too, but somehow, the loop is 
| not
closing.
|
|  We need to connect this feedback loop.  We need a way to get 
| complaints  back from the field into the hands of developers, like 
| I've suggested in  #6950.  We've talked about translating Trac, but 
| if Trac is too  complicated, then perhaps we need to set up an RT
list:
|  [EMAIL PROTECTED]  Maybe also a simple webform at  
| inconvenientes.laptop.org, for those with web access but no e-mail.  
| Then  we need to tell the teachers that these things exist, and make 
| them  understand that we really do want to hear about what they don't
like.
|
|  I want to hear complaints about my software, and then I want a way 
| to open  a dialogue with those who are having problems.  This is the 
| first step  toward improving open systems.
|
| I like your suggestions, two questions:
|
| - What would be done with the info submitted?

It would be translated and given to the engineer responsible for that
subsystem.

| Could there be an
| automatic process or someone would need to manually triage and send to

| trac/mailing lists?
There are many possibilities.  I think my favorite, at the moment, is to
create a simplified version of the trac webform,  perhaps a complete
parallel installation of Trac, at inconvenientes.laptop.org.  Presumably
we would make no registration required (or use the included OpenID once
that's live).  Therefore, users would be immediately be shown the
problem submission web form.  This form would contain fields for title,
component, the problem text, and uploads, without confusing users with
severities or owners.  Submissions could also be made by e-mail.

The process would then be the same as when someone submits an untriaged
trac bug.  The only difference is that the owner cannot expect the
submitter to respond further on that bug, due to lack of internet
connectivity and higher priorities than bug discussion.

| - How we could get back to the submitter?

If the submitter uses e-mail, Trac will CC them automatically.  If the
submitter uses the webform, they can be asked to bookmark that page, or
subscribe to its RSS feed.

Eventually, I would very much like to see direct support for
non-realtime messaging in Sugar.  Then [EMAIL PROTECTED] can
be represented as a specific buddy in the mesh view, and people can send
messages to it directly through the messaging interface, whatever form
that may take.

- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIKEHsUJT6e6HFtqQRAmwsAJwPr/b6Z7qaLXGCvnEubfGKmJCMqACghqsM
3GfoNiJOIbuH2hTDnKHjtaU=
=74qE
-END PGP SIGNATURE-
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Devel Digest, Vol 27, Issue 59

2008-05-12 Thread Kim Quirk

Greg,
The work that Pol is doing on mesh is all in development now... nothing that
has been released in a signed build. So I would NOT recommend that many
people try to upgrade to this. Plus I believe the work he is doing requires
api changes, so other activities probably won't work collaboratively at all
(Pol, you can confirm this).

We should be careful to only recommend development builds to people
technical enough to understand how to downgrade if they get into trouble and
fully understand that they will probably lose all their data, etc. (like
developers). Probably there are very few teachers who have enough technical
understanding to be able to support a classroom of different builds.

Other thoughts on this?
Kim


On Fri, May 9, 2008 at 9:01 AM, Greg Smith (gregmsmi) [EMAIL PROTECTED]
wrote:

 Hi Polychronis,

 Thanks for sharing the results. Did you use a wireless AP or active
 antenna? If you can include a few details on that it will help. Can you
 also include the XO build # and XS build and config if relevant?

 Would you say that this test passed? That is, can we recommend that
 schools use the chat activity with one chat session which all join?

 Lastly, can you tell us what kind of testing time and focus you will
 have in the near future? I believe there is a mesh test lab coming up at
 Nortel in Ottawa as well. Any feedback on test capacity and plans there
 is appreciated too.

 I ask because there is recent feedback on mesh issues from a teacher at
 Lambayeque, Peru http://wiki.laptop.org/go/Lambayeque#Inconvenientes and
 a teacher in Uruguay has asked about supported Mesh features too. The
 Lambayeque page says: they wish they knew in advance that Acoustic
 Measure Activity would not work with 6 groups of two students each.
 That's mostly an issue with activity design and our communication about
 what activities support but it does raise a good test case (6 groups of
 2 sharing a single activity).

 I think both (Peru and Uruguay) teachers can help define meaningful mesh
 use cases which will be applicable in many schools. I want to set the
 right expectation on our capacity before I ask them to spend a lot of
 time working with us.

 I can start by telling them that chat as you describe above will work
 well, if you agree. Then we can follow up to gather more details on how
 they want to use the mesh.

 The good news is they are motivated to use the mesh which helps validate
 one design goal of the XO. Now we just need to understand how they want
 to use it :-)

 It looks like you are focused on finding the maximum scale of Xos which
 can be in a mesh. That's clearly important info too. I'm just checking
 if you have capacity to look at a few other test scenarios as well.

 Thanks,

 Greg S

 
 Message: 5
 Date: Fri, 09 May 2008 03:29:51 -0400
 From: Polychronis Ypodimatopoulos [EMAIL PROTECTED]
 Subject: 65-node simple mesh test (and counting... ;-)
 To: OLPC Development devel@lists.laptop.org, Sugar ml
[EMAIL PROTECTED], [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed

 Dear devel,

 Here are the latest results from Cerebro's (http://cerebro.mit.edu)
 scaling properties. A 65-node testbed was used (703, Q2D14). The
 NetworkManager had to be disabled in order to stabilize the behavior of
 each XO's wireless interface. Unfortunately, the difficulty and time
 necessary to manage increasingly more nodes is linear (given that the
 NetoworkManager is disabled ;-), but increases steeply.


 ** Test plan:
 Cerebro was started on all 65 laptops almost at the same time. We
 attempted to emulate the 65 children turn on their laptops in class at
 the same time scenario. With Yani's help, it took about 5 seconds for
 both of us to press 'enter' on all laptops. Each XO would discover each
 other, exchange profile information and keep exchanging
 presence/discovery information.


 ** Measurements:
 Quantitative:
 According to the protocol, presence (mac address) arrives about other
 XOs first, then the profile for the newly arrived mac address is queried
 and finally the profile is cached. We assume that initially each XO has
 no cached information about other XOs. As a result, every XO will query
 everyone else.
 We measured the time it took for each XO to discover and exchange
 profile information with everyone else, bandwidth usage at all times
 (during profile exchange and after the network stabilized when all
 profiles were received everywhere)

 Qualitative:
 Collaboration was tested on all 65 nodes: one shared a chat session,
 everyone else joined. The chat session was based on Cerebro's
 collaboration model.


 ** Results:
 Discovery and profile information:
 The following graph shows arrival of profile information at each XO from
 other XOs a function of time. Each bar is a 3-second bucket representing
 the average number of profile arrivals during this 3-second period. The
 standard

Re: 65-node simple mesh test (and counting... ;-)

2008-05-12 Thread Polychronis Ypodimatopoulos

Hi Bill,

Bill Mccormick wrote:
 The network manager could be the culprit here, although I thought you
 had it disabled, how did you disable it?
   

chkconfig --del NetworkManager

you'll need to pass the '--add' argument to restore it in rc5.

 When it's running it looks like it first looks on channel 1 for a DHCP
 server.   Then channel 6.   Then channel 11.  Then it tries to connect
 to the last known access point.   Then it does it all again.   This will
 take a bit of time...

 Only then does it assume that there is no DHCP server and switches to ad
 hoc mode on channel 1.
   

Does it also start looking at different intervals for a DHCP server 
after switching to ad-hoc mode?

Pol

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

OLPC wireless networking in the trade press

2008-05-12 Thread Carol Lerche

http://www.networkworld.com/news/2008/050908-wireless-mesh-standard-olpc-open-source.html?page=1
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: olpcfs next steps (was very simple datastore reimplementation)

2008-05-12 Thread C. Scott Ananian

On Fri, May 9, 2008 at 6:09 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
   The current implementation of indexes is incomplete, and there are
   some design questions regarding how search results for certain key
   types ought to be presented using the POSIX API.  These are not
   showstoppers, but I/we should finish the implementation before Journal
   search would be expected to work.

  Have you already thought about using something like Xapian for all the
  search needs? Eben will correct me, but I think that we want pretty
  advanced Google like search. Implementing all this on top of a
  berkeley db may mean duplicating a lot of work.

I think google like search may be a separate functionality on top of
the filesystem.  I'll think about this more.  The current search
functionality is based on exact searches, and it uses the same basic
datastructures we use for data storage in the filesystem.  Google
like searches seem like a very different thing, and I'm not sure it's
wise to mix them.  You really want something like Beagle, strigi, or
http://en.wikipedia.org/wiki/List_of_search_engines#Desktop_search_engines
for that, since you want to take apart a large number of
application-specific data formats to extract keywords and index those.
 olpcfs is concentrating on indexing explicit filesystem metadata,
like tags, not on the larger task of extracting and indexing full-text
from documents.

For not reinventing the wheel reasons, I'd prefer to see full-text
search be based on an existing desktop search engine.

   There are some journal integration questions, for
   example w.r.t. grouping objects by action -- if a number of files have
   'action_id' set to (say) 1, is there a file named '1' with mime-type
   'text/sugar-action' somewhere with more details about the action?
   That sort of thing is best figured out by actually hacking up some
   code and figuring out what extra information needs to be stored.

  Yes, we have some unfortunate uncertainty there. But how this affect olpcfs?

It doesn't, directly.  I was just trying to enumerate the list of
things to do.
 --scott

-- 
 ( http://cscott.net/ )
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: New network scripts/tools for testing

2008-05-12 Thread Giannis Galanis

On Mon, May 12, 2008 at 10:58 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote:

 Some small discrepancies in the output of the new 'olpc-netstatus':

 1) I have a wired connection.  (NO wireless.)  I do not understand why,
 but for some Joyride builds, the wired connection gets assigned to 'eth0',
 and for others it gets assigned to 'eth1'.  My current build (1932) assigns
 it to 'eth1'.  The result is 'olpc-connections' and 'olpc-netstatus' have
 NOTHING to report for 'eth0' (that interface is there, but does not have an
 IPv4 address).


olpc-netstatus should work either way. I see that it detected properly that
eth1 is your ethernet.
It should also work if it was the other way around.

it scans all eth*, and checks which has an IP.(now if both have an IP it
willonly choose one)

oh btw *I think*  eth1 shows as the wireless, when you upgrade the build
with the eth/usb adapter plugged in(not 100% sure)

about olpc-connections then this is a bug.
It is not smart enough to determine whether eth0/eth1 is active.
I will make sure this is fixed before i put on the build




 2) My connection goes through a proxy.  The result is that
 'olpc-connections' and 'olpc-netstatus' show the Proxy-system IP, where they
 claim to be showing the Jabber-system IP.


this i dont know how to fix.
perhaps there is nothing i can do. I will have to ask in 1cc



 3) (For nameserver?) 'olpc-netstatus' refers to /root/test.  My system
 has no such file.


oh this is a terrible mistake!
I was testing with a sample resolv.conf file and I forgot about it.
I updated it properly now on the wiki. Thanx alot!


Thanks alot for the feedback!
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

[PATCH stable] libertas: fix command resent to firmware after timeout.

2008-05-12 Thread Brian Cavagnolo

This is a fix for OLPC ticket #6586: SCAN command fails, timer doesn't fire In
fact, the timer was firing.  The problem was that the dnld_sent state variable
was not being updated after the timer expired, so lbs_execute_next_command was
not being called.

Signed-off-by: Brian Cavagnolo [EMAIL PROTECTED]
Signed-off-by: Javier Cardona [EMAIL PROTECTED]
---
 drivers/net/wireless/libertas/main.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/libertas/main.c 
b/drivers/net/wireless/libertas/main.c
index e012d08..f327383 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -771,6 +771,7 @@ static int lbs_thread(void *data)
 #endif
} else {
priv-cur_cmd = NULL;
+   priv-dnld_sent = DNLD_RES_RECEIVED;
lbs_pr_info(requeueing command %x due to 
timeout (#%d)\n,

le16_to_cpu(cmdnode-cmdbuf-command), priv-nr_retries);
 
-- 
1.5.2.5



___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Mind improving tool announcement

2008-05-12 Thread qwerty

Hello, everybody. I'd like to present you our project in OLPC.

Tool that we develop improves such system thinking skills as
generalizing, abstracting, decomposing.
The idea is to make the application as intuitive as possible with the
help of ideas of mind mapping and modeling software.
At first, children choose the topic of current modeling session. They
can take one of existing topics or create their own one.
After that, children use tool palette to create objects and
relationships between them in the context of the topic.
Each topic is represented by ontology so relationships and objects are
elements of topic ontologies.
Relationships can have properties (transitive, symmetric, functional,
inverse functional), and object can unite into classes.
When map is created in the workspace, children can ask questions about
it (about existing objects and their relations with far-away ones).
Ontology ideas are very close to the system thinking. With the ability
to represent properties, classes, individual
concepts etc in a simple and funny way this tool will be suitable for
entertaining and educating children.
We don't know yet what ontology language to use, it could be RDF or OWL.
Does anybody know something about similar projects? Or may be somebody
wants to join us?
At the moment we are working in a group of three.
Our UI Prototype here:
http://kkv.spb.su/doku.php?id=etc:teach:diplomants:projects:2009:olpcmind:artifacts:inception:requirements:uiprototype
Other artifacts are only in Russian, we will translate it, if it's
necessary.
Yura
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Arcade game

2008-05-12 Thread Jeck Landin

Hello, All.

I would llike to develop 2D arcade/shooter multiplayer game. Planned to
create multiple game modes, such as well-known Deathmatch, Capture the flag,
Domination, etc. But without violence and in child-oriented setting. For
example, different funny animals would jump across 2D map and fire each
other with bananas, coconuts and other fruits. The game will support the
connection and disconnection of players during the round, using
mesh-networking technology.  Perhaps I will add bots. Then I will work on
the development of graphic elements and special effects. Design of the game,
I wish to make in the children's style - bright colors, distinct pieces .I
have some experience in the creation of images and animations of this type.

Looking forward to your reply.

Evgeny Balandin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Release management for upcoming bug fix releases and August release

2008-05-12 Thread Kim Quirk

Development and Testing community,

We have started planning for the next SW releases.  The goal is a bug fix
release in a few weeks (8.1.1), and then the major August release (8.2.0).
[NOTE: the release numbers are based on my last reading of the numbering
convention... not sure if it is final.]

A high level view of this process:
1) Prioritize feature and bug fix requests from deployments, developers,
support, our sales/marketing group
2) Triage bugs to determine which bugs are critical to fix to meet the
priorities
3) Translate these requests into requirements, use cases, and trac items
(bug fixes or task items).

After that planning, a weekly meeting can be held to manage the high
priority items (Wed 2pm EDT).

Michael Stone volunteered to be the release manager for the 8.1.0 (Update.1)
release and is willing to continue through to the August release. He will
provide much needed communications, planning, help in unblocking technical
problems, and general project management. We are hiring people so I expect
we will have some help for Michael soon.

Don't hesitate to reply with thoughts or ideas on this process.

Regards,
Kim
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Release management for upcoming bug fix releases and August release

2008-05-12 Thread Marco Pesenti Gritti

On Tue, May 13, 2008 at 1:41 AM, Kim Quirk [EMAIL PROTECTED] wrote:
 Development and Testing community,

 We have started planning for the next SW releases.  The goal is a bug fix
 release in a few weeks (8.1.1), and then the major August release (8.2.0).
 [NOTE: the release numbers are based on my last reading of the numbering
 convention... not sure if it is final.]

A release schedule for 8.2.0 would be very useful to better sync Sugar
0.82 release dates with it..

 A high level view of this process:
 1) Prioritize feature and bug fix requests from deployments, developers,
 support, our sales/marketing group

Can we post the priorities on these mailing lists?

Thanks,
Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [sugar] Release management for upcoming bug fix releases and August release

2008-05-12 Thread Marco Pesenti Gritti

On Tue, May 13, 2008 at 1:41 AM, Kim Quirk [EMAIL PROTECTED] wrote:
 2) Triage bugs to determine which bugs are critical to fix to meet the
 priorities

I spent quite a bit of time on this today, for the Sugar UI modules.
Lots more to be done though...

Marco
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

45 matches

Mail list logo