Re: [Sugar-devel] SoaS and new netbooks
On Tue, Sep 14, 2010 at 2:16 AM, Art Hunkins abhun...@uncg.edu wrote: Does anyone know whether SoaS USB sticks will boot onto the new 7 netbooks ($100US)? The OS is WindowsCE 6.0 professional, and there are 3 USB2.0 ports. Video resolution is 800x480. Unlikely as anything that runs WindowsCE is likely to be ARM. Do you have a model number? I usually recommend the Acer Aspire One devices. I can't remember exactly the model but I think it was the Acer Aspire One 532 and it works completely out of the box with SoaS v3. Regards, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 3:09 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: On Tue, Sep 14, 2010 at 5:27 AM, Simon Schampijer si...@schampijer.de wrote: Hi, what is the current status for activity releases in order to include them in distributions like Soas*? Do you guys need tarballs or did you switch over to construct the rpms from the .xo? For example the latest Paint rpm uses the .xo AFAIK (build even the binaries from the non-python sources in the bundle). And is the email from ASLO enough for packagers to know about new releases? Any other notification that packagers need? In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 11:27 AM, Simon Schampijer si...@schampijer.de wrote: Hi, what is the current status for activity releases in order to include them in distributions like Soas*? Do you guys need tarballs or did you switch over to construct the rpms from the .xo? For example the latest Paint rpm uses the .xo AFAIK (build even the binaries from the non-python sources in the bundle). In some cases we've used .xo files but its not ideal and its caused us packaging issues in Fedora as in a lot of cases the .xo files include binary blobs which is against Fedora packaging policies so we have to jump through extra hoops and its generally a pain we'd like to avoid! Personally I'm moving to the point where if there's not a tarball I won't spend my time packaging it. And is the email from ASLO enough for packagers to know about new releases? Any other notification that packagers need? That is generally enough but a direct link to both the .xo and tarball makes it quicker for me to update packages as I can grab it from the email. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Policy for activities for downstream inclusion
On Tue, Sep 14, 2010 at 10:51 PM, Bert Freudenberg b...@freudenbergs.de wrote: On 14.09.2010, at 23:15, pbrobin...@gmail.com wrote: On Tue, Sep 14, 2010 at 3:09 PM, Walter Bender walter.ben...@gmail.com wrote: On Tue, Sep 14, 2010 at 10:05 AM, David Farning dfarn...@gmail.com wrote: In the .deb side of the universe, we prefer tarballs but we can work directly from the git repository. Is it not still the practice to put tarballs on download.sl.o ??? No its not! Sebastian and I got sick of sounding like broken down records so I have no idea of the current status. Not sure I can parse what you mean. Are you saying it is not current practice but it should be? It seems it generally doesn't happen. No idea if its policy or not. And (from your other msg) why do you want both zip (xo) and tar balls? I just want sure source code only tarfiles. I presume for a.sl.o there's a need for ready to run .xo files which may or may not contain pre compiled binaries. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Tue, Sep 7, 2010 at 9:40 AM, Simon Schampijer si...@schampijer.de wrote: On 09/06/2010 03:40 PM, pbrobin...@gmail.com wrote: On Mon, Sep 6, 2010 at 2:05 PM, Daniel Draked...@laptop.org wrote: On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi, I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get some discussions started on what changes need to be made to Sugar to work well in an environment where multiple users will work on the same machine (which is how Peru's next 300,000 XOs will be used: http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). Obviously this touches upon a lot of areas from simple naming of the machine, over the Journal, backups and probably a whole host of other issues that I haven't though of yet. When we discussed this while I was in Peru, one requirement they identified is that the kid would log onto an XO one day and do some work, and then log onto another XO the following week and continue the same work. Assuming this still stands, this strongly calls for a network-based home directory system with some kind of network login service (but someone with experience in such areas should comment). This would require a number of changes at the OS level and server level, but Sugar would be left untouched, as far as I can think. The standard way of doing this in unix is to use nfs and automount with NIS/LDAP authentication. This would mount the users home directory on login. There's a number of issues that come up with this implementation for the XOs in that wireless would need to connect prior to this and NFS over wifi would be interesting at best due to wifi dropouts. To mitigate that problem you'd probably have to wedge some of the caching filesystems that are being developed to allow the home directory to be cached. Suddenly your getting a very complex solution to fix the problem. Yes, this is true. I obviously used wired connections when using LDAP/NFS. In a lap with fixed equipment this is an easy setup. For the XOs, I agree this could lead to frustration. (even in my case kids very confused because someone has pulled the cables) The other possible alternative to this would be to use something like couchdb to store the contents of the journal and associated config files where you can have a local couchdb that replicates to a remote service. This might be the simpler solution but would obviously require development. Peter Interesting. A solution where you only need to sync twice (start/stop) might be better in the wifi environment. It is something that I've been meaning of trying to dogfood as a concept as I think it would be a perfect cloud (and yes I frickn hate the term) storage solution for deployments as it allows you to change servers, move storage etc without having to reconfigure the client side. I got as far as setting up the server side of things and playing around with evolution-couchdb for storing evo contacts but no further. There's some glib helper files. I was actually hoping to get more time to play with this more once Fedora 14 / SoaS 4 is out the door. I have some server resources available to set up the server side if anyone else is interested as well. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Sugar to support multiple users
On Mon, Sep 6, 2010 at 2:05 PM, Daniel Drake d...@laptop.org wrote: On 5 September 2010 13:57, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi, I just created a new ticket (http://bugs.sugarlabs.org/ticket/2292) to get some discussions started on what changes need to be made to Sugar to work well in an environment where multiple users will work on the same machine (which is how Peru's next 300,000 XOs will be used: http://www.olpcnews.com/countries/peru/peru_between_one_laptop_per_child_and_seven_children_per_laptop.html). Obviously this touches upon a lot of areas from simple naming of the machine, over the Journal, backups and probably a whole host of other issues that I haven't though of yet. When we discussed this while I was in Peru, one requirement they identified is that the kid would log onto an XO one day and do some work, and then log onto another XO the following week and continue the same work. Assuming this still stands, this strongly calls for a network-based home directory system with some kind of network login service (but someone with experience in such areas should comment). This would require a number of changes at the OS level and server level, but Sugar would be left untouched, as far as I can think. The standard way of doing this in unix is to use nfs and automount with NIS/LDAP authentication. This would mount the users home directory on login. There's a number of issues that come up with this implementation for the XOs in that wireless would need to connect prior to this and NFS over wifi would be interesting at best due to wifi dropouts. To mitigate that problem you'd probably have to wedge some of the caching filesystems that are being developed to allow the home directory to be cached. Suddenly your getting a very complex solution to fix the problem. The other possible alternative to this would be to use something like couchdb to store the contents of the journal and associated config files where you can have a local couchdb that replicates to a remote service. This might be the simpler solution but would obviously require development. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] screenreader for sugar
On Wed, Sep 1, 2010 at 10:24 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:10, Tomeu Vizoso to...@sugarlabs.org wrote: On Fri, Aug 20, 2010 at 14:08, Esteban Arias ear...@plan.ceibal.edu.uy wrote: hi, we can colaborate with this proyect. Excelent, have you tried already orca with Sugar? And with GNOME? I would say that the next step is for someone who knows how orca is used to give it a try and file tickets for the biggest issues. Not sure we can make much more until then. The gnome guys mentioned this the other day and there's going to be some more work done within gnome hopefully for F-14. So hopefully we should be looking better for that release. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Request for comments: A Proposed way to report Soas tests
On Wed, Sep 1, 2010 at 4:11 PM, Caryl Bigenho cbige...@hotmail.com wrote: Hi Tom and all... You have done a great job organizing this. The only thing I would suggest is adding something for Mac testers, maybe a separate chart, that refers to the method (and version of the method) they are using... Virtual Box or boot-helper CD or something else if something else will work too. Also, it should include the model of the Mac. There are actually some folks in SoCal who are working on trying to get it to run on the old G4 (PowerPC) Macs. How are they using PowerPCs? What PPC distribution are they using for this? Peter Caryl Date: Wed, 1 Sep 2010 07:50:32 -0700 From: satel...@bendbroadband.com To: s...@lists.sugarlabs.org CC: sugar-devel@lists.sugarlabs.org Subject: [SoaS] Request for comments: A Proposed way to report Soas tests I have been using this format to report testing of Soas Nightly Composes. [1] Please comment on the usability of such a format. Tom Gilliard satellit [1] http://wiki.sugarlabs.org/go/Talk:Sugar_on_a_Stick_release_process#Test_Matrix ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Read in Fedora 14
It lives well it will do in updates testing as of tomorrow's compose. The appropriate update that needs your attention (and positive karma) is: https://admin.fedoraproject.org/updates/gnome-python2-desktop-2.31.1-5.fc14 So with luck SoaS 4 should have a working eReader. Cheers, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New dependency on gnome-keyring-daemon (was: Re: [RELEASE] sugar-0.89.5)
On Mon, Aug 30, 2010 at 8:11 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sat, Aug 28, 2010 at 11:58, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Fri Aug 27 12:21:19 +0200 2010: * Launch gnome-keyring-daemon from sugar-emulator This means I need to add a new dependency to sugar-jhbuild (as will distro packagers once Sugar 0.90 is released), If you are using mission-control from distro packages in jhbuild, you are most likely to have already an implementation of org.freedesktop.Secret installed. If not, we can build telepathy-mission-control without the dependency on gnome-keyring-daemon. adding about 6MB on my XO (and potentially more on other systems). Hmm, are you using sugar-emulator on your XO? What's the rationale for this change? The commit comment is rather sparse. As Peter already replied, it's used by telepathy-mission-control, but is not a hard dependency. So we have some alternatives to not requiring it unconditionally: If you disable gnome-keyring on t-m-c it stores password unencrypted so its probably not advisable. I'm surprised we don't already need gnome-keyring for NetworkManager. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Add dependency on pyXDG
On Wed, Aug 25, 2010 at 3:16 PM, Simon Schampijer si...@schampijer.de wrote: Hi, pyxdg [1] provides facilities to access freedesktop.org standards. We would like to add it as a dependency to the sugar platform. Real life example [2]: In sugar-jhbuild this will not discover that these files are not under sugar/jhbuild/install/share but can be found under /usr/share. pyxdg provides means to get a list of all the available paths. Comments? I presume this is for the base sugar package and will be announced against the package release that introduces is so I can update the rpm spec to ensure its included. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] New dependency on gnome-keyring-daemon (was: Re: [RELEASE] sugar-0.89.5)
On Sat, Aug 28, 2010 at 10:58 AM, Sascha Silbe sascha-ml-reply-to-201...@silbe.org wrote: Excerpts from Tomeu Vizoso's message of Fri Aug 27 12:21:19 +0200 2010: * Launch gnome-keyring-daemon from sugar-emulator This means I need to add a new dependency to sugar-jhbuild (as will distro packagers once Sugar 0.90 is released), adding about 6MB on my XO (and potentially more on other systems). What's the rationale for this change? The commit comment is rather sparse. telepathy-mission-control requires it which is used in the new messaging stuff that Tomeu has been doing to store user credentials. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Fwd: Dependency on python-cjson - dead upstream]
Hi Bernie, Funny this should come up. When Sebastian and I were packaging up sugar and deps for EPEL-6 I discovered this and scratched my head over it but haven't had time to follow up. Looking through the various sugar packages I see most of them use python-simplejson so if it could be verified that sugar-datastore does in fact work with python-simplejson I would happily change it over to simplify and reduce deps. Peter On Tue, Aug 24, 2010 at 2:05 AM, Bernie Innocenti ber...@codewiz.org wrote: Forwarding to the Sugar development list. IIRC, we had switched to cjson only for a short time. Sugar 0.88 uses simplejson. So, maybe the dependencies of the rpm have not been adjusted accordingly. - Mensaje reenviado De: Felix Schwarz felix.schw...@oss.schwarz.eu Para: sugar-datastore-ow...@fedoraproject.org, python-cjson-ow...@fedoraproject.org Asunto: Dependency on python-cjson - dead upstream Fecha: Mon, 23 Aug 2010 20:32:29 +0200 Hi, sugar-datastore in Fedora currently depends on python-cjson. The latter package has basically a dead upstream and a lot of bugs that never will be fixed. As sugar-datastore is the only package in Fedora that requires python-cjson I'm curious if it would be possible to get rid of python-cjson in Fedora. Usually it is quite easy to migrate to python-simplejson (or just to use the built-in JSON module from Python itself). Please note: I'm just asking how hard your dependency on cjson is, I'm not planning on removing the package immediately. (actually I'm not even the maintainer of that one :-). fs -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Fwd: Dependency on python-cjson - dead upstream]
On Tue, Aug 24, 2010 at 1:42 PM, Jonas Smedegaard d...@jones.dk wrote: On Tue, Aug 24, 2010 at 08:54:38AM -0300, Bernie Innocenti wrote: El Tue, 24-08-2010 a las 10:10 +0100, pbrobin...@gmail.com escribió: Hi Bernie, Funny this should come up. When Sebastian and I were packaging up sugar and deps for EPEL-6 I discovered this and scratched my head over it but haven't had time to follow up. Looking through the various sugar packages I see most of them use python-simplejson so if it could be verified that sugar-datastore does in fact work with python-simplejson I would happily change it over to simplify and reduce deps. No, it indeed still uses cjson. Sascha, could you provide a patch to convert it to simplejson? Please beware that sugar-toolkit, and activities Browse, Chat, Read and Speak, also use cjson. sugar-toolkit according to the requires in the spec file uses python-simplejson but that doesn't mean that its historically wrong and just works due to the fact that sugar-datastore pulls in the dep. The others don't have the explicit requires but then again that is likely because sugar-datastore and associated deps are available. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] screenreader for sugar
On Fri, Aug 20, 2010 at 10:16 AM, Tomeu Vizoso to...@sugarlabs.org wrote: Hi, is there any interest in a deployment somewhere for a screenreader that allows blind people use the Sugar UI when paired with keyboard navigation? I think most of the pieces are there, but without knowing how it could be used I cannot really test. there's speechdispatcher in fedora that is used by kde and gnome and I currently maintain it. It was also at some point used by olpc as the spec file use to have olpc specifics in it. There's been renewed interest with it upstream and I'm working to get it into better shape for F-14 and once its cleaned up I'll push updates back to F-13 and probably F-12. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Killing activities when memory gets short
On Sun, Aug 8, 2010 at 2:33 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Sun, Aug 8, 2010 at 15:15, Martin Langhoff martin.langh...@gmail.com wrote: On Sun, Aug 8, 2010 at 4:01 AM, Tomeu Vizoso to...@sugarlabs.org wrote: I tihnk I have been sloppy with my words, so let me clarify two things: - killing processes should be done only to avoid OOM (because currently the kernel kills the wrong thing most of the time). Can't we just _close it nicely_? When you are about to get into OOM? Don't think so because it's very probable that the kernel will block or kill something randomly before the activity or the user react. But as I said, before we reach this point we should have given the activities and/or the user the option to avoid this situation. Not sure what the requirements would be of implementing something like iphone/ipod (well versions prior to 4) where when the Activity is backgrounded it saves its state and quits so you don't really have more than one app running at a time? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read and evince issues in F-14 (again!)
On Wed, Aug 4, 2010 at 12:15 PM, Tomeu Vizoso to...@sugarlabs.org wrote: On Tue, Aug 3, 2010 at 12:12, pbrobin...@gmail.com pbrobin...@gmail.com wrote: So it seems somehow that Read is the one with all the bad luck at the moment... It currently broken in F-14 and rawhide due to the gnome-python2 evince bindings being disabled as it doesn't look like at the moment that they're coming back anytime soon [1]. I'm going to work on this from a couple of angles to see what the options are. So firstly this is a heads up to the issue. Secondly I would like some feed back to what the options are. I get the feeling that we should be looking at the pygi bindings for evince (yea Tomeu I'm looking at you for feed back here :-D ) and what other options sugar develops think we might have here. Well, we shouldn't have waited so long to invest on introspected bindings, these kind of platform changes take some planning or surprises like this happen. But for this particular case, now that Gtk+ 3.0 has been delayed some months, maybe it's not a problem any more for F14? Its not final but it looks like it may well remain broken. There were details in the link below. Hence the query. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity packaging
On Tue, Jul 6, 2010 at 5:02 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: On 07/06/2010 11:51 AM, Bernie Innocenti wrote: Ok, I think the requirements for activity bundles could be: 1) Support multiple CPU architectures 2) Support multiple distros (and different versions of same distro) 3) Centralized build cluster (submit one source package, get multiple binary packages) 4) Support inter-bundle dependencies (e.g.: GCompris + voices, OOo4Kids + dictionaries) 5) Support activity - OS dependencies (e.g.: espeak for Speak, squeak for etoys...) 6) Work with any programming language (setup.py is python-centric) 7) Easy to learn for activity writers without too much distro-hacking experience These requirements would fit well both rpm and deb, with OpenSUSE Build Service or their native build clusters. I think you are missing an important requirement: installation without elevated permissions. PackageKit can already do that. There was a furore around 6 months ago when someone enabled it by default for Fedora. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Read and evince issues in F-14 (again!)
So it seems somehow that Read is the one with all the bad luck at the moment... It currently broken in F-14 and rawhide due to the gnome-python2 evince bindings being disabled as it doesn't look like at the moment that they're coming back anytime soon [1]. I'm going to work on this from a couple of angles to see what the options are. So firstly this is a heads up to the issue. Secondly I would like some feed back to what the options are. I get the feeling that we should be looking at the pygi bindings for evince (yea Tomeu I'm looking at you for feed back here :-D ) and what other options sugar develops think we might have here. Peter [1] http://lists.fedoraproject.org/pipermail/desktop/2010-August/thread.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] touchpad section for Sugar Control Panel
On Wed, Jul 28, 2010 at 3:41 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Excerpts from Paul Fox's message of Wed Jul 28 16:01:22 +0200 2010: sascha wrote: Even your latest patch still contains code that is specific to OLPC builds and will break on other systems. Of course it's perfectly fine for you to say you only care about OLPC builds for XO-1 (because the number of XO-1s running non-OLPC builds is minimal, especially if you don't count developers). But in that case your patch should be included in the OLPC builds, not in Sugar mainline. can you remind me of the specific issue(s) here? I can remember two issues (there might be others as well): - hardcoded, absolute path (/home/olpc/whatever) I agree that it shouldn't ever user /home/olpc as hardcoded. At least you ~/.olpc-blah as it will then work on what ever distro and what ever user. I'm not sure of the general standard to use for this. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Fedora 14 / SoaS 4 changed heads up
On Sun, Jul 25, 2010 at 12:45 AM, Walter Bender walter.ben...@gmail.com wrote: On Sat, Jul 24, 2010 at 6:21 PM, pbrobin...@gmail.com pbrobin...@gmail.com wrote: Hi All, I thought I'd send a message to give people a heads up to the changes that are going into Fedora 14 that might have an impact on sugar. Thanks. This is helpful. Question: during the Posse workshop we bumped up against some pulseaudio issues, as I recall. Anything happening on that front? Or with gstreamer? The problem with the POSSE spin from memory was because a couple of packages that were needed in certain circumstances weren't installed. That's been fixed. Peter So the major changes are... in no particular order: - gnome 3 and all the associated changes. There's going to be api changes. This has already hit us with Read - python 2.7 (no idea of the impact of this but its about to hit rawhide) - xapian 1.2 - csound 5.12 (I'm hoping to get this in shortly) - systemd. For that those that don't know this is a massive change to the init process. I don't think it should impact badly. There's likely to be something I've missed but I think that's the major changes to be aware of. Let me know if you have any queries. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Fedora 14 / SoaS 4 changed heads up
Hi All, I thought I'd send a message to give people a heads up to the changes that are going into Fedora 14 that might have an impact on sugar. So the major changes are... in no particular order: - gnome 3 and all the associated changes. There's going to be api changes. This has already hit us with Read - python 2.7 (no idea of the impact of this but its about to hit rawhide) - xapian 1.2 - csound 5.12 (I'm hoping to get this in shortly) - systemd. For that those that don't know this is a massive change to the init process. I don't think it should impact badly. There's likely to be something I've missed but I think that's the major changes to be aware of. Let me know if you have any queries. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hosting activities(and its deps) sources(and not only) tarballs
On Tue, Jul 20, 2010 at 5:04 PM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, I'm working on Zero Sugar packaging infrastructure and wandering how to solve activity tarballs/bundles/etc hoisting issue. How does 0sugar work with multiple architectures such x86/x86_64/ARM? Peter Until now, I kept in mind only rsync access to remote directory (on sunjammer by default). But I guess it is overkill to require arbitrary activity developer to have ssh access to sunjammer (but it fine for core/fructose developers). There could be, at least, several options: * OBS (hosted by openSUSE or SL). http://wiki.opensuse.org/openSUSE:Build_Service It is full functional packaging environment but mainly targeting to native packages. But at the end, activities could be implicitly turned (using 0sugar) to native packages just by having an analog of existed activity.info file. So, we can have one packaging/code-sharing portal for developers (in comparing with sharing portal for users - ASLO). * reuse ASLO. It is already used for .xo uploads, but .xo, as primary sharing model, should die at earlier or later. Activity developers will upload sources (manually or via tools like 0sugar) to ASLO via web UI or http api like OBS has (https://api.opensuse.org/apidocs/). Any ideas? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
On Tue, Jul 20, 2010 at 2:27 AM, Gonzalo Odiard godi...@gmail.com wrote: Yeah How we detect what keyboard is present? Wouldn't you be better of using xkeys or what ever gtk uses and they you don't need to what keyboard is present, it would just work. Peter On Mon, Jul 19, 2010 at 9:26 PM, Walter Bender walter.ben...@gmail.com wrote: On Mon, Jul 19, 2010 at 5:20 PM, Paul Fox p...@laptop.org wrote: i'd like to bring this discussion to a conclusion. i'm starting to be a fan of this proposal of bert's -- it's very simple, keeps the keys the same in sugar and in gnome, and on membrane and non-membrane keyboards, it's backwards compatible with existing use on XO-1, and the volume/ brightness keys remain easily discoverable. it does require that sugar respond to F5 and F6 for journal and frame -- i still don't have a feeling for whether that's an issue or not, and if so, how big. The only activity I am aware of that uses F5 and F6 on the XO is the most recent version of Paint that Gonzolo is working on. Presumably these keymaps could be grabbed by Paint when running on an OLPC XO 1.0 or when we detect the membrane keyboard. Otherwise, we could keep the mapping as Bert suggests. any yeas or nays? Yeah. paul bert wrote: On 17.07.2010, at 09:31, Bernie Innocenti wrote: El Thu, 15-07-2010 a las 23:08 -0400, Paul Fox escribió: i think everyone (except apple, i'm learning tonight) agrees this is the correct setup when not in sugar. Lenovo also seems to be switching to the Apple layout: http://www.blogcdn.com/www.engadget.com/media/2010/01/thinkpadedgepost16.jpg http://www.thinkpads.com/wp-content/gallery/lenovo-thinkpad-edge-13-review/lenov o-thinkpad-edge-13-keyboard.jpg Almost all the historic F-key mappings have an alternative CTRL+key or ALT+key mapping in modern HIGs. Keys to control laptop volume and brightness are accessed much more frequently, so it's foreseeable that over time they will supplant the F-keys in PC keyboards. +1 IMHO pressing fn to get f1 to f10 makes sense. In my daily routine I much more often change volume or brightness than use the numbered F keys. Looking at this again http://wiki.laptop.org/go/OLPC_Spanish_Non-membrane_Keyboard I propose: f1-f8 produce F key codes both with and without the fn key f9-f12 produce F codes only with fn, and volume/brightness events without fn. So holding down fn always gets you the F key codes, you can change volume/brightness without modifier, and as a bonus you can use the first eight F keys even without the fn key. This mapping should work both in Sugar and outside. - Bert - ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Gonzalo Odiard Responsable de Desarrollo Sistemas Australes ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] SoaS-4 Feature Freeze approaching
Hi All, Just a reminder that SoaS-4 feature freeze is rapidly approaching. The feature freeze is July 27th. So we're a little under 2 weeks away from feature freeze so please get your features in. If you need help or have queries regarding the process please email the soas list. Regards, Peter BTW the first release of sugar 0.89 will be in tomorrow's nightly SoaS build... get it first here [1] :-) [1] http://alt.fedoraproject.org/pub/alt/nightly-composes/soas/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] icon-slicer and sugar-artwork
On Sun, Jul 11, 2010 at 7:28 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Excerpts from pbrobin...@gmail.com's message of Sun Jul 11 16:47:41 + 2010: [...] It currently needs icon-slicer but I think its an old dep that is still in configure.ac but no longer used, if I drop it out of configure.ac and rebuilt it all builds OK without it. It will fail, but in a non-obvious way. Here's the relevant part of the build log after applying your patch and removing icon-slicer from the system: make[3]: Entering directory `/home/sascha.silbe/sugar-jhbuild/source/sugar-artwork/cursor/sugar' image-dir=../../cursor/sugar --output-dir=../../cursor/sugar ../../cursor/sugar/sugar.cursortheme /bin/bash: image-dir=../../cursor/sugar: No such file or directory make[3]: [sugar.stamp] Error 127 (ignored) Let's take a look at the corresponding make rule: sascha.si...@xo-bine:~/sugar-jhbuild/source/sugar-artwork$ grep -B 1 -A 2 ICON_SLICER cursor/sugar/Makefile.am sugar.stamp: $(sugar_images) $(THEMEGEN) sugar.cursortheme $(ICON_SLICER) --image-dir=$(IMAGE_DIR) --output-dir=$(OUTPUT_DIR) $(IMAGE_DIR)/sugar.cursortheme touch sugar.stamp Since ICON_SLICER is never set, $(ICON_SLICER) will expand to the empty string. So the line make tries to execute is: --image-dir=../../cursor/sugar --output-dir=../../cursor/sugar ../../cursor/sugar/sugar.cursortheme A leading minus means ignore the exit status of this command and will be removed prior to executing the command. Apparently the second minus is stripped as well, so make will try to execute image-dir=../../cursor/sugar --output-dir=../../cursor/sugar ../../cursor/sugar/sugar.cursortheme and ignore the exit status. See Debian #555963 for what will happen at runtime if icon-slicer doesn't work (or isn't installed). Interesting, icon-slicer is only a build time dep in Fedora and so isn't installed at runtime. Unless you mean build time in referring to run time? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Announce: OLPC software strategy.
Hi Chris, Well done to the team for all the hard work! Now that the 10.1.1 release for XO-1.5 is out, it's a good time to talk about OLPC's software strategy for the future. We've got a few announcements to make: XO-1: = OLPC wasn't planning to make a Fedora 11 release of the XO-1 OS, but a group of volunteers including Steven Parrish, Bernie Innocenti, Paraguay Educa and Daniel Drake stepped up and produced Fedora 11 XO-1 builds that follow the OLPC 10.1.1 work. I'm happy to announce that we're planning on releasing an OLPC-signed version of that work, and that this release will happen alongside the next XO-1.5 point release in the coming weeks. So, OLPC release 10.1.2 will be available for both XO-1 and XO-1.5 at the same time, and will contain Sugar 0.84, GNOME 2.26 and Fedora 11. We think that offering this fully interoperable software stack between XO-1 and XO-1.5 laptops will greatly aid deployments, and we're very thankful to everyone who has enabled us to be able to turn this XO-1 work into a supported release! Excellent news! To prepare for this XO-1 release, we've started working on fixing some of the remaining bugs in the community F11/XO-1 builds. Paul Fox recently solved a problem with suspend/resume and wifi in the F11/XO-1 kernel, which was the largest blocker for a supported release. We'll continue to work on the remaining bugs, particularly the ones that OLPC is uniquely positioned to help with. The first development builds for this release will be published later this week. XO-1.5: === We'll be continuing to work on XO-1.5 improvements, incorporating fixes to the Known Problems section of the 10.1.1 release notes¹ into the 10.1.2 release. Now that the major release is out what are the plans for upstreaming the kernel and other changes for both the XO-1.5 as well as the remaining bits for the XO-1? XO-1.75 and beyond: === XO-1.75 software development is underway. Today we're announcing that we're planning on using Fedora as the base distribution for the XO-1.75. This wasn't an obvious decision -- ARM is not a release architecture in Fedora, and so we're committing to help out with that port. Our reasons for choosing Fedora even though ARM work is needed were that we don't want to force our deployments to learn a new distribution and re-write any customizations they've written, we want to reuse the packaging work that's already been done in Fedora for OLPC and Sugar packages, and we want to continue our collaboration with the Fedora community who we're getting to know and work with well. We've started to help with Fedora ARM by adding five new build machines (lent to OLPC by Marvell; thanks!) to the Fedora ARM koji build farm, and we have Fedora 12 and Sugar 0.86 running on early 1.75 development boards. We'd prefer to use Fedora 13 for the XO-1.75, but it hasn't been built for ARM yet -- if anyone's interested in helping out with this or other Fedora ARM work, please check out the Fedora ARM page on the Fedora Wiki². We're also interested in hiring ARM and Fedora developers to help with this; if you're interested in learning more, please send an e-mail to jobs-engineer...@laptop.org. Very interested in helping out, pushing builds etc through koji so let me know what needs attention and I'll help out where I can. We'll also be continuing to use Open Firmware on the XO-1.75, and Mitch Bradley has an ARM port of OFW running on our development boards already. EC-1.75 open source EC code: OLPC is proud to announce that the XO-1.75 embedded controller will have an open codebase (with a small exception, see below). After much behind-the-scenes effort, EnE has agreed to provide us with a public version of the KB3930 datasheet and is allowing our new code to be made public. The code is not available yet due to a few chunks of proprietary code that need to be purged and some other reformatting. A much more detailed announcement will be provided once the new code is pushed to a public repository. The code will be licensed under the GPL with a special exception for OLPC use. The exception is because EnE has not released the low-level details on the PS/2 interface in the KB3930, so there will be some code that is not available -- relative to the codebase this is a very small amount of code. The GPL licensing exception will allow for linking against this closed code. We're going to investigate ways to move away from this code in the future. (As far as we're aware, this will make the XO-1.75 the first laptop with open embedded controller code!) Multi-touch Sugar: == We've begun working on modifications to Sugar to enable touchscreen and multitouch use (the XO-1.75 will have a touchscreen, as will future OLPC tablets based on its design), and we'll continue to do so. The first outcome from this work is Sayamindu
Re: [Sugar-devel] Opportunity: migration from Gconf to GSettings
On Thu, Jul 8, 2010 at 9:18 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Thu, Jul 8, 2010 at 10:01, Simon Schampijer si...@schampijer.de wrote: Hi, while drafting the 0.90 schedule [1] I came across the migration from Gconf to GSettings in GNOME [2]. This is dependent on introspection, so not something for 0.90 but would be nice to have it ready in 0.92. If someone wants to work already on it, it would be a valuable and highly appreciated task. Wonder which backend would be most adequate for Sugar, dconf, gkeyfile, ...? What impact does what gnome upstream uses or what a distribution uses/ Can you mix backends? Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Write-70
On Tue, Jul 6, 2010 at 5:00 AM, Sugar Labs Activities activit...@sugarlabs.org wrote: Activity Homepage: http://activities.sugarlabs.org/addon/4201 Sugar Platform: 0.86 - 0.88 Download Now: http://activities.sugarlabs.org/downloads/file/26971/write-70.xo Release notes: Fix startup zoom level (sl#1121) Could the Write developer upload a tar file to http://download.sugarlabs.org/sources/sucrose/fructose/Write/ Cheers, Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
