Re: Google summer of Code?
> 2009/3/8 Jameson Quinn : > > No definite agreement has been made, but in preliminary chats, it seems > > that both organizations agree that anything for XS or specific to XO > hardware > > should go in OLPC, and everything else (general Sugar improvements, > > frameworks, or activities) should go in Sugarlabs. > > We discussed this at XO camp, and people from Sugar Labs were > considering not supporting activity development and focusing on core > sugar development. This is correct. > Has this changed? In general, do you expect that > priorities for toolchain and activity development will be the same? In general, sugar-core and toolchain development is a higher priority than generative Activity development (Activities that lower the barrier to Activity development). It's highly unlikely that non-generative Activity development will be supported. > I expect that many activity development and student projects > interested in working with current schools will apply for both OLPC > and Sugar Labs projects; they are welcome to apply to both, and those > doing work relevant to Sugar should be encouraged to! Applying to > multiple GSOC groups is standard practice; students do not need to > choose. We had a couple of students last year who ended up working on > OLPC related projects for other orgs. Yup, I remember that. :) We talked with Cjb about shuttling relevant apps back and forth as needed - what we're doing right now is setting up guidelines that will hopefully minimize the amount of sorting that's needed, then waiting for students to come in, then sorting. Double-apping is not a problem. --Mel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing perl from the build
Hi Chris, >> I've gone through what's been pulling in the perl dependency and >> narrowed down the packages that are dependant on it to the following >> list. There's a number of easy fix ones and two that I need to dig >> further on. The first four should be a matter of just blocking them >> out of the kickstart file. >> >> w3m >> logwatch >> lftp >> fbset >> >> This one is because cronie wants a mailer. Daniel and I fixed this one >> on joyride by explicitly adding ssmtp (a 50K mailer) >> exim >> >> These two will be a little more interesting. I'm going to file some >> bugs against them. The second one I can't see why it needs perl. The >> first one we'll see. >> deltarpm >> libgnomeprint22 > > As a followup to this email I filed bugs for the two issues above, I > was given permission to fix libgnomeprint22 (BZ 489227) which has been > done and should show up in the next rawhide. Still awaiting response > for the deltarpm one (BZ 489231). I can create a patch for the > kickstart if that makes it easier for you too. As another follow up to this the gnome-python2-evince package (needed from sugar-read) incorrectly required evince-devel which in turn pulls in a chunk of the devel stack plus perl, I've filed RH bug 490112 to get this fixed so hopefully it should be done before too long. If you think its work doing quickly it might be worthwhile adding it to the F11Beta tracker. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
On Fri, Mar 13, 2009 at 1:56 AM, Mel Chua wrote: > > 2009/3/8 Jameson Quinn : >> > No definite agreement has been made, but in preliminary chats, it seems >> > that both organizations agree that anything for XS or specific to XO >> hardware >> > should go in OLPC, and everything else (general Sugar improvements, >> > frameworks, or activities) should go in Sugarlabs. >> >> We discussed this at XO camp, and people from Sugar Labs were >> considering not supporting activity development and focusing on core >> sugar development. > > > This is correct. > > >> Has this changed? In general, do you expect that >> priorities for toolchain and activity development will be the same? > > > In general, sugar-core and toolchain development is a higher priority than > generative Activity development (Activities that lower the barrier to > Activity development). It's highly unlikely that non-generative Activity > development will be supported. > Honestly, this is news to me. (and I am the co-administrator of the Sugarlabs program). If I had to articulate my view of our priorities, it would be something like the following: 7-10 points: Key sugar core improvements. Long-standing, important gaps like versioning or unit-tests at the high end of this. 6-9 points: Activity frameworks to open new forms of activity development (in descending priority: javascript/AJAX, swf, improved PyGTK tools such as Develop activity, mono or java) 4-8 points: Core activities: For instance, Nepal has expressed the need for an improved Read. 3-6 points: Quality non-core educational activities: a physics sim or other creative idea. 0-8 points: Proposal quality. In other words, an excellent proposal from a highly-qualified student could very well make the cut, even if it were a non-core activity. Jameson (whose daughter likes colors) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jameson Quinn wrote: > Honestly, this is news to me. (and I am the co-administrator of the > Sugarlabs program). If I had to articulate my view of our priorities, it > would be something like the following: > > 7-10 points: Key sugar core improvements. Long-standing, important gaps like > versioning or unit-tests at the high end of this. As others have pointed out many times, the SoC projects that are least likely to produce useful results are the ones that are the most ambitious. In particular, it is difficult to find SoC applicants who are ready to make deep modifications to an existing codebase, or will be able to architect complex software. Remember, SoC applicants are mostly current undergrads, so most have never participated in multi-person development effort, or written anything larger than 1000 lines. > 0-8 points: Proposal quality. Maybe this problem is wrapped up in "Proposal quality". If I were designing a system to reflect my own internal judgment structure, I would probably add another /multiplying/ factor, the estimated probability of success (although I hope we can do selection without resorting to numerical scores.) - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkm6XnQACgkQUJT6e6HFtqSlrACgjuswY+/aYXWkfaTY3DZcls/l gLcAnRP4Rn7tGfuQoiipzFtXQfEHP1g4 =Z92W -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Removing perl from the build
> As another follow up to this the gnome-python2-evince package (needed > from sugar-read) incorrectly required evince-devel which in turn pulls > in a chunk of the devel stack plus perl, I've filed RH bug 490112 to > get this fixed so hopefully it should be done before too long. If you > think its work doing quickly it might be worthwhile adding it to the > F11Beta tracker. Continuing the thread by talking to myself. This has been fixed and I've asked if we can get it tagged into the F11 beta. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Google summer of Code?
On Fri, Mar 13, 2009 at 7:24 AM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jameson Quinn wrote: > > Honestly, this is news to me. (and I am the co-administrator of the > > Sugarlabs program). If I had to articulate my view of our priorities, it > > would be something like the following: > > > > 7-10 points: Key sugar core improvements. Long-standing, important gaps > like > > versioning or unit-tests at the high end of this. > > As others have pointed out many times, the SoC projects that are least > likely to produce useful results are the ones that are the most ambitious. > In particular, it is difficult to find SoC applicants who are ready to > make deep modifications to an existing codebase, or will be able to > architect complex software. Remember, SoC applicants are mostly current > undergrads, so most have never participated in multi-person development > effort, or written anything larger than 1000 lines. Agreed. However, I think that a relatively-skilled GSoC student could take on one of the tasks I mentioned. Versioning could build on CScott's OLPCFS2, which AFAIK works remarkably well; it really only needs an interface and maybe a converter. Unit tests require a harness (and Sugarbot already exists) and a couple of demo self-tests of the harness; the tests themselves would be a separate story. Yet it is true, both of these would still be ambitious, and would probably be scored down because of it. > > > > 0-8 points: Proposal quality. > > Maybe this problem is wrapped up in "Proposal quality". If I were > designing a system to reflect my own internal judgment structure, I would > probably add another /multiplying/ factor, the estimated probability of > success (although I hope we can do selection without resorting to > numerical scores.) I agree. The numbers are only a way of communicating, not a proposed system for choosing. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
2PM EDT Friday: BRIEF Contributors Program Mtg (#olpc-meeting)
Contributor Program v2.0 is off to a Great start this month, thanks to So Many of You, including: * almost 15 active (dare I saw AWESOME) Mentors * several "Laptop Lending Libraries" Right Now getting underway this month in Australia, New Zealand & beyond * a far more accessible reviewing process volunteers are increasingly helping me roll out (you know who you are, thank Mafe & all!!) Join us reviewing the latest OLPC/Sugar community projects today 2PM EDT in just over an hour from now: http://forum.laptop.org/chat Then type at bottom: /join #olpc-meeting 1. We'll review these 4 new projects: NLP tools for OLPC, Meaning to Word Multi-lingual Dictionary by Ervin [ALBANIA] http://rt.laptop.org/Ticket/Display.html?id=35617 PROJECT i-TEACH, Philippines by Emmanuel [PHILIPPINES] http://rt.laptop.org/Ticket/Display.html?id=35665 OLPC Jericho by Sebastian [WEST BANK, PALESTINIAN TERRITORY, ISRAEL, GERMANY, SWITZERLAND] http://rt.laptop.org/Ticket/Display.html?id=35743 Ghana olpc by Eric [GHANA] http://rt.laptop.org/Ticket/Display.html?id=35942 (*) site passworded to protect personal privacy of applicants; if you can help, please do join http://wiki.laptop.org/go/Support_Gang ! NEW: Project summaries of pre-approved projects will soon be posted here, as they "bubble" up to maturity: http://wiki.laptop.org/go/Projects 2. Revising Prior Proposals Integrate CRM Web form using XO by benbas [MALAYSIA] http://rt.laptop.org/Ticket/Display.html?id=35391 Loan Laptop to students and lecturers by benbas [MALAYSIA] http://rt.laptop.org/Ticket/Display.html?id=35393 AND OTHERS! http://rt.laptop.org/Search/Results.html?Query=Queue=%27contributors%27 3. Hone our Mentoring Process! * Our "Science fair" garden is growing fast for springtime, watch (and help!) /many/ ongoing inspiring changes Hullaw & others sparking here --* help all worthy projects past/present/future take root!* http://wiki.laptop.org/go/Projects * Application process clarified regarding privacy/sharing options -- Title, Objectives, and Mentor Preferences must be web-published: http://wiki.laptop.org/go/Contributors_program/Project_proposal_form * Build Awareness around our new: http://wiki.laptop.org/go/Contributors * Mentor More Projects-- Help Us Resolve several dozen Project Proposals dating from 2008: http://rt.laptop.org/Search/Results.html?Query=Queue=%27contributors%27 * Keep stress-testing our new CP v2.0 to make sure it continues to scale** * Craft RTFM's and email to all older/ongoing projects asking them how it's going, how we can help! * Craft email to the many who registered over the last year expecting hardware, but failed to to complete the 2nd step applying :( 4. "Projecting" Futurism * Several "Laptop Lending Libraries" are Right Now getting underway. Help us provide them the best ideas towards organic growth (Project Pools) by commenting here: http://wiki.laptop.org/go/Contributors_program_criteria * Contributors Program v3.0 arising springtime? http://wiki.laptop.org/go/Support_meetings/20090301#Agenda_Item_2:_Contributors_Program.2B.2B.3B_Radical_Overhaul_Advances * Your Other Questions! ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
announce: alternate power management
hi --
i had an itch that needed scratching, and the result is a
reimplementation of much (but not all) of what ohmd does
currently.
i've thought for some time (and i believe cjb agrees) that ohmd
is needlessly difficult to maintain and modify for our purposes
on the XO. small improvements are difficult to implement
quickly.
since my heart is with more quasi-embedded systems than the XO's
current incarnation, part of my goal was to do a rewrite which
was not dependent on hald, dbus, or X11 -- power management
should work well from a console screen, and be available even if
none of those services is running.
i call the service i wrote "powerd". it gets user idle/active
reports from the olpc-kbdshim daemon (which is watching all
user keypress and touchpad activity in any case), and it gets
reports regarding the hardware inputs (power button, lid and
ebook switches, ac adapter status, battery level, etc) either
from another small daemon that monitors /dev/input/event{0,1,2},
or from /sys nodes directly.
it basically recreates ohmd's "dim after a bit, then sleep"
behavior, with some additions:
- a power button splash screen: a second press of the power
button invokes shutdown, simply waiting for a brief timeout
invokes suspend, and any user activity cancels. (i even
managed to kinda sorta convey all that with graphics. i'm
sure every UI person that sees it will roll their eyes.)
- configurable timeouts for screen dim and sleep. the dim
level is configurable.
- different power management behavior when on wall power vs.
battery -- many laptop owners don't need to be miserly with
power when running from an external source. powerd makes
this behavior selectable.
- different power behavior when in ebook mode (though detection
may be unreliable -- i think the ebook switch suffers from
some issues we previously noticed with the lid switch). this
should let you configure things like a very short timeout until
idle-suspend, and/or no screen dimming, when in ebook mode. (i
find the frequent on/off nature of the backlight when reading
in ebook mode to be a distraction.)
- clean shutdown on critically low battery. (currently set at
a reported 5%, at which point my laptop would only run for
another couple of minutes.)
- the ability to run arbitrary scripts after a resume. (perhaps
to reinit usb devices that don't suspend/resume properly? haven't
used this much yet.)
- ease of customization, given that it's written in everyone's
favorite interpreted language.
unimplemented:
- inhibiting idle suspend based on system or network load.
i.e., the system will dim or suspend when watching a video.
(there are hooks in place where these features should be
implemented -- they're just not coded at all.) there's
no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
instead.
- no special support for the wireless mesh, whatsoever. i
couldn't remember how it was supposed to work, and i recall
cjb saying it's hard to figure out whether the mesh is active
or not.
- there's some support for wake-on-wlan, but it's not well tested.
finally a big one:
- proper support for USB keyboards and mice. i recently
realized that since olpc-kbdshim only monitors the built-in
keyboard and touchpad, powerd will think the user is idle
while they type on a USB keyboard, and cheerfully suspend
regardless. (in my case, most of the time i want to
auto-suspend is when i'm running on battery, and not using
external devices, so i sort of forgot about this case.)
anyway, code is available here:
http://dev.laptop.org/git/users/pgf/powerd/
and rpms are here:
http://dev.laptop.org/~pgf/rpms/
you'll need to install both olpc-kbdshim and olpc-powerd (in that
order). when installed, olpc-powerd disables ohmd, and reenables
it when uninstalled. (so it's relatively safe to try.)
there's no gui or other convenience for configuration --
see/etc/powerd/powerd.conf. the installed defaults should be
reasonable. and you'll need to run:
echo reconfig >/var/run/powerevents
after making changes to the config file.
paul
=-
paul fox, p...@laptop.org
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: [Sugar-devel] announce: alternate power management
Very cool!
How well will this integrate with the power management systems other
distros are using? Can it become a 'Value Added' for other netbook
manufacturers?
david
On Fri, Mar 13, 2009 at 4:33 PM, wrote:
> hi --
>
> i had an itch that needed scratching, and the result is a
> reimplementation of much (but not all) of what ohmd does
> currently.
>
> i've thought for some time (and i believe cjb agrees) that ohmd
> is needlessly difficult to maintain and modify for our purposes
> on the XO. small improvements are difficult to implement
> quickly.
>
> since my heart is with more quasi-embedded systems than the XO's
> current incarnation, part of my goal was to do a rewrite which
> was not dependent on hald, dbus, or X11 -- power management
> should work well from a console screen, and be available even if
> none of those services is running.
>
> i call the service i wrote "powerd". it gets user idle/active
> reports from the olpc-kbdshim daemon (which is watching all
> user keypress and touchpad activity in any case), and it gets
> reports regarding the hardware inputs (power button, lid and
> ebook switches, ac adapter status, battery level, etc) either
> from another small daemon that monitors /dev/input/event{0,1,2},
> or from /sys nodes directly.
>
> it basically recreates ohmd's "dim after a bit, then sleep"
> behavior, with some additions:
>
> - a power button splash screen: a second press of the power
> button invokes shutdown, simply waiting for a brief timeout
> invokes suspend, and any user activity cancels. (i even
> managed to kinda sorta convey all that with graphics. i'm
> sure every UI person that sees it will roll their eyes.)
>
> - configurable timeouts for screen dim and sleep. the dim
> level is configurable.
>
> - different power management behavior when on wall power vs.
> battery -- many laptop owners don't need to be miserly with
> power when running from an external source. powerd makes
> this behavior selectable.
>
> - different power behavior when in ebook mode (though detection
> may be unreliable -- i think the ebook switch suffers from
> some issues we previously noticed with the lid switch). this
> should let you configure things like a very short timeout until
> idle-suspend, and/or no screen dimming, when in ebook mode. (i
> find the frequent on/off nature of the backlight when reading
> in ebook mode to be a distraction.)
>
> - clean shutdown on critically low battery. (currently set at
> a reported 5%, at which point my laptop would only run for
> another couple of minutes.)
>
> - the ability to run arbitrary scripts after a resume. (perhaps
> to reinit usb devices that don't suspend/resume properly? haven't
> used this much yet.)
>
> - ease of customization, given that it's written in everyone's
> favorite interpreted language.
>
> unimplemented:
>
> - inhibiting idle suspend based on system or network load.
> i.e., the system will dim or suspend when watching a video.
> (there are hooks in place where these features should be
> implemented -- they're just not coded at all.) there's
> no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
> instead.
>
> - no special support for the wireless mesh, whatsoever. i
> couldn't remember how it was supposed to work, and i recall
> cjb saying it's hard to figure out whether the mesh is active
> or not.
>
> - there's some support for wake-on-wlan, but it's not well tested.
>
> finally a big one:
> - proper support for USB keyboards and mice. i recently
> realized that since olpc-kbdshim only monitors the built-in
> keyboard and touchpad, powerd will think the user is idle
> while they type on a USB keyboard, and cheerfully suspend
> regardless. (in my case, most of the time i want to
> auto-suspend is when i'm running on battery, and not using
> external devices, so i sort of forgot about this case.)
>
> anyway, code is available here:
> http://dev.laptop.org/git/users/pgf/powerd/
> and rpms are here:
> http://dev.laptop.org/~pgf/rpms/
>
> you'll need to install both olpc-kbdshim and olpc-powerd (in that
> order). when installed, olpc-powerd disables ohmd, and reenables
> it when uninstalled. (so it's relatively safe to try.)
>
> there's no gui or other convenience for configuration --
> see/etc/powerd/powerd.conf. the installed defaults should be
> reasonable. and you'll need to run:
> echo reconfig >/var/run/powerevents
> after making changes to the config file.
>
> paul
> =-
> paul fox, p...@laptop.org
> ___
> 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
Re: [Sugar-devel] announce: alternate power management
david wrote:
> Very cool!
>
> How well will this integrate with the power management systems other
> distros are using? Can it become a 'Value Added' for other netbook
> manufacturers?
while i'd love to say i did a lot of research and prep in order
to make sure my little project was api compliant and future
compatible with other power management systems, i can't say that.
my goal's were small: to produce a lighter weight skeleton on
which to hang XO power management, in order to reduce the effort
needed to add some small features (that i wanted) to the current
functionality, and to make sure it was distro, desktop, and UI
independent. (i also wanted to prove to myself that it could
really be done the way i was picturing it).
paul
>
> david
>
> On Fri, Mar 13, 2009 at 4:33 PM, wrote:
> > hi --
> >
> > i had an itch that needed scratching, and the result is a
> > reimplementation of much (but not all) of what ohmd does
> > currently.
> >
> > i've thought for some time (and i believe cjb agrees) that ohmd
> > is needlessly difficult to maintain and modify for our purposes
> > on the XO. Â small improvements are difficult to implement
> > quickly.
> >
> > since my heart is with more quasi-embedded systems than the XO's
> > current incarnation, part of my goal was to do a rewrite which
> > was not dependent on hald, dbus, or X11 -- power management
> > should work well from a console screen, and be available even if
> > none of those services is running.
> >
> > i call the service i wrote "powerd". Â it gets user idle/active
> > reports from the olpc-kbdshim daemon (which is watching all
> > user keypress and touchpad activity in any case), and it gets
> > reports regarding the hardware inputs (power button, lid and
> > ebook switches, ac adapter status, battery level, etc) either
> > from another small daemon that monitors /dev/input/event{0,1,2},
> > or from /sys nodes directly.
> >
> > it basically recreates ohmd's "dim after a bit, then sleep"
> > behavior, with some additions:
> >
> > Â - a power button splash screen: Â a second press of the power
> > Â Â button invokes shutdown, simply waiting for a brief timeout
> > Â Â invokes suspend, and any user activity cancels. Â (i even
> > Â Â managed to kinda sorta convey all that with graphics. Â i'm
> > Â Â sure every UI person that sees it will roll their eyes.)
> >
> > Â - configurable timeouts for screen dim and sleep. Â the dim
> > Â Â level is configurable.
> >
> > Â - different power management behavior when on wall power vs.
> > Â Â battery -- many laptop owners don't need to be miserly with
> > Â Â power when running from an external source. Â powerd makes
> > Â Â this behavior selectable.
> >
> > Â - different power behavior when in ebook mode (though detection
> > Â Â may be unreliable -- i think the ebook switch suffers from
> > Â Â some issues we previously noticed with the lid switch). Â this
> > Â Â should let you configure things like a very short timeout until
> > Â Â idle-suspend, and/or no screen dimming, when in ebook mode. Â (i
> > Â Â find the frequent on/off nature of the backlight when reading
> > Â Â in ebook mode to be a distraction.)
> >
> > Â - clean shutdown on critically low battery. Â (currently set at
> > Â Â a reported 5%, at which point my laptop would only run for
> > Â Â another couple of minutes.)
> >
> > Â - the ability to run arbitrary scripts after a resume. Â (perhaps
> > Â Â to reinit usb devices that don't suspend/resume properly? Â haven't
> > Â Â used this much yet.)
> >
> > Â - ease of customization, given that it's written in everyone's
> > Â Â favorite interpreted language.
> >
> > Â unimplemented:
> >
> > Â - inhibiting idle suspend based on system or network load.
> > Â Â i.e., the system will dim or suspend when watching a video.
> > Â Â (there are hooks in place where these features should be
> > Â Â implemented -- they're just not coded at all.) Â there's
> > Â Â no /etc/ohmd directory, so it honors /var/run/inhibit-idle-suspend
> > Â Â instead.
> >
> > Â - no special support for the wireless mesh, whatsoever. Â i
> > Â Â couldn't remember how it was supposed to work, and i recall
> > Â Â cjb saying it's hard to figure out whether the mesh is active
> > Â Â or not.
> >
> > Â - there's some support for wake-on-wlan, but it's not well tested.
> >
> > Â finally a big one:
> > Â - proper support for USB keyboards and mice. Â i recently
> > Â Â realized that since olpc-kbdshim only monitors the built-in
> > Â Â keyboard and touchpad, powerd will think the user is idle
> > Â Â while they type on a USB keyboard, and cheerfully suspend
> > Â Â regardless. Â (in my case, most of the time i want to
> > Â Â auto-suspend is when i'm running on battery, and not using
> > Â Â external devices, so i sort of forgot about this case.)
> >
> > anyway, code is available here:
> > Â Â
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
p...@laptop.org a écrit : > rekik wrote: > > Hi, > > > > I tried to build the kernel open80211s on a group of machines which use > > ubuntu 8.10 and it's work. Now I had to build it on an XO. The problem > > is that I don't have enough space on my flash memory ( 1Go ). So, I had > > to extend it with an SD card ( to have a space > 1024 Mo), but I > > don't know the steps to make this solution and the minimum size of the > > SD card.. > > > > can anyone help me !!! > > it sounds like you're trying to do the build of open80211s on > the XO itself. most people don't do development for the XO that way -- > we build on another machine, and move the binaries onto the XO. > > for simple programs, you can build on most any modern linux > distribution and your binary will work on the XO, because the > libraries and environment tend to be compatible. (you could > perhaps build a static binary to be sure.) > > the XO is based on fedora, so a fedora machine will be the best > build host. > Yes, but debian can also run on XO. However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Today, the stuff with debian on XO is cleaner and very fast to install and test ; http://wiki.laptop.org/go/DebXO is the best page I found about it : # zcat debxo-$DESKTOP.ext3.img.gz > /dev/sdX (for instance, sdb; not sdb1) And update the firmware to q2e34.rom at http://dev.laptop.org/pub/firmware/ Then it works fine either on SD card or USB pendrive of 2 GB minimum and you can still boot and use the native fedora XO build. With SD cards you could need some swap that can be made with a file /swap.bin as explained at http://www.olpcnews.com/forum/index.php?topic=4053.0 However, I have to compile a more recent kernel because the 2.6.25 version on that debian lenny is not sufficient for some of my experiments. With all the wiki documentation pages I don't know on which I should write. Regards Aimé > paul > =- > paul fox, p...@laptop.org > ___ > Olpc-france mailing list > olpc-fra...@lists.laptop.org > http://lists.laptop.org/listinfo/olpc-france > > > signature.asc Description: OpenPGP digital signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
On Fri, Mar 13, 2009 at 07:27:47PM +0100, Aime Vareille wrote: > However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good > because it puts the fedora kernel on the ubuntu which works with some > discrepencies ; it takes also some time because of qemu and the boot is > not optimal. Fedora and Ubuntu use the same upstream source for the kernel. What are these discrepencies, and why aren't they fixed? -- James Cameronmailto:qu...@us.netrek.org http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [Olpc-france] extend the memory flash space with an SD card to build open80211s
look at using debxo to give you a debian install on the XO David Langp...@laptop.org a écrit : > rekik wrote: > > Hi, > > > > I tried to build the kernel open80211s on a group of machines which use > > ubuntu 8.10 and it's work. Now I had to build it on an XO. The problem > > is that I don't have enough space on my flash memory ( 1Go ). So, I had > > to extend it with an SD card ( to have a space > 1024 Mo), but I > > don't know the steps to make this solution and the minimum size of the > > SD card.. > > > > can anyone help me !!! > > it sounds like you're trying to do the build of open80211s on > the XO itself. most people don't do development for the XO that way -- > we build on another machine, and move the binaries onto the XO. > > for simple programs, you can build on most any modern linux > distribution and your binary will work on the XO, because the > libraries and environment tend to be compatible. (you could > perhaps build a static binary to be sure.) > > the XO is based on fedora, so a fedora machine will be the best > build host. > Yes, but debian can also run on XO. However I found http://wiki.laptop.org/go/Ubuntu_On_OLPC_XO not good because it puts the fedora kernel on the ubuntu which works with some discrepencies ; it takes also some time because of qemu and the boot is not optimal. Today, the stuff with debian on XO is cleaner and very fast to install and test ; http://wiki.laptop.org/go/DebXO is the best page I found about it : # zcat debxo-$DESKTOP.ext3.img.gz > /dev/sdX (for instance, sdb; not sdb1) And update the firmware to q2e34.rom at http://dev.laptop.org/pub/firmware/ Then it works fine either on SD card or USB pendrive of 2 GB minimum and you can still boot and use the native fedora XO build. With SD cards you could need some swap that can be made with a file /swap.bin as explained at http://www.olpcnews.com/forum/index.php?topic=4053.0 However, I have to compile a more recent kernel because the 2.6.25 version on that debian lenny is not sufficient for some of my experiments. With all the wiki documentation pages I don't know on which I should write. Regards Aimé > paul > =- > paul fox, p...@laptop.org > ___ > Olpc-france mailing list > olpc-fra...@lists.laptop.org > http://lists.laptop.org/listinfo/olpc-france > > > signature.asc Description: OpenPGP digital 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: announce: alternate power management
> configurable timeouts for screen dim and sleep. the dim > level is configurable. My XO systems are plugged in to the AC, so I normally leave them running 24/7. But in the middle of the night if I happen to walk by, I notice if they are acting as "light sources". Two concerns (for which I don't know whether doing anything is feasible): - Rawhide. AFAIK there currently is no dimming support at all. I either have to power off such an XO overnight, or have to close the lid while the backlight is still lit. It would be useful if rawhide supported dimming/shutting_off the screen when no one is looking at it (irrespective of whether the CPU is doing work or not). - Suspend. It was functioning well only with Joyride - but I hope it gets implemented other places as well. The problem is - the CPU may suspend because it is idle (and partly dim the screen), but the user may still continue looking at that screen (in color mode) while the XO is suspended. After a decent interval at half-bright, it is reasonable to assume the user has "seen enough", and the screen could now be dimmed all the way off. BUT since the system is "sleeping", the current implementation has no way to "wake up" the system just so it can execute 'screen dim' instructions. The result is that if I don't intervene at the keyboard, my suspended (Joyride) XO's screen remains half-bright throughout the night. I think it counter-productive to suspend the rest of the system (to save power!) when no one is using it, but to leave the screen lit (still drawing power!) once it can be presumed no one is using it any more. > different power behavior when in ebook mode (though detection > may be unreliable -- i think the ebook switch suffers from > some issues we previously noticed with the lid switch). What issues ? I thought the lid switch could be fooled by people with magnets - but that an actual "shut" would always be recognized as being a "shut" (and a failure to recognize an "open" could be overcome by momentarily pressing the power button). mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
