Re: LZO support

2008-07-20 Thread NoiseEHC
Okay, I have become a little more advanced lately, and was able to 
compile the kernel zlib and lzo in userspace (last year I gave up...).

So here is the code (with results, the lib file is the compiled lzo 2.03):
http://wiki.laptop.org/images/5/5b/Zlibtest5.tar.gz

Since I did not find any assembly compressor support (only 
decompressor), I do not know what did I talked about last time. It could 
have been that I have been dreaming about that...

The program needs a test.dat file, I have used cat */*test.dat in 
/var/lib which gave me a 22 MB file (the code handles a max of 40 MB). 
The results are consistent with Erik's results. Since ZLIB has a 
compression level parameter, and LZO has different compressor types, I 
will test those as well.

Now I think that jffs2 (or any other flash filesystem) should use LZO to 
store the data, so if the limit is the flash write speed then it could 
write twice as fast. Later, when there is ample power in the battery and 
no cpu utilization, it should recompress the data either using a better 
LZO or by ZLIB (of course only those files which are old enough, so it 
would not recompress files which will be modified soon).

And the results:
started with block size == 4096

LZO test
in size: 22987994
22987994 - 11575529 (50.354672%)
1.96 seconds - 11.185234 MB/sec
11575529 - 22987994
0.75 seconds - 29.230745 MB/sec
compared 22987994 bytes OK

LZO asm test
in size: 22987994
22987994 - 11575529 (50.354672%)
1.93 seconds - 11.359098 MB/sec
11575529 - 22987994
0.49 seconds - 44.740936 MB/sec
compared 22987994 bytes OK

ZLIB test
in size: 22987994
22987994 - 8982973 (39.076802%)
9.81 seconds - 2.234767 MB/sec
8982973 - 22987994
2.75 seconds - 7.972022 MB/sec
compared 22987994 bytes OK


Greg Smith wrote:
 Hi Erik,

 Can you design a test case or two to test the performance of these 
 compression schemes?

 Thanks,

 Greg S

 ___
 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: PlayGo Patches/Commit access

2008-07-20 Thread Tomeu Vizoso
2008/7/20 Andrés Ambrois [EMAIL PROTECTED]:
 On Saturday 19 July 2008 21:25:55 Nate Ridderman wrote:
 Andrés,

 Go is one of my favorite games, so I'm excited to see that someone has
 picked up development again! It requires such balance between
 aggressiveness and defense, as well as local play vs spreading out on the
 board - I think it's a great game for kids to learn. I look forward to
 trying out a new version, and I agree that collaboration is an important
 problem to tackle soon. Adding GnuGo (http://www.gnu.org/software/gnugo/)
 support would be a great addition too. It would be nice to support GnuGo
 and collaboration over the same networking framework, but I don't know
 enough about the
 collaboration framework and Bitfrost to know if this is a possibility.
 GnuGo generally runs as it's own process and communicates over GTP (
 http://www.gnu.org/software/gnugo/gnugo_19.html#SEC196).

 It seems there's a lack of documentation for people like yourself who want
 to pick up development on an existing activity. Most people who want shell
 access to dev.laptop.org also want to host a new activity. I wasn't able to
 find anything on the wiki about requesting shell access. Maybe putting a
 blurb on the wiki about who to contact would be helpful.

 Nate

 Dear Nate,

  Thanks for your interest! I also like Go a lot, even though I'm very bad at
 it! :P. I also think it's a great game for kids, most strong go players start
 very young, and a lot turn pro before age 15.
  GnuGo integration is certainly the way to go (no pun intended XD), maybe we
 can use a local gnugo instance speaking GTP with the Activity, for what I
 see, it shouldn't be too hard. The standard API for sharing (Telepathy tubes)
 can be used by the host to tell the other player what's going on. I'm just
 thinking out loud here, as I yet have to delve into the sharing API. Maybe
 one of the experts here can give us some pointers :).

Normally I would recommend to move the part of gnugo that can be of
interest to embedders to a shared lib and then do python bindings for
it. But looks like gnugo already has covered the embedding use case
with GTP:

http://en.wikipedia.org/wiki/Go_Text_Protocol

So that should just work.

Good luck,

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


Re: experiencing unexpected OLPC behavior from a misplaced click

2008-07-20 Thread Greg Smith
Hi Mikus,

I didn't mean to put you in a difficult position.

I assume that if the XO doesn't do what the user expects its a bug 
(maybe a low priority one). No problem if you don't want to file this one.

Can you write a brief blurb in the 8.2.0 release notes to preserve the 
knowledge. Maybe just text, no bug ID in 
http://wiki.laptop.org/go/Release_Notes/8.2.0#Notable_Open_Bugs_In_This_Release

I'm not trying to push you into anything you are not comfortable with.

You're making a great contribution and its making a big difference to 
the quality of the product! Please keep the comments and work coming, 
regardless of any communication faux pas on my part.

Thanks,

Greg S


Date: Sat, 19 Jul 2008 14:25:39 -0400
From: Mikus Grinbergs [EMAIL PROTECTED]
Subject: experiencing unexpected OLPC behavior from a misplaced click
To: devel@lists.laptop.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

I posted about an experience I had, where I was surprised to find
that my OLPC had become unresponsive.  My reason for posting was to
alert others that surprises may be lurking for OLPC users.



Greg, you quoted my post, and wrote:
   Can you file a bug on this (dev.laptop.org) and include steps to
   reproduce and test?

I am put into a difficult position when I see comments like this.
If I am prevented from doing something by the current behavior of
the OLPC, and would like that behavior changed to allow me to go
ahead and do the thing I wanted, *then* I will write a ticket.


But here is a case where I did not wait long enough for the OLPC to
draw a pop-up palette, and did not make sure that the cursor was
correctly positioned on the appropriate entry in that palette,
before I 'clicked'.  In other words, it was __I__ who misbehaved.

It is my intention to *not* write a ticket on this.  Aside from the
__user's__ behavior needing to be corrected, I'm not sure what else
would be ticketable ??

It might help impatient users if palettes (e.g., in the Journal
screen) were 'instantaneous' instead of 'slow' --  but I imagine the
graphics speed is established by the OLPC processing capability (low
power draw is imperative) and the overall Sugar GUI 'Look_And_Feel'
design -- and can't be changed.  I see nothing in this particular
situation for which writing a ticket would improve matters.


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


Re: running speech-dispatcher as non-root using setuid on XO and accompanying security issues

2008-07-20 Thread Hemant Goyal
Hi James,

The point I was trying to make was that the Sugar API itself could have
 removed the burden of setting these options from the developer.


Yes that is indeed what is happening :). And there is no API call involved
whatsoeverl with the present design :). Perhaps once the code is released
you'll get an idea whats exactly happening.


 An Activity could also, using the API, find out what the default values are
 without having to look at speechd.conf.


I think it would be useful for the activity developer in certain instances
to get the default speech synthesis settings. I'll look into this
requirement  and see if we can provide some methods through sugar for this
purpose.


 Or the Sugar Activity base class could automatically start up a speech
 client and give the Activity developer simple methods to use it in his
 application, or even automatically speech enable any Activity so that for
 instance the contents of the control with the focus could be spoken, or
 whatever it is that screen readers for the blind do.


Well, the main reason why sugar does not/should not handle requests for
speech-synthesis from all Activities is that we will need to re-write a  lot
of code to handle priorities/serializing speech synth requests from multiple
activities/maintaining Activitiy-specific settings (these were issues with
the initial DBUS API that we created, and the main reason for shifting to
speech-dispatcher). All these features are already available in
speech-dispatcher and hence communicating directly with the
speech-dispatcher server instead through sugar seems more optimal.

Also if Activities had to connect to a client that was started by sugar
would mean that sugar will have to provide the Callbacks that are at present
returned by speech-dispatcher directly to the Activity.

Thats why its best that Activities connect themselves to speech-dispatcher
and not communicate through sugar.

Automatically speech-enabling an activity is something I will be exploring,
however, from initial analysis its not that straight forward. How sugar will
hack into Activities and pull the data relevant for speech-synth is what
needs to be analyzed for this purpose.

I understood that the Sugar developers wanted to provide text to speech
 support to all Activities, even those written before TTS was available.  To
 do that you would have to change the Sugar base classes, etc. anyway.


Are you suggesting that just like the Activity Tool bars etc are provided to
Sugar Activities primitively, speech-synth should be provided primitively
when each Activity starts?

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


Re: Autosave in 8.2.0?

2008-07-20 Thread Bert Freudenberg
Am 17.07.2008 um 07:37 schrieb Bert Freudenberg:

 Am 17.07.2008 um 00:10 schrieb Tomeu Vizoso:

 Marco has added a session manager to Sugar (in 8.2.0) that takes care
 of telling activities to save their work because the system is being
 shut down. Haven't verified if this is complete and working. Have  
 you,
 Marco? If so, this would also take care of the case where kids shut
 down before closing all running activities first.


 How does this work from an activity's pov?

 - Bert -


Thanks for not answering, and not updating the API doc, and me having  
to dig through Sugar patches to find out how this works.

I updated the doc:
http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods
===
org.laptop.Activity.SyncData()
Called when the laptop is about to shutdown, reboot, or suspend. The  
activity must save its state in the datastore.
===
Apparently this does not send a reason for having to sync - IMHO  
suspend is not as severe a reason as impending shutdown/reboot so an  
activity might want to choose to not save on suspend if suspends are  
as frequent as we anticipate.

- Bert -


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


Re: [sugar] Autosave in 8.2.0?

2008-07-20 Thread Marco Pesenti Gritti
On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Thanks for not answering,

Hmm? Both Tomeu and me answered.

http://lists.laptop.org/pipermail/devel/2008-July/016914.html
http://lists.laptop.org/pipermail/devel/2008-July/016951.html

 and not updating the API doc,

The time I can devote to OLPC is *very* limited these days and I had
no time until today to even check this API was working properly... I
just finished up the python Activity bits and I have a patch up for
review. I will try to update the doc on monday.

 and me having
 to dig through Sugar patches to find out how this works.

 I updated the doc:
 http://wiki.laptop.org/go/Low-level_Activity_API#D-Bus_Methods
 ===
org.laptop.Activity.SyncData()
Called when the laptop is about to shutdown, reboot, or suspend. The
 activity must save its state in the datastore.
 ===
 Apparently this does not send a reason for having to sync - IMHO
 suspend is not as severe a reason as impending shutdown/reboot so an
 activity might want to choose to not save on suspend if suspends are
 as frequent as we anticipate.

This code never went in actually... See the mails I referenced.

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


Re: [sugar] Autosave in 8.2.0?

2008-07-20 Thread Tomeu Vizoso
On Sun, Jul 20, 2008 at 5:44 PM, Bert Freudenberg [EMAIL PROTECTED] wrote:
 Am 17.07.2008 um 07:37 schrieb Bert Freudenberg:

 Am 17.07.2008 um 00:10 schrieb Tomeu Vizoso:

 Marco has added a session manager to Sugar (in 8.2.0) that takes care
 of telling activities to save their work because the system is being
 shut down. Haven't verified if this is complete and working. Have
 you,
 Marco? If so, this would also take care of the case where kids shut
 down before closing all running activities first.


 How does this work from an activity's pov?

 - Bert -


 Thanks for not answering, and not updating the API doc, and me having
 to dig through Sugar patches to find out how this works.

Bert, you should know better than others how things are here. We
cannot manage to do the things we know that must be done, much less we
can do those properly. If I was in any regular job, I would limit
myself to do what I can, and do it right. Here we just cannot behave
like that.

You are right to be frustrated by this situation, but please don't ask
us to do more than what is in our hands. If you know anyone who would
like to join us in this craziness, please point them to
http://www.laptop.org/en/jobs.shtml .

Regards,

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


Re: LZO support

2008-07-20 Thread Erik Garrison
How are you producing the test data (test.dat) used by the test?

On Sun, Jul 20, 2008 at 10:57:37AM +0200, NoiseEHC wrote:
 Okay, I have become a little more advanced lately, and was able to  
 compile the kernel zlib and lzo in userspace (last year I gave up...).

 So here is the code (with results, the lib file is the compiled lzo 2.03):
 http://wiki.laptop.org/images/5/5b/Zlibtest5.tar.gz

 Since I did not find any assembly compressor support (only  
 decompressor), I do not know what did I talked about last time. It could  
 have been that I have been dreaming about that...

 The program needs a test.dat file, I have used cat */*test.dat in  
 /var/lib which gave me a 22 MB file (the code handles a max of 40 MB).  
 The results are consistent with Erik's results. Since ZLIB has a  
 compression level parameter, and LZO has different compressor types, I  
 will test those as well.

 Now I think that jffs2 (or any other flash filesystem) should use LZO to  
 store the data, so if the limit is the flash write speed then it could  
 write twice as fast. Later, when there is ample power in the battery and  
 no cpu utilization, it should recompress the data either using a better  
 LZO or by ZLIB (of course only those files which are old enough, so it  
 would not recompress files which will be modified soon).

 And the results:
 started with block size == 4096

 LZO test
 in size: 22987994
 22987994 - 11575529 (50.354672%)
 1.96 seconds - 11.185234 MB/sec
 11575529 - 22987994
 0.75 seconds - 29.230745 MB/sec
 compared 22987994 bytes OK

 LZO asm test
 in size: 22987994
 22987994 - 11575529 (50.354672%)
 1.93 seconds - 11.359098 MB/sec
 11575529 - 22987994
 0.49 seconds - 44.740936 MB/sec
 compared 22987994 bytes OK

 ZLIB test
 in size: 22987994
 22987994 - 8982973 (39.076802%)
 9.81 seconds - 2.234767 MB/sec
 8982973 - 22987994
 2.75 seconds - 7.972022 MB/sec
 compared 22987994 bytes OK


 Greg Smith wrote:
 Hi Erik,

 Can you design a test case or two to test the performance of these  
 compression schemes?

 Thanks,

 Greg S

 ___
 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: LZO support

2008-07-20 Thread Erik Garrison
On Sun, Jul 20, 2008 at 04:38:36PM -0400, Erik Garrison wrote:
 How are you producing the test data (test.dat) used by the test?

Excuse me.  You clearly stated that in your email!

 
 On Sun, Jul 20, 2008 at 10:57:37AM +0200, NoiseEHC wrote:
  The program needs a test.dat file, I have used cat */*test.dat in  
  /var/lib which gave me a 22 MB file (the code handles a max of 40 MB).  
  The results are consistent with Erik's results. Since ZLIB has a  
  compression level parameter, and LZO has different compressor types, I  
  will test those as well.
 
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel


Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)

2008-07-20 Thread Gary C Martin
On 20 Jul 2008, at 13:40, Bobby Powers wrote:

 On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso  
 [EMAIL PROTECTED] wrote:
 Works quite well here in a MP with last joyride. Just did some light
 testing, though.

 I've also tested it (lightly) on 3 machines running Joyride ~2170.

 Tomeu

 On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender [EMAIL PROTECTED] 
  wrote:
 Not good news. I don't recall that anything should have changed
 between B4 and the C series that would have impacted Record. I'll  
 have
 to check it out on more machines...

 -walter

 On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin  
 [EMAIL PROTECTED] wrote:
 On 19 Jul 2008, at 00:18, Walter Bender wrote:

 (Now that we have a reasonably stable joyride-with a working  
 Record
 activity again-I'll try to get a quick user study pulled  
 together in
 Peru on this topic by someone less bias than myself.)

 Hmmm, not convinced Record-55 is working well enough yet  
 (Joyride-2174),
 unless it's just failing on my B4 hardware. I get everything from  
 a black
 feed, to a green/purple stripy feed. Not managed to actually  
 record anything
 with it yet. Doesn't seem to help launching Record first after a  
 reboot and
 with no other activities (think that was one of the open bugs).

 just did that (boot then launch record) and it worked alright for me
 (on a MP machine).

 bobby

Thanks for all the feedback.

OK, after a lot of testing and looking through logs I finally  
accidently stumbled on the problem. It seems to be a HW fault on my  
B4. Perhaps a dry solder joint, cracked pcb or camera component not  
seated correctly. If I squeeze the right side of the screen, just  
below the camera lense, Record-55 starts displaying the video image,  
sometimes blank, sometimes green/purple, sometimes back to normal.  
Managed to successfully recorded a video clip while the image was good.

I'm reasonably handy with a soldering iron so I'll open up the unit  
and see if I can see the specific cause. Is there a specific place I  
should report this HW issue incase it is more than single an unlucky  
occurrence?

--Gary


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


Re: Report on `views with many icons' profiling

2008-07-20 Thread riccardo
On Sat, 2008-07-19 at 11:49 +0200, Tomeu Vizoso wrote:
 This is really awesome, congrats.
 
thanks !

 I would like to know how much time takes every switch (including the
 redraw), is that 130ms and 170ms? Looks like it should be more to me.
for the ring layout:
favorite's view - list view : avg 0.15 sec
list view - favorite's view : avg 0.15 sec

for the freeform layout:
favorite's view - list view : avg 0.16 sec
list view - favorite's view : avg 0.85 sec

In fact the 170ms value can be lowered but it makes very difficult to
see whether both views are always redrawn or if sometimes one of the two
is jumped (in the case of the freeform layout the screen is gray blank
most of the time).

 Also, would like to see as well a top-down analysis, which are the top
 3-5 high level operations that take most CPU? Are they executed more
 often than what would be strictly needed? I see in kcachegrind that
 _views_switch_...() was called 2481 times, this means that your script
 switched that many times?

Yes, 2481 is the number of times the views were switched.

I think one can say that there's only one high-level operation: the call
to _set_view in HomeBox.py; what happens as a consequence(/`parallel
effect') is the firing of expose events and thus all the time that
cProfile assigns to cairo and that sysprof shows in geode_drv.so.

One thing I noted particularly is that 77% of the time of _set_view time
goes to enable_xo_palette in sugar/view/home/favoritesview.py. It seems
to me this last function is creating a new palette at every call
(re-doing quite a bit of work scattered on various packages). I guess
this can be done just once ?

For the ring layout case, all the rest looks ok to me or not worth
optimizing.

 
 Can you please try to assess the impact to the user of any slowness we
 may have in there?
--ring layout --
Perhaps we should ask the kids if they notice too much delay. I don't
think so, this `transition' is much faster than those to other views.

--freeform layout--
No need to ask ;)


  Which are in your opinion the next steps we should
 take?
- see if all the time in enable_xo_palette can be spared
- use box2d for the freeform layout; I guess that any naive algorithm
*handling* collision detection would perform worse than box2d and any
non naive one (really handling collisions) isn't worth the time.

 Thanks,
 
 Tomeu
 
 [Sorry about the late replies]
 
:)

thanks,
riccardo


 On Thu, Jul 17, 2008 at 7:43 PM, riccardo [EMAIL PROTECTED] wrote:
  Hi,
 
  Problem: slow switching between views with many icons
 
  Test-case: the test consist of switching between the favorites view and
  the list view. Test were ran once with the ring layout in the favorite
  view and once with the freeform layout; the xo had 25 activities
  installed all checked as `favorite'. The action of switching was
  automated with a timer with period 130ms when the ring layout was
  selected and 170ms in the case of the freeform layout (as the minimum
  values permitting complete redraw of the views).
 
  Note that there is a noticeable delay when switching to the favorites
  views when the selected layout is freeform.
 
 
  --- RING layout ---
  The following tab. and fig. show cpu time usage of the processes
  taking more cpu time while running the test:
 
  (tot% us+sy) - (partial% us+sy) : cmdline
  - 63.6 : python /usr/bin/sugar-shell
   91.2- 27.5 : /usr/bin/X :0 -fp built-ins...
   99.5- 8.2  : picker -t30
 
  http://dev.laptop.org/~rlucchese/views/favorites_ring-list/picker.stats.svg
  (http://dev.laptop.org/~rlucchese/views/favorites_ring-list/picker.stats )
 
  They were obtained by running:
  $ picker -t30
  $ grapher -c3
 
  --- FREEFORM layout ---
  (tot% us+sy) - (partial% us+sy) : cmdline
  - 82.  : python /usr/bin/sugar-shell
   91.6- 9.5  : /usr/bin/X :0 -fp built-ins...
   99.4- 7.7  : picker -t30
 
  http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/picker.stats.svg
  (http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/picker.stats
   )
 
   ! sugar-shell is taking 20% more cpu time than in the ring layout case.
 
 
 
  cProfile statistics (KCacheGrind format) for sugar-shell:
  --- RING layout ---
  http://dev.laptop.org/~rlucchese/views/favorites_ring-list/cProfile-shell
 
  Ordering by function's self-time:
   %  func name
  35.6   : cairo.Context.paint
  3.9: gtk.Container.add
  2. : sugar.graphics.palette.do_paint_below_children
  1.9: __setitem__ sugar.util
  --
  57%
 
  Well, this isn't unexpected. But it's interesting when looking at
  sysprof results (below).
 
  --- FREEFORM layout ---
  http://dev.laptop.org/~rlucchese/views/favorites_freeform-list/cProfile-shell
 
  Ordering by function's self-time:
   %  func name
  21.6   : _add_weight in sugar/shell/view/home/grid.py
  21.5   : 

Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)

2008-07-20 Thread John Watlington

Take a look at:
http://wiki.laptop.org/go/ 
XO_Troubleshooting_AV#Errors_communicating_with_the_camera

The majority of these problems are due to a latch on the flex cable  
connector coming loose.
If you disassemble the laptop, and find that it was due to another  
source, pleased either
add it to the guide or let me know.

Cheers,
wad

On Jul 20, 2008, at 5:40 PM, Gary C Martin wrote:

 On 20 Jul 2008, at 13:40, Bobby Powers wrote:

 On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso
 [EMAIL PROTECTED] wrote:
 Works quite well here in a MP with last joyride. Just did some light
 testing, though.

 I've also tested it (lightly) on 3 machines running Joyride ~2170.

 Tomeu

 On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender  
 [EMAIL PROTECTED]
 wrote:
 Not good news. I don't recall that anything should have changed
 between B4 and the C series that would have impacted Record. I'll
 have
 to check it out on more machines...

 -walter

 On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin
 [EMAIL PROTECTED] wrote:
 On 19 Jul 2008, at 00:18, Walter Bender wrote:

 (Now that we have a reasonably stable joyride-with a working
 Record
 activity again-I'll try to get a quick user study pulled
 together in
 Peru on this topic by someone less bias than myself.)

 Hmmm, not convinced Record-55 is working well enough yet
 (Joyride-2174),
 unless it's just failing on my B4 hardware. I get everything from
 a black
 feed, to a green/purple stripy feed. Not managed to actually
 record anything
 with it yet. Doesn't seem to help launching Record first after a
 reboot and
 with no other activities (think that was one of the open bugs).

 just did that (boot then launch record) and it worked alright for me
 (on a MP machine).

 bobby

 Thanks for all the feedback.

 OK, after a lot of testing and looking through logs I finally
 accidently stumbled on the problem. It seems to be a HW fault on my
 B4. Perhaps a dry solder joint, cracked pcb or camera component not
 seated correctly. If I squeeze the right side of the screen, just
 below the camera lense, Record-55 starts displaying the video image,
 sometimes blank, sometimes green/purple, sometimes back to normal.
 Managed to successfully recorded a video clip while the image was  
 good.

 I'm reasonably handy with a soldering iron so I'll open up the unit
 and see if I can see the specific cause. Is there a specific place I
 should report this HW issue incase it is more than single an unlucky
 occurrence?

 --Gary


 ___
 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


current olpc-2.6 git tree Makefile minor patch

2008-07-20 Thread Hero_xbd!.RRR
Hey.

I found there is parenthesis mismatching in olpc-2.6/Makefile, which 
causes make help to fall.

I figured it out but do have the permission to git commit.

Cheers!



diff --git a/Makefile b/Makefile
index 9652cc5..5d87deb 100644
--- a/Makefile
+++ b/Makefile
@@ -1236,7 +1236,7 @@ help:
echo '')
@$(if $(boards), \
$(foreach b, $(boards), \
- printf  %-24s - Quiet Build for %s\\n $(subst 
_defconfig,_silentdefconfig,$(b)) $(subst _defconfig,,$(b));) \
+ printf  %-24s - Quiet Build for %s\\n $(subst 
_defconfig,_silentdefconfig,$(b)) $(subst _defconfig,,$(b));))
@$(if $(board-dirs), \
$(foreach b, $(board-dirs), \
printf  %-16s - Show %s-specific targets\\n help-$(b) $(b);) \



-- 
续本达
Xu, Benda

Academic Talent Program on
Fundamental Science of Mathematics and Physics,
Tsinghua University, Beijing, P.R.China

http://learn.tsinghua.edu.cn:8080/2005012177/index.html
http://thirsty.phys.tsinghua.edu.cn/MyWiki/heroxbd

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


Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)

2008-07-20 Thread Gary C Martin
On 20 Jul 2008, at 22:27, John Watlington wrote:

 Take a look at:
 http://wiki.laptop.org/go/XO_Troubleshooting_AV#Errors_communicating_with_the_camera

 The majority of these problems are due to a latch on the flex cable  
 connector coming loose.
 If you disassemble the laptop, and find that it was due to another  
 source, pleased either
 add it to the guide or let me know.

Thanks for the pointer. I've now disassembled, detached and reattached  
the camera connector and am back up and running. I could see no  
visible signs of any damage, though the ribbon from camera to  
motherboard did seem perhaps a little short/tight given the attachment  
angle. The camera is working in Record and with the hardware test,  
however moderate pressure to the right of the screen near the camera  
(i.e. as when you rotate/move the screen from that side) will cause  
the image to fail or go purple/green as before, though it is currently  
returning to normal when pressure is released.

So, resolved enough for me to help test software that uses the  
camera :-) but I'll need to keep an eye on the pressure applied when  
adjusting the screen angle.

--Gary

P.S. I'll try and think-up something non-committal for the wiki page  
about applying and/or avoiding pressure on the right side of screen as  
something to investigate if a camera is playing up.

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


Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)

2008-07-20 Thread John Watlington

On Jul 20, 2008, at 11:07 PM, Gary C Martin wrote:

 On 20 Jul 2008, at 22:27, John Watlington wrote:

 Take a look at:
 http://wiki.laptop.org/go/ 
 XO_Troubleshooting_AV#Errors_communicating_with_the_camera

 The majority of these problems are due to a latch on the flex  
 cable connector coming loose.
 If you disassemble the laptop, and find that it was due to another  
 source, pleased either
 add it to the guide or let me know.

 Thanks for the pointer. I've now disassembled, detached and  
 reattached the camera connector and am back up and running. I could  
 see no visible signs of any damage, though the ribbon from camera  
 to motherboard did seem perhaps a little short/tight given the  
 attachment angle. The camera is working in Record and with the  
 hardware test, however moderate pressure to the right of the screen  
 near the camera (i.e. as when you rotate/move the screen from that  
 side) will cause the image to fail or go purple/green as before,  
 though it is currently returning to normal when pressure is released.

 So, resolved enough for me to help test software that uses the  
 camera :-) but I'll need to keep an eye on the pressure applied  
 when adjusting the screen angle.

 --Gary

 P.S. I'll try and think-up something non-committal for the wiki  
 page about applying and/or avoiding pressure on the right side of  
 screen as something to investigate if a camera is playing up.

Please remember that the B4 is pre-production hardware.
We lengthened the cable between the camera and the motherboard to  
improve this problem
in production.

John

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


Re: Record-55 issue was B4 hardware failure (Was: [sugar] Design Question)

2008-07-20 Thread Gary C Martin
On 21 Jul 2008, at 04:13, John Watlington wrote:

 Please remember that the B4 is pre-production hardware.
 We lengthened the cable between the camera and the motherboard to  
 improve this problem
 in production.

Thanks John, that's good to know, glad it was B4 specific.

--Gary

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


[Server-devel] [PATCH] server: postprocess renamed to ds-postprocess.py

2008-07-20 Thread martin . langhoff
From: Martin Langhoff [EMAIL PROTECTED]

---
 server/{postprocess.py = ds-postprocess.py} |2 +-
 server/incron-ds-backup.conf |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename server/{postprocess.py = ds-postprocess.py} (98%)

diff --git a/server/postprocess.py b/server/ds-postprocess.py
similarity index 98%
rename from server/postprocess.py
rename to server/ds-postprocess.py
index 216a42e..a99b6ab 100755
--- a/server/postprocess.py
+++ b/server/ds-postprocess.py
@@ -6,7 +6,7 @@
 # drop privileges to the user it will process.
 #
 # The incrond invocation line should be
-# /path/to/dir IN_CREATE /path/to/postprocess.py $@ $#
+# /path/to/dir IN_CREATE /path/to/ds-postprocess.py $@ $#
 #
 # (in other words, we expect 2 parameters, dirpath, filename)
 #
diff --git a/server/incron-ds-backup.conf b/server/incron-ds-backup.conf
index 23a554d..b422a5b 100644
--- a/server/incron-ds-backup.conf
+++ b/server/incron-ds-backup.conf
@@ -1 +1 @@
-/var/lib/ds-backup/completion IN_CREATE,IN_MOVED_TO 
/usr/local/ds-backup/server/postprocess.py $@ $#
\ No newline at end of file
+/var/lib/ds-backup/completion IN_CREATE,IN_MOVED_TO /usr/bin/ds-postprocess.py 
$@ $#
\ No newline at end of file
-- 
1.5.6.dirty

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel


[Server-devel] [PATCH] ds-backup: RPM packaging for -server

2008-07-20 Thread martin . langhoff
From: Martin Langhoff [EMAIL PROTECTED]

Sort out the server package, tidy up things along the way...
---
 Makefile.build   |   14 --
 Makefile.fedora  |2 +-
 Makefile.package |2 +-
 ds-backup.spec.in|   30 +++---
 server/apache-ds-backup.conf |6 +++---
 5 files changed, 40 insertions(+), 14 deletions(-)

diff --git a/Makefile.build b/Makefile.build
index 78de8d4..1a9af81 100644
--- a/Makefile.build
+++ b/Makefile.build
@@ -10,8 +10,18 @@ install-client:
 
 install-server:
install -D -d $(DESTDIR)/usr/bin
-   install -D server/postprocess.py $(DESTDIR)/usr/bin
-
+   install -D server/ds-postprocess.py $(DESTDIR)/usr/bin
+   install -D -d $(DESTDIR)/var/www/ds-backup
+   install -D server/backup-available.py $(DESTDIR)/var/www/ds-backup
+   install -D server/ds-restore.php  $(DESTDIR)/var/www/ds-backup
+   install -D -m 644 server/incron-ds-backup.conf  
$(DESTDIR)/etc/incron.d/ds-backup.conf
+   install -D -m 644 server/apache-ds-backup.conf  
$(DESTDIR)/etc/httpd/conf.d/050-ds-backup.conf
+   install -D -d $(DESTDIR)/var/lib/ds-backup
+   # ownerships are set in the spec file - this execs as nonroot in 
rpmbuild
+   install -D -d $(DESTDIR)/var/lib/ds-backup/recentclients
+   # todo: tighten to group ownership
+   install -D -d -m 777 $(DESTDIR)/var/lib/ds-backup/completion
+   
 install: install-client install-server
 
 .PHONY: install-client install-server
diff --git a/Makefile.fedora b/Makefile.fedora
index eb672a9..915a079 100644
--- a/Makefile.fedora
+++ b/Makefile.fedora
@@ -83,7 +83,7 @@ $(TARBALL): $(SRCDIR) $(foreach 
src,$(SOURCES),$(SRCDIR)/$(src))
tar cjf $(TARBALL) -C $(BUILDDIR) $(NV)
 
 $(SRPM): $(SPEC) $(TARBALL)
-   $(RPMBUILD) -bs $(BUILDDIR)/$(PKGNAME).spec
+   $(RPMBUILD) -bs --nodeps $(BUILDDIR)/$(PKGNAME).spec
 
 build: $(SRPM)
$(MOCK) -r $(BUILDROOT) --uniqueext=`whoami` --resultdir=$(BUILDDIR) 
--rebuild $(SRPM)
diff --git a/Makefile.package b/Makefile.package
index 9ea9dd5..ed65bd4 100644
--- a/Makefile.package
+++ b/Makefile.package
@@ -2,7 +2,7 @@
 PKGNAME = ds-backup
 COMPLETION  = 0.6
 RELEASE = 1
-SOURCES = README AUTHORS COPYING Makefile.build client server utils
+SOURCES = README AUTHORS COPYING Makefile.build client server
 
 ARCH= noarch
 DIST= olpc
diff --git a/ds-backup.spec.in b/ds-backup.spec.in
index 97919e1..43ac878 100644
--- a/ds-backup.spec.in
+++ b/ds-backup.spec.in
@@ -29,18 +29,21 @@ Requires:   python
 Requires:   rsync
 Requires:   sugar-datastore
 Requires:   sugar
-Requires:   cronie
+Requires:   vixie-cron
 
 %package server
 
 Summary:OLPC DS backup  restore server
 Group:  Applications/Archiving
 
+Requires:   mod_python
 Requires:   python
 Requires:   rsync
-Requires:   sugar-datastore
-Requires:   sugar
-Requires:   cronie
+Requires:   vixie-cron
+Requires:   incron
+Requires:   php
+Requires:   httpd
+BuildRequires:  httpd
 
 %description client
 ds-backup-client is a GPL-licensed collection of scripts for backing up and
@@ -65,21 +68,34 @@ make -f Makefile.build install DESTDIR=$RPM_BUILD_ROOT
 %clean
 rm -rf $RPM_BUILD_ROOT
 
+%post server
+service httpd restart
 
 %files client
 %defattr(-,root,root,-)
 %doc README COPYING AUTHORS
-%config(noreplace) %{_sysconfdir}/cron.d/ds-backup
+%config %{_sysconfdir}/cron.d/ds-backup
 %{_bindir}/ds-backup.py
 %{_bindir}/ds-backup.sh
 
 %files server
 %defattr(-,root,root,-)
 %doc README COPYING AUTHORS
-%{_bindir}/postprocess.py
-
+%config(noreplace) %{_sysconfdir}/httpd/conf.d/050-ds-backup.conf
+# incron will mess up with an rpmsave file
+# so replace inconditionally
+%config %{_sysconfdir}/incron.d/ds-backup.conf
+%{_bindir}/ds-postprocess.py
+/var/www/ds-backup/backup-available.py
+/var/www/ds-backup/ds-restore.php
+%attr(700, apache, apache) %dir %{_localstatedir}/lib/ds-backup/recentclients
+%attr(777, nobody, nobody) %dir %{_localstatedir}/lib/ds-backup/completion
 
 %changelog
+* Fri Jul 18 2008 Martin Langhoff [EMAIL PROTECTED] - 0.7-1.olpc3
+- Updated server package, several fixes.
+- Fixed dependencies: cronie-vixie-cron (which cronie provides on F9)
+
 * Mon Jul 06 2008 Michael Stone [EMAIL PROTECTED] - 0.6-1.olpc3
 - Fix dependencies: crond - cronie.
 
diff --git a/server/apache-ds-backup.conf b/server/apache-ds-backup.conf
index 7f7321a..0c5a14b 100644
--- a/server/apache-ds-backup.conf
+++ b/server/apache-ds-backup.conf
@@ -7,8 +7,8 @@
 # clients check whether they are allowed to
 # backup now...
 #
-Alias /backup/1 /usr/local/ds-backup/server/backup-available.py
-Directory /usr/local/ds-backup/server/ 
+Alias /backup/1 /var/www/ds-backup/backup-available.py
+Directory /var/www/ds-backup/ 
 AddHandler mod_python .py
 PythonHandler backup-available
 ## Enable only in development boxen
@@ 

[Server-devel] [PATCH] ds-backup packaging - use git describe for versioning.

2008-07-20 Thread martin . langhoff
From: Martin Langhoff [EMAIL PROTECTED]

Make the rpm versioning dependent on git describe, which does
a very sensible thing - finds the closest tag. If the match
is perfect, it will use the version there stripping a possible
leading 'v' and replacing - with . (so v1.0-33 becomes v1.0.33).

If the match is not perfect, it will count commits of distance,
so 2.0.45.sha1 is 45 commits after v2.0, with a particular sha1.

It retains the 'snapshot' build number counter, which is a handy
shortcut while testing.
---
 Makefile.fedora  |5 ++---
 Makefile.package |2 +-
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/Makefile.fedora b/Makefile.fedora
index 915a079..dde1ccb 100644
--- a/Makefile.fedora
+++ b/Makefile.fedora
@@ -19,7 +19,6 @@ include ./Makefile.package
 
 # Select build id.
 
-SNAPSHOT   := $(shell date +%Y%m%d)git$(shell git log | head -n1 | awk '{print 
substr($$2,0,6)}')
 BUILDNO:= $(shell if [ -f build-no ]; then cat build-no; else echo 1; fi)
 OLDBUILDNO := $(shell echo '$(BUILDNO) - 1' | bc)
 incr-build:
@@ -28,7 +27,7 @@ incr-build:
 ifeq (,$(findstring snapshot,$(MAKECMDGOALS)))
   VERSION=$(COMPLETION)
 else
-  VERSION=$(COMPLETION).$(BUILDNO).$(SNAPSHOT)
+  VERSION=$(COMPLETION).$(BUILDNO)
 endif
 
 NV= $(PKGNAME)-$(VERSION)
@@ -111,7 +110,7 @@ clean:
 
 # Snapshot and Release Rules
 
-snapshot-deploy: VERSION=$(COMPLETION).$(OLDBUILDNO).$(SNAPSHOT)
+snapshot-deploy: VERSION=$(COMPLETION).$(OLDBUILDNO)
 
 snapshot-lint release-lint: lint
 
diff --git a/Makefile.package b/Makefile.package
index ed65bd4..2c31372 100644
--- a/Makefile.package
+++ b/Makefile.package
@@ -1,6 +1,6 @@
 
 PKGNAME = ds-backup
-COMPLETION  = 0.6
+COMPLETION  = $(shell git describe | sed 's/^v//' | sed 's/-/./g')
 RELEASE = 1
 SOURCES = README AUTHORS COPYING Makefile.build client server
 
-- 
1.5.6.dirty

___
Server-devel mailing list
Server-devel@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel