Re: move to rawhide update

[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, such as
> OLPC's custom kernel (this has already been tested working), or just
> the minimum set of patches to the F11 kernel that add suspend/resume
> support, as Scott Douglass and Martin Dengler have been looking at
> recently.
> 
> I hope we can get some power management patches (even if they're basic
> patches rather than everything we have) upstream and back for F12.  We
> started the F11 project with the knowledge that we wouldn't be able to
> get much of what we need upstream and back in time for its release.

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 carries about 60 patches beyond Linus's version.
Some are tiny 4kb patches; others are 300KB.  Why aren't any of the
XO-1 hardware support patches included in the F11 kernel?

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

Fwd: Heart Rate Monitor Peripheral

[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 great work of Arjun
Sarwal and help us extend the sensor interface with our peripheral --
the heart rate monitor.

Pictures of the device:
http://farm4.static.flickr.com/3559/3419907541_f62b168dce_m.jpg
http://farm4.static.flickr.com/3558/3420715230_00e29b7787_m.jpg

It's a relatively simple device that measures the blood flow in your
finger with an infrared sensor. Powered by USB, the device sends
measurements to the XO via the AC/DC sensor interface (audio jack).
Using a Measure variant with a heart beat detection method, we are
able to display the heart rate (as shown in the pic).

If you're a developer interested in integrating biofeedback into your
application, please email me for more details on how you can get your
hands on a few of our peripherals. Otherwise, we are looking for
developers who can help us evolve the Measure activity to better suit
the lesson plan we have created for the device. The device is not of
clinical quality and solely for educational purposes. We are
definitely interested in feedback on our direction.

In the short-term, it would be interesting to develop a gui where you
could structure a family tree (even extending it to branches for
relatives) and allow kids to record measurements for various family
members. This could potentially evolve into other health education
efforts with a wiki backbone to support health wellness.

Please send me your feedback and your interest!

Thanks,
Tom Boonsiri -- OLPC GoldenState
(tom.boons...@gmail.com)
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Rainbow, olpc-update, and olpcrd.

[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 for me to give you a coherent update. Instead, I'll make some
general remarks in the hope that they will elicit further questions.

1. As has been recently pointed out, Rainbow is not currently in use
on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*).
However, some have wondered whether it might make a reappearance in
sugar-*-0.86. To speed this outcome, I have prepared new versions of
rainbow (0.8.*) which are easy to install and test on many different
platforms. See

   http://wiki.laptop.org/go/Rainbow

for current status information. 

  (I await further rainbow-0.8.* questions, comments, concerns, and
   test results with particular interest.)

2. There is little change in the state of olpcrd and olpc-update.
Daniel Drake did some nice work in February to make the toolchain
support OFW-hosted key overlays and, so far as I know, is happily
serving Paraguay-signed leases and software updates over Paraguay's
test schools' wifi network. 

  (Dan -- could you please update 

   http://wiki.laptop.org/go/Security

   with links to a description of how you've deployed these
   technologies?)

  (Peter -- Did you have some specific question about the technology or
   about its inclusion [or lack thereof] in Fedora?)

Regards from Athens,

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

Re: move to rawhide update (Fedora QA breakage)

[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 in ways that appear to be 77 degrees away from the
usual viewpoint.  His bug reports require careful interpretation if
you want to avoid immediately discarding them as worthless.

>  What good would it do for 
> me to enter a bugzilla report?  A dozen people would ask me for more 
> information, and for more "try this and try that".  I have better 
> things to do with my time.

I'm sad to report that I tried to participate in a Fedora QA "test
day" last week for some particular hardware I have (low end Radeon
graphics).  I filed one clear bug report, and four days later got the
usual "please send us lots of irrelevant info" form letter.  I filed a
testy reply telling them they don't need it and please stop pretending
to close out bug reports by demanding that the user send some
irrelevant info.  See:

  https://bugzilla.redhat.com/show_bug.cgi?id=493748

One of these irrelevant busybodies self-identifies as one of the
Fedora "BugZappers" with this link:

  https://fedoraproject.org/wiki/BugZappers

  "We are a group of volunteers and Red Hat employees whose primary
  mission is to review and triage bug report submissions on
  bugzilla.redhat.com, acting as a bridge between users and developers
  to aid in fixing and closing bugs."

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 barrier, though perhaps they do good work somewhere.  I
think these are the same people who also trashed the "OLPC
suspend/resume is broken" bug report, by running a script that
declared it an obsolete problem that only applied to F10, even though
the problem persists long after F10.  But as the BugZapper credo says,
"No programming knowledge is necessary, and triagers don't necessarily
need to understand the bugs they are working on."

So I'll have to agree with Mikus's analysis of why not to bother
filing Red Hat bugzilla bugs.  Idiots will hassle you, and claim
that the bug doesn't exist after all, then close it.  (*)

John

(*): At Cygnus, we wrote a bug tracking system, PRMS.  We made very
sure that nobody except the original submitter could close out a bug
report.  The only thing developers or QA people could do was put the
bug into "feedback" state, asking the original submitter to confirm
that the bug really is fixed.  I insisted on this process flow because
of the numerous companies I'd reported bugs to, who regularly closed
out my bugs without fixing them -- over and over.  I'd search the bug
reports at Sun and find six people all reporting the same bug I'd
encountered -- and all six of them closed inappropriately by somebody
whose "job" it was to close bug reports (not to fix bugs).  Cygnus's
customers appreciated the attention, even though it was sometimes a
hassle for us to nudge them to close out the bugs we really HAD fixed.
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: xapian and pyxapian

[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 xappy. So i'm just wondering if its still used
>> in OLPC 80x another later branches, or is it not used any more?
>>
>> Cheers,
>> Peter
> 
> I guess you are right. The sugar-datastore which uses xapian requires 
> xapian-bindings-python The pyxapian package sounds highly obsolete to me.
> 
> Regards,
> Simon

Thanks Peter for taking care of following the 'Retired Package' process.

Regards,
Simon

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

Re: Rainbow, olpc-update, and olpcrd.

[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 it stands within Fedora rawhide. The current understanding is
what's documented at this link. If you have more to provide that would
be great (I was already aware of rainbow and the PID changes but
didn't put details in as I don't know alot about early boot
processes).

https://fedoraproject.org/wiki/OLPC/Packages_for_F11

> 1. As has been recently pointed out, Rainbow is not currently in use
> on any Sugar platform later than sugar-*-0.84 (i.e. OLPC's 8.2.*).
> However, some have wondered whether it might make a reappearance in
> sugar-*-0.86. To speed this outcome, I have prepared new versions of
> rainbow (0.8.*) which are easy to install and test on many different
> platforms. See

I presume you mean later than 0.8.2?

>  http://wiki.laptop.org/go/Rainbow
>
> for current status information.
>  (I await further rainbow-0.8.* questions, comments, concerns, and
>  test results with particular interest.)

I believe the major concerns around about the changes to init to run
it as PID 1 and what changes can be made for Fedora mainline
acceptance. I have no idea about the pros and cons of this hence the
generic query.

> 2. There is little change in the state of olpcrd and olpc-update.
> Daniel Drake did some nice work in February to make the toolchain
> support OFW-hosted key overlays and, so far as I know, is happily
> serving Paraguay-signed leases and software updates over Paraguay's
> test schools' wifi network.
>  (Dan -- could you please update
>  http://wiki.laptop.org/go/Security
>
>  with links to a description of how you've deployed these
>  technologies?)
>
>  (Peter -- Did you have some specific question about the technology or
>  about its inclusion [or lack thereof] in Fedora?)

About its inclusion in Fedora.

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

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 
going to measure SpO2 (oxygen saturation) as well as that's what I'm 
interested in), I'd like to see the schematics. Are they available 
somewhere?
Do you just amplify the current through a photo transistor or is there 
something more fancy going on, e.g. AGC?


CU Sascha

--
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: Digital signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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. Perhaps the packaging gurus can chime in.
(See http://dev.sugarlabs.org/ticket/155).

-walter

On Wed, Apr 8, 2009 at 3:44 AM, Seth Woodworth  wrote:
> -- 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 great work of Arjun
> Sarwal and help us extend the sensor interface with our peripheral --
> the heart rate monitor.
>
> Pictures of the device:
> http://farm4.static.flickr.com/3559/3419907541_f62b168dce_m.jpg
> http://farm4.static.flickr.com/3558/3420715230_00e29b7787_m.jpg
>
> It's a relatively simple device that measures the blood flow in your
> finger with an infrared sensor. Powered by USB, the device sends
> measurements to the XO via the AC/DC sensor interface (audio jack).
> Using a Measure variant with a heart beat detection method, we are
> able to display the heart rate (as shown in the pic).
>
> If you're a developer interested in integrating biofeedback into your
> application, please email me for more details on how you can get your
> hands on a few of our peripherals. Otherwise, we are looking for
> developers who can help us evolve the Measure activity to better suit
> the lesson plan we have created for the device. The device is not of
> clinical quality and solely for educational purposes. We are
> definitely interested in feedback on our direction.
>
> In the short-term, it would be interesting to develop a gui where you
> could structure a family tree (even extending it to branches for
> relatives) and allow kids to record measurements for various family
> members. This could potentially evolve into other health education
> efforts with a wiki backbone to support health wellness.
>
> Please send me your feedback and your interest!
>
> Thanks,
> Tom Boonsiri -- OLPC GoldenState
> (tom.boons...@gmail.com)
> ___
> IAEP -- It's An Education Project (not a laptop project!)
> i...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/iaep
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 architectures isn't a problem in the short run, correct?

On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson  wrote:
>> 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. Perhaps the packaging gurus can chime in.
>> (See http://dev.sugarlabs.org/ticket/155).
>
> So the sensors are the ones that can get plugged into the audio
> input/output on the XO? Is this custom to the XO or could be
> conceivably be implemented/used on other audio cards?
>
> Peter
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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. Generally you would put the hardware specific bits
in either a separate package from the app or a sub-package so that for
devices where the hardware isn't present it doesn't need to be
installed. This though would require the app to be able to detect the
whether drivers/plugins are present or not and deal with it. There
would be no issue installing them by default as long as it doesn't
disturb other sound cards that aren't supported.

Peter

BTW the idea of the hardware sensors is very cool. Is there somewhere
you can see what sensors are available for the XO and buy them?


> 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 architectures isn't a problem in the short run, correct?
>
> On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson  wrote:
>>> 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. Perhaps the packaging gurus can chime in.
>>> (See http://dev.sugarlabs.org/ticket/155).
>>
>> So the sensors are the ones that can get plugged into the audio
>> input/output on the XO? Is this custom to the XO or could be
>> conceivably be implemented/used on other audio cards?
>>
>> Peter
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 special
OLPC hardware modifications. The other is a means within the Sugar
bundling system to include binaries for multiple architectures. I
actually had written a work-around for the former, but I remain
ignorant about the details of how to best handle the latter. (At one
point, Sascha had helped me include a script that would build the
appropriate binaries at install time, but that solution depends upon a
build environment be installed, which is not the default for most OLPC
systems. Oops.)

Regarding available sensors, Arjun describes some on the Measure page
in the OLPC wiki

http://wiki.laptop.org/go/Measure

There are also many people working on USB sensor input devices that
would be great to support in general.

thanks.

-walter

On Wed, Apr 8, 2009 at 8:22 AM, Peter Robinson  wrote:
> 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. Generally you would put the hardware specific bits
> in either a separate package from the app or a sub-package so that for
> devices where the hardware isn't present it doesn't need to be
> installed. This though would require the app to be able to detect the
> whether drivers/plugins are present or not and deal with it. There
> would be no issue installing them by default as long as it doesn't
> disturb other sound cards that aren't supported.
>
> Peter
>
> BTW the idea of the hardware sensors is very cool. Is there somewhere
> you can see what sensors are available for the XO and buy them?
>
>
>> 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 architectures isn't a problem in the short run, correct?
>>
>> On Wed, Apr 8, 2009 at 7:56 AM, Peter Robinson  wrote:
 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. Perhaps the packaging gurus can chime in.
 (See http://dev.sugarlabs.org/ticket/155).
>>>
>>> So the sensors are the ones that can get plugged into the audio
>>> input/output on the XO? Is this custom to the XO or could be
>>> conceivably be implemented/used on other audio cards?
>>>
>>> Peter
>>>
>>
>



-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: move to rawhide update (Fedora QA breakage)

[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 barrier, though perhaps they do good work somewhere.  I
> think these are the same people who also trashed the "OLPC
> suspend/resume is broken" bug report, by running a script that
> declared it an obsolete problem that only applied to F10, even though
> the problem persists long after F10.  But as the BugZapper credo says,
> "No programming knowledge is necessary, and triagers don't necessarily
> need to understand the bugs they are working on."

I agree with you to a certain extent. I believe the reason for the
"relable as F10" is primarily due to the fact that Fedora is
relatively fast moving. The idiots you refer to are in the case of the
"this has been reported in rawhide during the F10 development process
so assigning it to F10" are in fact scripts so are complete idiots.
There's a good reason to assign it from rawhide to the specific
release that it was reported under, its because it moves very quickly.
X is an example of this. There's been massive changes in the last 3-4
fedora releases and for example errors related to input devices
reported in F-9 are completely irrelevant in F-10 because the entire X
input subsystem was replaced. So to be able to see that it was
reported in what became F-9 is important because its going to be
completely different issue in F-10. Just because it gets moved from a
rawhide designator to a F-10 one doesn't mean its closed, and if its
still relevant for rawhide, you can update it. I do so regularly.

As for the bugZappers. no comment :-)

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

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 for other people working on similar
projects to add to. Could everyone working on a health-related peripheral go
to http://wiki.laptop.org/go/Health_Hardware and add a blurb. This is a
great place for people to post technical resources as well.
Thanks,
--
Ian Daniher
OLPCinci Repair Center Lead
OLPC Support Gang Volunteer

On Wed, Apr 8, 2009 at 5:27 AM, Sascha Silbe <
sascha-ml-ui-sugar-i...@silbe.org> wrote:

> 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 going
> to measure SpO2 (oxygen saturation) as well as that's what I'm interested
> in), I'd like to see the schematics. Are they available somewhere?
> Do you just amplify the current through a photo transistor or is there
> something more fancy going on, e.g. AGC?
>
> CU Sascha
>
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJJ3G3/AAoJELpz82VMF3DaxB0H/jq4PoQLdRltHR7LsRAgIqcg
> XmGgBTuDZS8qP8KFGEfhNJP04xc4NUfjQpDM3+LhgGBgWDKJMAm2kNWzKrxOxoJs
> 5DkPf7kxNGqRNHFjpXNJeLgcOvo/fcyrt1oynpuAu7qxISB2GFmlllmywL0dM0BX
> TGK/4f9fzilyMQnk53d9eAYw/4mblY+jTAEO1MTULYTbZywwNtdd8wmg+j04wXCq
> QTqghlU/8IadahAJBdXUfK95vQHiUYOmRO8MEDmDaqGZpb1Wb1QjlGCWBfSBn/D+
> 5fYtc8+/VZDEnLp3vqBtqKku8CfnXNdpmH3Z4TSSVrI/YUu67O34kL3JFAeDm4o=
> =LYUf
> -END PGP SIGNATURE-
>
> ___
> 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: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 are part of a
release.

> The other is a means within the Sugar
> bundling system to include binaries for multiple architectures. I
> actually had written a work-around for the former, but I remain
> ignorant about the details of how to best handle the latter. (At one
> point, Sascha had helped me include a script that would build the
> appropriate binaries at install time, but that solution depends upon a
> build environment be installed, which is not the default for most OLPC
> systems. Oops.)

That would be just a packaging procedure. In the case of Fedora it
would be just the arch dependant rpms as opposed to using a activity
.xo file which I believe are arch independent. Unless I've missed
something here.

> Regarding available sensors, Arjun describes some on the Measure page
> in the OLPC wiki

Thanks!

> http://wiki.laptop.org/go/Measure
>
> There are also many people working on USB sensor input devices that
> would be great to support in general.

In fedora at least from a driver perspective it would land in Fedora
as soon as the upstream kernel has the drivers. I'm not sure whether
there is a defined api for accessing those sort sensors on linux. If
there was I would presume as the hardware is added that TA/measure
would automatically get support for the hardware as its added, if
there's not I presume there would need to be individual support added
for each device.

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

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 architecture. Perhaps the packaging gurus can chime in.
> (See http://dev.sugarlabs.org/ticket/155).

So the sensors are the ones that can get plugged into the audio
input/output on the XO? Is this custom to the XO or could be
conceivably be implemented/used on other audio cards?

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

Re: move to rawhide update

[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 carries about 60 patches beyond Linus's version.
> Some are tiny 4kb patches; others are 300KB.  Why aren't any of the
> XO-1 hardware support patches included in the F11 kernel?

I don't think any effort has been made (since layoffs) to get any
kernel patches upstream anywhere, mostly due to time constraints. But
anyone is welcome to step up and do so!

During a quick discussion with Chris and some others we seemed to
agree on the following:
 - regardless of Fedora/F11/F12 status, policies or whatever, the
first thing to do in any case is to get the patches upstream to Linus
 - we haven't actually tried sending our patches specifically to
Fedora (knowing that they aren't quite ready for Linus) - but IMO this
would be a bad idea
 - we don't really know Fedora's kernel policies for accepting
non-upstream patches, or for backporting upstreamed patches into
current Fedora kernels
 - my opinion: getting patches upstream to Linus, or perhaps even as
far as linux-next, would be enough for the fedora kernel maintainers
to include the patches in the F11 release kernel as an update. So
let's not rule out suspend-on-F11.. it's possible that
F11-plus-updates may work in future.

The biggest showstopper right now seems to be finding someone to do
the work of upstreaming the patches. And, in my opinion and
experience, the correct way to do this is to approach upstream saying

"hey, we have this weird hardware, how would you like to see the
kernel code crafted? here's a possible patch to act as the basis of
discussions"

and *not*

"hey, we have this weird hardware, please take our patches as-is
without consideration because we've shipped them internally for 2
years"

which makes the task harder (since kernel hacking may be needed as a
result of discussions), but should lead to success :)

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

Re: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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


On Wed, Apr 8, 2009 at 7:40 AM, Peter Robinson  wrote:

> > 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 are part of a
> release.
>
> > The other is a means within the Sugar
> > bundling system to include binaries for multiple architectures. I
> > actually had written a work-around for the former, but I remain
> > ignorant about the details of how to best handle the latter. (At one
> > point, Sascha had helped me include a script that would build the
> > appropriate binaries at install time, but that solution depends upon a
> > build environment be installed, which is not the default for most OLPC
> > systems. Oops.)
>
> That would be just a packaging procedure. In the case of Fedora it
> would be just the arch dependant rpms as opposed to using a activity
> .xo file which I believe are arch independent. Unless I've missed
> something here.
>
> > Regarding available sensors, Arjun describes some on the Measure page
> > in the OLPC wiki
>
> Thanks!
>
> > http://wiki.laptop.org/go/Measure
> >
> > There are also many people working on USB sensor input devices that
> > would be great to support in general.
>
> In fedora at least from a driver perspective it would land in Fedora
> as soon as the upstream kernel has the drivers. I'm not sure whether
> there is a defined api for accessing those sort sensors on linux. If
> there was I would presume as the hardware is added that TA/measure
> would automatically get support for the hardware as its added, if
> there's not I presume there would need to be individual support added
> for each device.
>
> Peter
> ___
> 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: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 to the alsa audio to accommodate the special
> OLPC hardware modifications. The other is a means within the Sugar
> bundling system to include binaries for multiple architectures. I

What binary drivers are you talking about?


-- 
Richard Smith  
One Laptop Per Child
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

1cc network outage

[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/listinfo/devel

[Server-devel] 100 user test on XS

[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 to work well.

This was a very basic test, but overall seems to be promising news.
Dave
-- 
Dave Bauer
d...@solutiongrove.com
http://www.solutiongrove.com
___
Server-devel mailing list
server-de...@lists.laptop.org
http://lists.laptop.org/listinfo/server-devel

Re: Devel Digest, Vol 38, Issue 1

[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 swallow.
>>>
>>
>> I am under the impression that the relation between the OS vendor (and
>> kernel/driver devs on the OS side) and the HW companies (with their hw
>> and driver devs) is full of hard nuts to swallow. From reading horror
>> stories around winhec, and ms bloggers making strained comments about
>> driver developers, it doesn't sound like a bed of roses :-) But, for
>> good or bad, management has gotten used to the dynamic w Redmond.
>>
>>
>
> That is absolutely correct.  Windows drivers are a total pain in the ass
> (speaking from my experience making Windows run on the XO).>
> But in compensation, once you get the driver right, or mostly so, it
> will work on hundreds of millions of machines for a few years.  By "it",
> I mean a specific binary that you can point to and say "that is the
> one".  When it stops working due to a new MS OS like Vista, you might be
> able to ignore the problem because the old product is several
> generations obsolete and you've already made your money on it.  "Sorry,
> you have to upgrade".

Which is wrong and a very good thing about Linux. If you saw the
outcry that followed when Creative labs aliented their customer base
from Vista by offering new cards or a paid upgrade for Alchemy, you
know how bad it was. I have a serious problem paying say $200 for a
sound card that will still be mostly state of the art five years down
the road but that doesn't have drivers two years after release, just
because some company only thinks about profits.

>
> Having done the painful-but-necessary work to service the market that is
> big enough to return a profit, there is scant motivation to swallow
> additional nuts for a much smaller amorphous market that won't stay in
> focus.
>
> One of Joel Spolsky's essays pointed out that to attract customers from
> an entrenched competitor, you must ruthlessly eliminate the many
> barriers that make it difficult to switch.  You must see those barriers
> from the customer's point of view; trying to impose your point of view
> on the customer just doesn't work.

Breaking APIs in the kernel, AFAIK, is more related to changing things
when security concerns arise than by will - after all, the people who
do that end up having more work with affected drivers.

There are plenty of companies that have the will to support changes.
Some because they have server related hardware, some because they
catter to the customer, like Intel, which has even contributted to
advances in Xorg. And they manage fine, more than fine. Nvidia
released 4 drivers in March, mostly to add features. Unfortunately,
most just plain like to ignore it's customers, like the above cited
Creative labs.

Best regards,
   Tiago Marques

>
> I guess the main disconnect is that, for the FOSS community, the point
> of view is more important than the product.  The commercial world is
> just the opposite.
>
>> I am interested in discussing
>> the meatier parts of whether the commiditization that FOSS has applied
>> to sw affects hw and how some time over a beer.
>
> I would like that very much.  I sincerely hope that we have the
> opportunity to meet in person at some point.
>
>
> ___
> 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: Occasional stuck keys on devanagari keyboard

[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 yesterday the keys were stuck on
> the first boot. On the second boot the problem  went away. Today, I
> powered on the same XO's and the keys were stuck on the first boot.  
> The
> problem went away on the second boot.
>
> We have firmware Q2E33
>
> Can anyone shed some insight on this problem?

My (hardware) stuck XO-1 key experience was intermittent. Opening/ 
closing, moving, slight case flexing was enough to stop or start the  
issue. If it is the old hardware issue (and keys around the edge did  
seem to be the ones effected), the ~30min sticky tape fix worked and  
continues to work today for me (6 months on):

http://wiki.laptop.org/go/Stuck_keys#Fix

Regards,
--Gary

> -- 
> Bryan W. Berry
> Technology Director
> OLE Nepal, http://www.olenepal.org
>
> ___
> 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: [IAEP] Fwd: Heart Rate Monitor Peripheral

[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 architecture. Perhaps the packaging gurus can chime in.
> (See http://dev.sugarlabs.org/ticket/155).

I'm guessing below, because I can't find the source of the "binary
driver" you are discussing.  The bug report doesn't point to it, and
it isn't in an obvious place in the OLPC git or the Sugar gitorious.

It's not a "binary driver", it's just a library implemented in C or C++
rather than Python.  This is only novel to the Sugar team -- the vast
majority of packages in every Linux distro are already this way.

There's already a python-alsaaudio package in Ubuntu:

  http://packages.ubuntu.com/intrepid/sound/python-alsaaudio

If this is the module you're calling, your sugar-measure-activity
package just has to mention that as a dependency, and all should be
well.

If you have your own unique python-alsaaudio module, you'll probably
want to merge it with the already-existing one, and fix up Measure
so it can call the existing public one.

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