Re: XO-1 Mesh support in F11, testing request

2009-09-19 Thread Mikus Grinbergs

Anyone interested in helping the last few steps in getting XO-1 mesh
support running again?


Sorry - but my news (testing mesh support in F11) is not good.

Could not run a Chat session using any F11-on-XO1 systems.  Don't 
know if it is a problem with Chat-65 itself, or with the interface. 
 I start Chat somewhere, and tell it to share with Neighborhood. 
All systems (802, os6) see that Chat icon on their own Neighborhood 
Views - and if in any system I click that icon, Chat launches.  But 
on (os6) systems, the Share with text in the activity header never 
gets greyed out - in other words, the Chat activity never goes 
on-line.  [Using only (802) systems, Chat works fine on those.]


Was able to get 'rsync' to transfer directories between (os6) 
systems, using the local mesh connection (IP address 169...). 
[Also was able to get 'rsync' to transfer directories between (os6) 
systems, using the local wireless connection (IP address 10...).]




But my overall impression of mesh support in F11 is that currently 
it is flaky.  One system ended up showing a blank screen whenever 
F1 (for Neighborhood View) was pressed (went back to normal after 
being rebooted).  Neighborhood view often showed invitations to 
chat even half an hour after the inviting system had been shut 
down.  Some systems connected quickly to the local mesh - others 
took many minutes of pulsing to do so.  Sometimes not all on-line 
systems showed in Neighborhood.  It was unpleasant whenever the mesh 
icons in Neighborhood stopped accepting clicks - all I could do was 
to reboot the system this happened on.  [IIRC, one of the ways to 
trigger this was to click on the (mesh) Frame icon's 'Disconnect' - 
there seemed to be no way to 'Connect' again.]




My personal desire is to *control* what is happening.  I realize 
that for kids (the primary user target), the more things get done 
hands off, the easier to use the product.  But that means that 
when things do not go as expected, users can be left helpless.  It 
was frustrating to see Chat launch but fail to show messages from 
others on its screen;  it was frustrating to see Neighborhood View 
showing the same information as before, when I knew things had 
changed;  it was frustrating to not be able to turn mesh back on, 
when it appeared to have given up.



mikus


p.s.  attachment shows some meshbox messages

1253325333.007362 DEBUG sugar.presence.presenceservice: Created proxy Buddy 
object at 0x95282d4 (sugar+presence+buddy+Buddy at 0x90ff160)
** (sugar-session:1959): DEBUG: starting phase 1

** (sugar-session:1959): DEBUG: ending phase 1

** (sugar-session:1959): DEBUG: starting phase 2

** (sugar-session:1959): DEBUG: ending phase 2

** (sugar-session:1959): DEBUG: starting phase 3

** (sugar-session:1959): DEBUG: ending phase 3

** (sugar-session:1959): DEBUG: starting phase 4

** (sugar-session:1959): DEBUG: ending phase 4

** (sugar-session:1959): DEBUG: starting phase 5

** (sugar-session:1959): DEBUG: ending phase 5

1253325333.503768 DEBUG root: STARTUP: Loading the desktop window
1253325333.628769 DEBUG root: STARTUP: Loading the home view
1253325333.631072 DEBUG root: STARTUP: Loading the favorites view
1253325339.292493 DEBUG root: FavoritesSetting layout 'spiral-layout'
1253325339.296294 DEBUG root: Icon without fixed_position: _MyIcon object at 
0x95285a4 (SugarFavoritesMyIcon at 0x94b2c90)
1253325339.298559 DEBUG root: Icon without fixed_position: CurrentActivityIcon 
object at 0x9528874 (CanvasIcon at 0x94b2d08)
1253325339.300673 DEBUG root: STARTUP: Loading the activities list
1253325339.696847 DEBUG root: ('Setup widget', gtk.RadioButton object at 
0x9528f54 (GtkRadioButton at 0x922a940))
1253325339.704580 WARNING root: No gtk.AccelGroup in the top level window.
1253325339.744635 DEBUG root: ('Setup widget', gtk.RadioButton object at 
0x95319b4 (GtkRadioButton at 0x922ac40))
1253325339.751851 WARNING root: No gtk.AccelGroup in the top level window.
1253325339.757904 DEBUG root: STARTUP: Loading the group view
1253325339.770991 DEBUG sugar.presence.presenceservice: Reused proxy Buddy 
object at 0x95282d4 (sugar+presence+buddy+Buddy at 0x90ff160)
1253325339.906036 DEBUG root: STARTUP: Loading the mesh view
1253325340.229738 DEBUG root: Not an activity icon _MyIcon object at 0x95285a4 
(SugarFavoritesMyIcon at 0x94b2c90)
1253325340.232643 DEBUG root: Not an activity icon CurrentActivityIcon object 
at 0x9528874 (CanvasIcon at 0x94b2d08)
1253325340.368353 DEBUG root: activate channel 1 anycast \xc0'\xc0'\xc0\x00
1253325341.537885 DEBUG root: Connection activated: 
/org/freedesktop/NetworkManager/ActiveConnection/1
1253325341.583291 DEBUG sugar.presence.presenceservice: Reused proxy Buddy 
object at 0x95282d4 (sugar+presence+buddy+Buddy at 0x90ff160)
Traceback (most recent call last):
  File /usr/lib/python2.6/site-packages/dbus/connection.py, line 586, in 
msg_reply_handler
reply_handler(*message.get_args_list(**get_args_opts))
  File 

Re: XO-1 Mesh support in F11, testing request

2009-09-19 Thread Daniel Drake
2009/9/19 Mikus Grinbergs mi...@bga.com:
 Anyone interested in helping the last few steps in getting XO-1 mesh
 support running again?

 Sorry - but my news (testing mesh support in F11) is not good.

Thanks for the feedback. I think we can summarize the problems into a
few groups:

 - activity/presence/telepathy level problems (e.g. your inability to
chat successfully) that are on a different level of the stack from the
work I've been doing
 - a Sugar bug where the neighborhood view becomes partially or wholly
unresponsive to clicks (I saw this twice, even before modifying to add
mesh support)
 - some mesh connectivity issues related to
http://thread.gmane.org/gmane.linux.network.networkmanager.devel/13607
(related to my work, but to be tackled separately)

I'll move forward on getting my work into NM-0.7 and F11, which will
then enable more people to help fix the other issues you have found.

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


Re: 0.84 for XO-1

2009-09-19 Thread Mikus Grinbergs
 ... testing seems like something that is needed, though I would like to
 know what is required in order to say that one of these builds is
 ready to be deployed somewhere.

The __principal__ thing that keeps me from recommending one of these
builds is lack of moving pictures output.  ['Record' not showing
(real_time) what the XO-1 camera sees is a symptom of this problem.]


 - Camera is not working
 
 That's kernel, Video4Linux driver?

I use various multimedia video applications (for instance, 'mplayer' 
to view movies).  On F7- and F9-based builds, these worked fine on 
the XO-1.  Joyride 2602 (F10-based) was the last build that showed 
correct output.  From then on, I am instead on the XO-1 being shown 
a blank (perhaps dark green) screen, or maybe occasional distorted 
still picture snapshots from the input material, with notations 
about the CPU being too slow to produce the desired output.

Since what happened right after Joyride 2602 was an upgrade to
xorg-x11-drv-geode - that's where I think the bad behavior started.


mikus


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


Re: Smile activity version 1

2009-09-19 Thread Wade Brainerd
Hi Tony,
Sorry for taking so long to respond to this one.

I had a similar problem in Colors! and solved it by adding a timer event
while playback was running:

1350def start_update_timer(self):
1351if self.update_timer:
1352gobject.source_remove(self.update_timer)
1353
1354# The timer priority is chosen to be above PRIORITY_REDRAW
(which is PRIORITY_HIGH_IDLE_20, but not defined in PyGTK).
1355self.update_timer = gobject.timeout_add(1, self.update,
priority=gobject.PRIORITY_HIGH_IDLE+30)

The update event would trigger a paint event and return True when playback
was active, else return False if playback was done.  When playback was
started again it would start the timer running again.  This starting and
stopping prevents pegging the CPU all the time.

Anyway, this might help solve your problem by forcing the event loop to run,
although it does sound like the root problem could be a different issue.

Best,
Wade

On Thu, Sep 3, 2009 at 12:02 PM, Tony Anderson t...@olenepal.org wrote:

 Hi,

 I am always tempted to blame my code, but the same problem appeared
 in the Ambulant demo wrapper (player_pygtk.py) on Ubuntu. It appears only
 in the python wrapper (not the C++ version). The Ambulant team has opened a
 ticket. The problem appears to be an interaction between the gtk.main()
 event loop and the Ambulant redraw logic. Player_pygtk.py doesn't call
 gtk.main but instead uses a loop:

 while gtk.events_pending():
   gtk.main_iteration()

 I think it is safe to rule out Sugar as a culprit, but not my building of
 the Ambulant package!

 Yours,

 Tony



 Tomeu Vizoso wrote:

 On Wed, Sep 2, 2009 at 18:31, Tony Andersont...@olenepal.org wrote:


 I posted version 1 of the Smile activity to activities.sugarlabs.org. It
 matches the code posted on gitorious.

 The Smile activity implements the open source Ambulant SMIL3 player. It
 plays a variety of media types. More importantly it can play a complex
 multimedia presentation including text, images, audio, and video using a
 standard SMIL script.

 My goal is to use the Smile activity to play children's stories so that
 they can see the text highlighted karaoke-style while listening to the
 story's audio track and looking at background images.

 Similar to the Quiz and ShowNTell activities, the Smile activity plays a
 bundle with an extension '.smxo' and mime_type 'application/x-smile'
 which contains the controlling SMIL script and the associated media
 files.

 Version 1 has two serious problems. Video playback and multimedia
 playback does not redraw correctly (playback is advanced by moving the
 mouse!). In addition, it is possible to replay only be re-selecting the
 presentation. The pause and stop buttons do not work correctly.

 I hope that both of these problems will be resolved in version 2 by the
 end of September.



 Hi Tony,

 do you know if the cause for these problems in the Ambulant SMIL3
 player or in the activity code?

 Regards,

 Tomeu





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


Re: [Sugar-devel] Smile activity version 1

2009-09-19 Thread David Farning
By way of introduction for the newer contributors--

Wade started and was the first co-ordinator of the Activities Team.
He took a break last spring for the birth of a child:)  I wonder if he
has looked at activities.sugarlabs.org lately. It has had over 680,000
activity downloads, most of them since June.

Congratulation on the baby and starting something pretty cool.

david

On Sat, Sep 19, 2009 at 8:42 PM, Wade Brainerd wad...@gmail.com wrote:
 Hi Tony,
 Sorry for taking so long to respond to this one.
 I had a similar problem in Colors! and solved it by adding a timer event
 while playback was running:
 1350    def start_update_timer(self):
 1351        if self.update_timer:
 1352            gobject.source_remove(self.update_timer)
 1353
 1354        # The timer priority is chosen to be above PRIORITY_REDRAW
 (which is PRIORITY_HIGH_IDLE_20, but not defined in PyGTK).
 1355        self.update_timer = gobject.timeout_add(1, self.update,
 priority=gobject.PRIORITY_HIGH_IDLE+30)
 The update event would trigger a paint event and return True when playback
 was active, else return False if playback was done.  When playback was
 started again it would start the timer running again.  This starting and
 stopping prevents pegging the CPU all the time.
 Anyway, this might help solve your problem by forcing the event loop to run,
 although it does sound like the root problem could be a different issue.
 Best,
 Wade

 On Thu, Sep 3, 2009 at 12:02 PM, Tony Anderson t...@olenepal.org wrote:

 Hi,

 I am always tempted to blame my code, but the same problem appeared
 in the Ambulant demo wrapper (player_pygtk.py) on Ubuntu. It appears only
 in the python wrapper (not the C++ version). The Ambulant team has opened a
 ticket. The problem appears to be an interaction between the gtk.main()
 event loop and the Ambulant redraw logic. Player_pygtk.py doesn't call
 gtk.main but instead uses a loop:

 while gtk.events_pending():
   gtk.main_iteration()

 I think it is safe to rule out Sugar as a culprit, but not my building of
 the Ambulant package!

 Yours,

 Tony


 Tomeu Vizoso wrote:

 On Wed, Sep 2, 2009 at 18:31, Tony Andersont...@olenepal.org wrote:


 I posted version 1 of the Smile activity to activities.sugarlabs.org. It
 matches the code posted on gitorious.

 The Smile activity implements the open source Ambulant SMIL3 player. It
 plays a variety of media types. More importantly it can play a complex
 multimedia presentation including text, images, audio, and video using a
 standard SMIL script.

 My goal is to use the Smile activity to play children's stories so that
 they can see the text highlighted karaoke-style while listening to the
 story's audio track and looking at background images.

 Similar to the Quiz and ShowNTell activities, the Smile activity plays a
 bundle with an extension '.smxo' and mime_type 'application/x-smile'
 which contains the controlling SMIL script and the associated media
 files.

 Version 1 has two serious problems. Video playback and multimedia
 playback does not redraw correctly (playback is advanced by moving the
 mouse!). In addition, it is possible to replay only be re-selecting the
 presentation. The pause and stop buttons do not work correctly.

 I hope that both of these problems will be resolved in version 2 by the
 end of September.


 Hi Tony,

 do you know if the cause for these problems in the Ambulant SMIL3
 player or in the activity code?

 Regards,

 Tomeu





 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel


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


[Server-devel] server ecurity

2009-09-19 Thread Henry Vélez Molina
Hi everyone

Our server is working very good with 0.5.2 version. But now, we have a big
network in  the neighborhood that is coming to the children´s houses through
each access point. For that reason we need to have a big security on the
server to prevent access to unknown users to internet.


What could be the best solution for this?
is there any way to get this with a transparent  way for the XOs?
maybe through Squid and ejabberd?

Thanks for your help.




-- 
Henry Vélez Molina
Administrador de red OLPC
Fundación MArina Orth
Tel :341 23 59
Móvil: 312 769 0169
www.fundacionmarinaorth.org
___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel