Re: move to rawhide update

2009-04-08 Thread John Gilmore
>> But now, it appears that F11 won't be able to suspend on OLPC, >> which makes it almost useless for laptop use (as opposed to >> developer use when the laptop is sitting on a desk with permanent >> AC power). > > Sure, but you can install a different kernel on your F11 image, su

Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Seth Woodworth
-- Forwarded message -- From: Tom Boonsiri Date: Wed, Apr 8, 2009 at 2:31 AM Subject: Heart Rate Monitor Peripheral To: seth.woodwo...@gmail.com Fellow developers, Is your Measure activity feeling neglected? If so, shame on you. =) I'd like to encourage everyone to build on the

Rainbow, olpc-update, and olpcrd.

2009-04-08 Thread Michael Stone
> The main and probably most major issues outstanding are the > kernel/boot process - so > kernel/initscripts/olpcrd/initscripts/upstart/rainbow collection > of stuff of which I have no real idea about. Updates? Peter, Your remark does not contain any specific questions so it's a little hard

Re: move to rawhide update (Fedora QA breakage)

2009-04-08 Thread John Gilmore
> II. - What for me is an inhibitor is the bugzilla section "tell us > how to reproduce the problem". I have no desire whatsoever to try Mikus unfortunately plays a troll on the Internet. He probably isn't one in real life, but the way he uses the XO is extremely unusual, so he views the XO

Re: xapian and pyxapian

2009-04-08 Thread Simon Schampijer
Simon Schampijer wrote: > Peter Robinson wrote: >> Hi All, >> >> Just looking at the pyxapian package in Fedora. Its only even been >> used in the OLPC-2 cvs branch. There is no build in mainline fedora >> branches. Is it still used? According to the pyxapian site its been >> obsoleted/replaced by

Re: Rainbow, olpc-update, and olpcrd.

2009-04-08 Thread Peter Robinson
> Peter, > > Your remark does not contain any specific questions so it's a little > hard for me to give you a coherent update. Instead, I'll make some > general remarks in the hope that they will elicit further questions. Sorry, there were no real questions, but its more about the status of where

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Sascha Silbe
On Wed, Apr 08, 2009 at 03:44:05AM -0400, Seth Woodworth wrote: I'd like to encourage everyone to build on the great work of Arjun Sarwal and help us extend the sensor interface with our peripheral -- the heart rate monitor. Looks great! As I intended to do a similar device in the future (it's

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Walter Bender
Alas, the blocker with Measure (and Turtle Art with Sensors) is that we haven't come to consensus regarding a packaging strategy for the binary drivers we include for support of the sensor input; these differ by architecture, which wasn't a problem when we were building for just one architecture. P

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Seth Woodworth
Right now this device works primarily with the XO-1, taking advantage of the AC/DC conversion going on in the XO's audio-in port. But if the gain were tweaked a bit more it could work with other audio cards. The fact that it is XO-1 Hardware specific means that packaging for different architectur

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Peter Robinson
There's generally no issue with hardware specific packages in distros (there certainly isn't an issue in Fedora), from the quick read I had of the ticket it looks more like the turtle activity didn't work on the non XO hardware. I presume that's because it couldn't load the specific libraries. Gene

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Walter Bender
Peter, In the ticket, I was trying to express my ignorance of how to proceed, but not suggest that the distros haven't dealt with these sorts of issues in the past. There are two separate issues I encountered with TA (and Measure). One is the need for patches to the alsa audio to accommodate the

Re: move to rawhide update (Fedora QA breakage)

2009-04-08 Thread Peter Robinson
> Now I see what's going on.  Clueless people are crashing around in the > bug database, "helping" developers by hassling users.  Then if you > don't answer the idiots, 30 days later they close out your bug report > as "CLOSED:INSUFFICIENT_DATA".  Instead of a bridge, they seem to be > more of a ba

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Ian Daniher
Hello all, Back when I had much more time and less knowledge, I was working on designing a similar device. While the design didn't progress into a prototype due to lack of interest by other developers and lack of knowledge on my end, there's a large wikipage on TeleHealth_Hardware that's available

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Peter Robinson
> There are two separate issues I encountered with TA (and Measure). One > is the need for patches to the alsa audio to accommodate the special > OLPC hardware modifications. That would need to be accepted upstream by the alsa project, and then distros will automatically get the changes when they

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Peter Robinson
> Alas, the blocker with Measure (and Turtle Art with Sensors) is that > we haven't come to consensus regarding a packaging strategy for the > binary drivers we include for support of the sensor input; these > differ by architecture, which wasn't a problem when we were building > for just one archi

Re: move to rawhide update

2009-04-08 Thread Daniel Drake
2009/4/8 John Gilmore : > Since OLPC's "upstream" is both Linus's kernel releases, and Fedora's > distributions, there are two upstream places to push OLPC's hardware > support patches to.  Have we only been trying to get them into one of > those places (Linus's)? > > The F11 kernel currently carri

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Rafael Enrique Ortiz Guerrero
Hi In a related note Kristianpaulof Sugarlabs .co is testing measure in Soas (with arjun's help) in an effort to adapt it to all kinds of hardware. http://co.sugarlabs.org/go/Sobre_Measure Rafael Ortiz O

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread Richard A. Smith
Walter Bender wrote: > Peter, > > In the ticket, I was trying to express my ignorance of how to proceed, > but not suggest that the distros haven't dealt with these sorts of > issues in the past. > > There are two separate issues I encountered with TA (and Measure). One > is the need for patches

1cc network outage

2009-04-08 Thread Stefan Unterhauser
We had an interruption in network services at 1cc from about 12:38 am to 12:47 am. This affected the reverse proxy server serving the wiki as well as phone and network services at 1cc. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/

[Server-devel] 100 user test on XS

2009-04-08 Thread Dave Bauer
I tested ejabberd from XS 0.5.2 with 100 concurrent users using hyperactivity. This is just using shared-roster. Memory usage was totaly under 1G with no swapping. It got a little slow on the client side running the hyperactivity code. The neighborhood view was pretty crowded but everything seemed

Re: Devel Digest, Vol 38, Issue 1

2009-04-08 Thread Tiago Marques
On 4/2/09, Mitch Bradley wrote: > Martin Langhoff wrote: >> On Thu, Apr 2, 2009 at 3:49 PM, Mitch Bradley wrote: >> >>> It's nice to say they should "see the light", but in my experience >>> talking >>> to many such companies, the fact of the matter is that it is a hard nut >>> for >>> them to sw

Re: Occasional stuck keys on devanagari keyboard

2009-04-08 Thread Gary C Martin
On 8 Apr 2009, at 07:20, Bryan Berry wrote: > I have about 40 XO's out of 2000 so far that occasionally show "stuck > keys" in the corners of the keyboard, particularly the frame, fn, and > right arrow key. The keys seem to stick occasionally but not > consistently. For instance, w/ 5 XO's yesterd

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

2009-04-08 Thread John Gilmore
> Alas, the blocker with Measure (and Turtle Art with Sensors) is that > we haven't come to consensus regarding a packaging strategy for the > binary drivers we include for support of the sensor input; these > differ by architecture, which wasn't a problem when we were building > for just one archi