Re: joyride, staging builds, sugar releases
2009/2/12 victor victor.lazzar...@nuim.ie: Sorry to insist on this, but I have not got it quite yet. Joyrides = obsolete (even though the builder script keeps churning them out and telling the olpc devel list). Obsolete, but not really obsoleted by anything usable *yet*. staging = what are these? Obsolete too? This is where we are staging changes to be used in v8.2.1. release builds = only last week there was a release build announced on the olpc devel list. Are these obsolete too? You are referring to the v8.2.1 candidate release? This is not obsolete, it is being pushed to various deployments. And another thing: olpc-update is not to be used anymore, or is it still on? It is still on for v8.2. It's future is perhaps a bit uncertain (maybe once we have working pure-Fedora builds it won't be active for a while, but it possibly will be resuscitated or replaced in future). I think the real question is: who are you developing for? v8.2 is pretty frozen and slow moving - the upcoming 8.2.1 includes only a handful of fixes (plus a couple of features for much improved deployability, that do not really affect the user experience). It will be adopted by deployments over the next few months, and will continue to be rolled out for probably a long time (e.g. Uruguay still using build 656 even though development terminated a long time ago). There may be an 8.2.2 with a similar collection of small fixes, depending on demand from deployments. If you want to develop for these deployments on this timeline, then you should work on top of 8.2 (sugar-0.82) and limit yourself to activity-level changes only. As for the future, the hope is that we will have a similarly-functional OS that includes the latest version of sugar asap. OLPC is working with Fedora on this, and while I suspect that the end result will be pushed as a reference OS by OLPC, there are also some other efforts which I think OLPC would probably be happy to flash onto machines at the factory (I can't speak officially, I am only a volunteer right now), including debXO, and a possibility of the community taking the 8.2 OS release and adding sugar-0.84 and some other things as an intermediate step before the pure-Fedora builds are suitable replacements. However, I personally think that all of these efforts are 6-12 months away (at least) from producing something adoptable by deployments. If you want to develop for the-future-with-unknown-timeframe, then you should work upstream at sugarlabs for sugar-0.84. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: WARNING -- since about build 2590 I can get my permanent SD card (ext2 filesystem) completely corrupted - I've had to restore it twice. [This is a regression - with 2583 and earlier I never saw any SD corruption. Note that my systems have multiple USB devices.] Hi Mikus, Can you re-test with 2586 and then 2587? 2587 brought in a kernel configuration change (CONFIG_USB_SUSPEND) and I'm wondering if it is the root cause. You can just update the kernels if you feel comfortable updating kernel RPMS as per http://wiki.laptop.org/go/Kernel#Installing_OLPC_kernel_RPMs. 2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081210.1.olpc.05aa2d840dc7b96.i586.rpm pre-2587: http://dev.laptop.org/~dilinger/master/kernel-2.6.27-20081201.1.olpc.672cde9409f412e.i586.rpm Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride SD card corruption
On Dec 15 2008, at 08:23, Deepak Saxena was caught saying: nn Dec 12 2008, at 11:34, Mikus Grinbergs was caught saying: WARNING -- since about build 2590 I can get my permanent SD card (ext2 filesystem) completely corrupted - I've had to restore it twice. [This is a regression - with 2583 and earlier I never saw any SD corruption. Note that my systems have multiple USB devices.] Hi Mikus, Can you re-test with 2586 and then 2587? 2587 brought in a I mean 2588 insted of 2587 here if you decide to do a full build update. I miss-read the logs. Thanks, ~Deepak -- Deepak Saxena - Kernel Developer, One Laptop Per Child _ __o (o ---\, Give One Laptop, Get One Laptop //\ - ( )/ ( ) http://www.amazon.com/xoV_/_ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride Build 2582
Hi, The logs at http://dev.laptop.org/~bert/joyride-pkgs.html say: joyride-2582 (pkgs) ! Build incomplete Error Downloading Packages: Any idea someone? xs-dev was out of disk space, and isn't anymore; let's see what happens with the next build. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2578 does not boot on my XO
On Sat, Dec 6, 2008 at 7:08 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: The error I get is: File /usr/bin/sugar-session, line 30, in module import gconf ImportError: could not import gobject: (error was '/usr/lib/python2.5/site-packages/gtk-2.0/glib/_glib.so: undefined symbol: PySignal_SetWakeupFd') Thanks, I screwed up the changelog so my new python packages did not make it into this build. Should be fixed in 2579. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride build fixes cont
On Wed, Nov 19, 2008 at 11:50 AM, Peter Robinson [EMAIL PROTECTED] wrote: The ntp-ntpdate package is now called just ntpdate. I've tagged the standard F-10 build package for olpc-4 in koji so if someone could update the build script for the new name it should be fixed. Ah, I was wondering where this had gone. Updated pilgrim, thanks. The olpcsound package is built and tagged so should be pulled in for the next joyride. Great! The olpc-logos package I can't even see in 8.2-767 package list [2] so is it even relevant any more? If not can the person who can fix the ntpdate issue remove it from the list. Hmm, I'll leave this one for someone who understands more about the build system. This package is only included in the ext3 builds (which we don't use on the XO), and I don't really understand that difference. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride build fixes cont
On Wednesday 19 November 2008 05:50:29 am Peter Robinson wrote: Hi All, Looking further at the issues with joyride in particular the following 3 packages: ntpdate olpcsound olpc-logos Looking at the output of the pilgrim build logs [1] I see the following errors: Setting up Install Process Parsing package install arguments No package olpc-logos available. No package olpcsound available. No package ntp-ntpdate available. Resolving Dependencies The ntp-ntpdate package is now called just ntpdate. I've tagged the standard F-10 build package for olpc-4 in koji so if someone could update the build script for the new name it should be fixed. please untag it. it will be picked up through regular inheritance. by having it tagged any fedora updates will not get picked up automatically. The olpcsound package is built and tagged so should be pulled in for the next joyride. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride build fixes cont
On Wed, Nov 19, 2008 at 4:25 PM, Dennis Gilmore [EMAIL PROTECTED] wrote: please untag it. it will be picked up through regular inheritance. by having it tagged any fedora updates will not get picked up automatically. Hmm, then perhaps I should undo what I did yesterday (tagged 3 packages in the f10-updates queue for quicker joyride inclusion). But, I'm pretty sure we had things working differently for F9. If there was something pending we would tag it for earlier inclusion than normal. I'm pretty sure it was you who told me this, I documented it here: http://wiki.laptop.org/go/Joyride#Packages_without_OLPC-3_disttags Can we make things work the same way for F10? Saves the pain of waiting for the updates queue which is out of our hands. Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride build fixes cont
please untag it. it will be picked up through regular inheritance. by having it tagged any fedora updates will not get picked up automatically. Hmm, then perhaps I should undo what I did yesterday (tagged 3 packages in the f10-updates queue for quicker joyride inclusion). Those would then drop out as they haven't been pushed to F-10 due to the immentant release of F-10 so I can do them once I've had confirmation they've been pushed to mainline. But, I'm pretty sure we had things working differently for F9. If there was something pending we would tag it for earlier inclusion than normal. I'm pretty sure it was you who told me this, I documented it here: http://wiki.laptop.org/go/Joyride#Packages_without_OLPC-3_disttags Can we make things work the same way for F10? Saves the pain of waiting for the updates queue which is out of our hands. Once F-10 is out and rolling I suspect it will be less painful. Its just that we're so close to release. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride build fixes cont
Hi All, Looking further at the issues with joyride in particular the following 3 packages: ntpdate olpcsound olpc-logos Looking at the output of the pilgrim build logs [1] I see the following errors: Setting up Install Process Parsing package install arguments No package olpc-logos available. No package olpcsound available. No package ntp-ntpdate available. Resolving Dependencies The ntp-ntpdate package is now called just ntpdate. I've tagged the standard F-10 build package for olpc-4 in koji so if someone could update the build script for the new name it should be fixed. please untag it. it will be picked up through regular inheritance. by having it tagged any fedora updates will not get picked up automatically. Done. Sorry, still a bit raw on how the whole tagging side of things works. There doesn't seem to be a lot of documentation on how it works. Peter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride seems stuck
On Sun, Oct 19, 2008 at 4:21 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I pushed two packages yesterday but no joyride build was made. Did we disable automatic builds? Not that I know of, but I won´t be able to diagnose until later in the week. '--scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride-activities.py --mirror
Am 14.10.2008 um 05:01 schrieb James Cameron: Added a --mirror flag to joyride-activities.py so that the script can be used on a system without dbus or sugar, in order to create a mirror of the activity files for later pickup. git clone http://dev.laptop.org/~quozl/berts-script.git Thanks - merged. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride and 9.1 development
On Tue, Oct 7, 2008 at 2:24 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, is joyride open for 9.1 development now? Also, should we start work on rebasing on F10? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2369 - yum fails with key error
The patch in Ticket 8125 works for joyride-2370. Would you alert us in which build yum will work without the workaround? -- View this message in context: http://n2.nabble.com/joyride-2369---yum-fails-with-key-error-tp796070p832780.html Sent from the OLPC Software development mailing list archive at Nabble.com. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2369 - yum fails with key error
On Sun, Aug 31, 2008 at 02:55:18PM -0700, [EMAIL PROTECTED] wrote: If you try to use yum install in joyride 2369 it fails with a key error. Yup: http://dev.laptop.org/ticket/8125 Martin pgpUWUqTdo34P.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride releases
On Thu, Aug 21, 2008 at 10:48 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 22 Aug 2008, at 02:53, Ricardo Carrano wrote: I am reading a ticket (7967) that reports tests based on joyride 2302. But this version did not seem to be released (from 2301 it jumps to 2311). What am I missing? joyride-2302 was built, but turned out to be identical to joyride-2301. This happens sometimes: koji will indicate that there are new packages available, but they turn out to be packages which aren't actually included in our build, and so the end result is identical to the previous builds. The build announcer script at http://dev.laptop.org/~rwh/announcer/joyride-pkgs.html suppresses these duplicate builds but the build announcer script at http://dev.laptop.org/~bert/joyride-pkgs.html does not. In any case, they do exist and you can install them; it's just not very interesting to do so. Well as I understand it the fedora infrastructure outage stopped everything after 2302 until 2311, but I think 2311 may just have got in there by luck, as servers popped alive again for a short time, or because cscott was quick enough pulling needed packages from koji before it went off-line again (I'm not sure if he's confident he has everything needed mirrored yet). I switched joyride to our own mirror as of 2311, and then koji came back so I switched back, and then koji went down so I switched back to our mirror koji seems to be back now. I'm confident I've got everything mirrored, but since (presumably) the reason for the koji outages is security-related, we'll certainly want to grab package updates from koji when it comes back for good. If today's koji not-outage persists today, I hope we can get our backlog of packages tagged and in a build and maybe even make a new stable candidate. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride releases
On 22 Aug 2008, at 02:53, Ricardo Carrano wrote: I am reading a ticket (7967) that reports tests based on joyride 2302. But this version did not seem to be released (from 2301 it jumps to 2311). What am I missing? Hi Ricardo, Well as I understand it the fedora infrastructure outage stopped everything after 2302 until 2311, but I think 2311 may just have got in there by luck, as servers popped alive again for a short time, or because cscott was quick enough pulling needed packages from koji before it went off-line again (I'm not sure if he's confident he has everything needed mirrored yet). Folks are still keeping quiet as to why fedora infrastructure was taken off-line. Looking at Berts script is always useful I find, so 2302 was identical to 2301 (no change), and 2311 onwards has been fairly patch quiet and/ or a bit random: http://dev.laptop.org/~bert/joyride-pkgs.html So far I'm hanging back and sticking to work with 2301 until things stabilise and we get some confirmation of what has happened. Lots of new, and interesting changes to go test, but no XO images with them in yet (unless you have a jhbuild system set up and are willing to test only on an emulator). --Gary ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride version announcements
On Tue, Aug 19, 2008 at 09:53:22PM -0400, Polychronis Ypodimatopoulos wrote:
Why are new versions of Joyride not announced?
Bert pointed out http://dev.laptop.org/~rwh/announcer/streams.py to me
yesterday, and it look as if the announcer doesn't bother if the
joyride build hasn't succeeded ('Calling out the done script' is
present in the build.log). I checked yesterday and 2306-2303
(inclusive) had failed.
Pol
Martin
pgpe6yqiL5Mhm.pgp
Description: PGP signature
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: joyride version announcements
That's right, would people be interested in hearing about each failed build?
Regards,
Reinier
Martin Dengler wrote:
On Tue, Aug 19, 2008 at 09:53:22PM -0400, Polychronis Ypodimatopoulos wrote:
Why are new versions of Joyride not announced?
Bert pointed out http://dev.laptop.org/~rwh/announcer/streams.py to me
yesterday, and it look as if the announcer doesn't bother if the
joyride build hasn't succeeded ('Calling out the done script' is
present in the build.log). I checked yesterday and 2306-2303
(inclusive) had failed.
Pol
Martin
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
--
Reinier Heeres
Waalstraat 17
2515 XK Den Haag
The Netherlands
Tel: +31 6 10852639
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel
Re: joyride version announcements
That's right, would people be interested in hearing about each failed build? No. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride version announcements
There haven't been joyride build announcements, because there haven't been (successful) joyride builds, because RedHat's koji system has been down. Koji came up for a while yesterday (it seems to be down again today) and I pulled all the packages on the olpc-dist3 branch locally. I've now switched joyride over to building from this local mirror. I'll make a full announcement in a new thread here on devel@ as soon as I confirm that the joyride build from the mirror worked (ie, that the mirror is complete). --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
Chris Ball [EMAIL PROTECTED] writes: Hi, Hi list, where can I find images of the latest joyride for installing it with a USB key? Something similar to these images: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_ext3/ Anything under this directory is now emtpy: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/ 2302 is not empty, but 2303 is since midday. Something wrong? -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
On Aug 14 2008, at 21:35, Bastien was caught saying: Chris Ball [EMAIL PROTECTED] writes: Hi, Hi list, where can I find images of the latest joyride for installing it with a USB key? Something similar to these images: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_ext3/ Anything under this directory is now emtpy: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/ 2302 is not empty, but 2303 is since midday. Something wrong? Fedora's Koji build system that is used for some of our components is currently down (See mstone's prior email to this list from a few hours back.) From bottom of http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/build2303/devel_jffs2/build.log: http://koji.fedoraproject.org/static-repos/dist-olpc3-build-current/i386/repodata/repomd.xml: [Errno 12] Timeout: urlopen error timed out Trying other mirror. Error: Cannot retrieve repository metadata (repomd.xml) for repository: olpc_development. Please verify its path and try again * Unmounting special file systems from install root * Detaching disk and partition 1 (/dev/loop5 and /dev/loop6) - Cleaning up connections to loop devices * Deleting incomplete OS image -- Deepak Saxena - Kernel Developer - [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
Hi, Hi list, where can I find images of the latest joyride for installing it with a USB key? Something similar to these images: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_ext3/ (It would be great if you could add this to the place you think it should be in the wiki, thanks!) - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
Chris Ball [EMAIL PROTECTED] writes: Hi list, where can I find images of the latest joyride for installing it with a USB key? Something similar to these images: http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_ext3/ Shouldn't I use jffs2 instead? http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/ What is os2090.usb? Is it a standalone USB distribution of both the system and the activity bundle? Is this _what_ I'm looking for?? If I don't use os2090.usb maybe I can just go with os2090.img -- fine. But what about fs.zip? Is it safe to use the old (708) one? (It would be great if you could add this to the place you think it should be in the wiki, thanks!) I will as soon as I'm sure where to put what... Thanks again! -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride images for downloading and installing them with a USB key
Daniel Drake [EMAIL PROTECTED] writes: On Tue, 2008-08-12 at 16:31 -0500, Bastien wrote: Shouldn't I use jffs2 instead? If flashing to XO nand, yes. If booting from USB/SD, no. All right, thanks. http://xs-dev.laptop.org/~cscott/xo-1/streams/joyride/latest/devel_jffs2/ What is os2090.usb? Is it a standalone USB distribution of both the system and the activity bundle? Is this _what_ I'm looking for?? This is for the olpc-update --usb upgrade method. Not sure if that's what you're looking for or not. That wasn't, but I will test this method. What about the fs.zip file? Is it safe to use an old one? -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride-weekly: joyride-2230
On 31.07.2008, at 02:41, Michael Stone wrote: Dear world, This week's 'please test this joyride' is joyride-2230. Test group release notes, care of Charlie, are available at http://wiki.laptop.org/go/ Test_Group_Release_Notes#Build_Joyride_2230 olpc-update thinks that build does not exist. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
Daniel Drake wrote: Resyncing the X server was not quite as simple as you might expect. Previously, X was compiled along with the mesa sources to offer software-based GL. The software GL is very slow but word on the street is that some activities use it anyway. ... Anyway, at the moment, we have no swrast in our build, which means no GL support at all. Does anyone care? One thing OpenGL has going for it is portability and availability. There was some wiki mention of interest in one of the embedded subset OpenGL implementations. Did anything ever come from that? The slowness is only relative to modern GPU speed. For a lot of applications, using the 3D framework with the simpler geometries and more image-oriented, a software OpenGL can be quite acceptable. --Chris I am going to work with Fedora to get the swrast module separated from the overweight mesa-dri-drivers - this could return in future if we need it. Sorry for any inconvenience, this was the most straightforward way of getting a working X and a working keyboard again. Daniel ___ 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: joyride keyboard problems GL/glx
On Fri, Jul 25, 2008 at 08:10:21AM -0400, Chris Marshall wrote: For a lot of applications, using the 3D framework with the simpler geometries and more image-oriented, a software OpenGL can be quite acceptable. Forgive the uninformed question, but this would be a requirement for clutter to run on the XO, right? --Chris Martin pgpYQx25BxKzA.pgp Description: PGP signature ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
2008/7/25 Martin Dengler [EMAIL PROTECTED]: On Fri, Jul 25, 2008 at 08:10:21AM -0400, Chris Marshall wrote: For a lot of applications, using the 3D framework with the simpler geometries and more image-oriented, a software OpenGL can be quite acceptable. Forgive the uninformed question, but this would be a requirement for clutter to run on the XO, right? From http://clutter-project.org/: Runs on Linux, Windows and OSX with backend window system support for GLX, EGL, WGL, SDL and Cocoa. We support SDL; that's what all our pygame activities use. I believe we are only specifically talking about GLX support (that's OpenGL directly implemented by the X server) at this time. Since we're doing software rendering in any case, GLX (Mesa in the X server) is not substantially differenent from linking Mesa directly to your application. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
On Thu, Jul 24, 2008 at 9:44 PM, Daniel Drake [EMAIL PROTECTED] wrote: Just a quick FYI: the keyboard bugs in recent joyrides (various buttons not working or misbehaving) is fixed by the X server update in joyride 2207. The problem was that a Fedora 9 update included an updated evdev driver, which had been compiled against a newer X server (we have forked xserver, so we don't automatically get updates there). I have resynced our xserver with Fedora's so we support the new ABI which evdev uses. Resyncing the X server was not quite as simple as you might expect. Previously, X was compiled along with the mesa sources to offer software-based GL. The software GL is very slow but word on the street is that some activities use it anyway. In the newer X server, the software GL implementation (dri_swrast) has been moved to mesa, which we don't include in our builds. The newer X server also includes a bug which caused it to crash when no swrast was present, I wrote a patch included in our build which I will be committing to freedesktop git upstream shortly... Anyway, at the moment, we have no swrast in our build, which means no GL support at all. Does anyone care? I am going to work with Fedora to get the swrast module separated from the overweight mesa-dri-drivers - this could return in future if we need it. Sorry for any inconvenience, this was the most straightforward way of getting a working X and a working keyboard again. Daniel Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the devel-ext3 variant) on qemu (on win XP/SP2) but both fail with the same error: (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) Fatal server error: GLX: could not load software rendered giving up. - Is this something specific for emulation ??? Ton van Overbeek ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
On Fri, Jul 25, 2008 at 10:22 AM, Ton van Overbeek [EMAIL PROTECTED] wrote: Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the devel-ext3 variant) on qemu (on win XP/SP2) but both fail with the same error: (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) Fatal server error: GLX: could not load software rendered giving up. - Is this something specific for emulation ??? Hmm, looks like our xorg.conf for qemu needs some adjustment? Daniel? --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
On Fri, 2008-07-25 at 10:22 -0400, Ton van Overbeek wrote: Just FYI. Tried to boot both joyride-2207 and joyride-2210 (the devel-ext3 variant) on qemu (on win XP/SP2) but both fail with the same error: (EE) AIGLX error: dlopen of /usr/lib/sri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) Fatal server error: GLX: could not load software rendered giving up. - That's really odd, it looks like my patch didn't get applied, or the wrong X server build is creeping in, or something like that. Definitely works for me using freshly reflashed joyride-2210 (jffs2). Can you double check which version you are using? Also see which xserver is there, run rpm -q xorg-x11-server-Xorg Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride keyboard problems GL/glx
Am 24.07.2008 um 21:44 schrieb Daniel Drake: The software GL is very slow but word on the street is that some activities use it anyway. Until very recently we did not even ship libGL so no activity relying on it would even load. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride-weekly builds for testing. (Michael Stone)
Hi All, We could especially use verification of these items: http://dev.laptop.org/query?status=assignedstatus=newstatus=reopenedcol=idcol=summarycol=statuscol=ownercol=typecol=milestonenext_action=qa+signofforder=priority The developers have marked those as ready for QA sign off so any testing on them is appreciated. I could also use documentation or usage notes on them, especially the two marked as enhancements. You can edit comments on how to use these right in to the release notes: http://wiki.laptop.org/go/Release_Notes/8.2.0 or e-mail them to me and I'll make the edits. Thanks, Greg S -- Message: 8 Date: Wed, 23 Jul 2008 16:01:01 -0400 From: Michael Stone [EMAIL PROTECTED] Subject: joyride-weekly builds for testing. To: devel@lists.laptop.org, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii; format=flowed As part of our gradual stabilization program, each week, we're going to nominate the newest non-disqualified Tinderbox-approved joyride build available as of 9:00 AM EDT on Wednesday as the joyride-weekly test candidate for people who are unable to contribute test results against joyride-latest. Please do everything in your power to ensure that builds at risk of being nominated are worthy of these testers' consideration. Or else. :) Finally, this week's joyride-weekly build is joyride-2200. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride 2201 blocker
On Wed, 2008-07-23 at 19:20 -0400, Mikus Grinbergs wrote: I do most of my work with CLI from the Terminal. On my XO with Joyride 2201 there is no bash history accessible in Terminal -- hitting up-arrow at the prompt does NOT call up what had been previously entered at the prompt. [bash history is accessible from the text console (alt-ctl-F1).] Please file a ticket, and also let us know which joyride version this did work with (if known). Thanks, Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride 2201 blocker
Just added a ticket for this myself: http://dev.laptop.org/ticket/7617 Seems to affect quite a number of keys – at least on my XO B4 with Spanish overlay (worked fine in 2174). I'd previously added ticket (Journal search and frame key have no effect): http://dev.laptop.org/ticket/7616 But am now assuming some keyboard mapping has gone wonky in the latest Joyrides (it's been about a week since Joyride was available to the non-hardcore dev so 2174 was last I could install). --Gary On 24 Jul 2008, at 01:28, Daniel Drake wrote: On Wed, 2008-07-23 at 19:20 -0400, Mikus Grinbergs wrote: I do most of my work with CLI from the Terminal. On my XO with Joyride 2201 there is no bash history accessible in Terminal -- hitting up-arrow at the prompt does NOT call up what had been previously entered at the prompt. [bash history is accessible from the text console (alt-ctl-F1).] Please file a ticket, and also let us know which joyride version this did work with (if known). Thanks, Daniel ___ 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: Joyride 2201 blocker
I get the same result on Joyride 2202 (manually upgraded to 2203). What is happening is that in Terminal on my XO certain keypresses (e.g., up-arrow, right-arrow, end) are not being recognized. mikus ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride and microphone
Robert Myers wrote: Is this a software issue or did my mic die? Things were working before I upgraded to Joyride. Anything I can do to check? You stated that it work in the ofw selftest so your hardware appears good. If this is a software issue are there libraries or versions I need to change? Run alsamixer from the command like and take a look at what the various settings are. Make sure the mic is unmuted and that the record levels are set properly and the v_refout is enabled (unmuted) and DC Mode disabled. When using alsamixer make sure you switch to the capture settings with the tab key to see the mic record level. In playback the mic control is not the microphone record control its the analog mixer control which is the level of mic input thats routed back the the speaker output. Muted and zero is the proper setting for that control. -- Richard Smith [EMAIL PROTECTED] One Laptop Per Child ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:24 AM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project Agreed on all of the above. And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC This is one of those steps that makes sense politically, but doesn't really pan out so well in practice. We really *do* need to have maintainability of a subset of activities. It's unfortunately that defining the set we want to 'own' gets people so flustered, but I still think we may find we need to make some form of commitment in this regard. 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time Yup. and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. I think we need to find a way to make solid, secure updates without wiping the machines clean each year; otherwise we're contradicting our goals for learning, as I see it. At the very least, end of year sounds like a good time to backup and organize all student data from the year somewhere (XS?). - Eben ___ 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: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hi All, Responding to all in one pass. From Scott - The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. GS - Sounds good but it still requires all activity developers to update their activities which I think is the central problem. Also, we still need to warn users in advance, especially if they upgrade via USB. Definitely will help so let's do it if its not too much work. From Michael - 2 - Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions GS - How certain are these and is there any documentation of them or what activity changes they will require? We should agree that they are must have items worth requiring activity upgrade before doing them and we should document what it will cost activity developers if we do. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. and related comments GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. GS - I'm asking if we can tell developers here are the things you can do which will be safe. That is, make some kind of promise of backward compatibility for some subset of all functionality. http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html GS - Will read Monday, thanks. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? GS - I thought it was precise :-) and I meant not. I want to know if we can promise that *any* activities will continue to work. I hoped that these Sugar activities are the only ones using some APIs (e.g. collaboration) and therefore the only ones susceptible to breakage. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). Again, please say more about what you're thinking of. GS - I'm saying let's make sure to discuss and agree before making any API changes that might break activities. Tuesday call? GS - Sorry I meant Tuesday software IRC/Gabble meeting. We are on for Tuesday and Wed. again this week at the same times, right? RE: Marco's comments. GS - Thanks! Can you start adding the names of all activities that we know should/will work to the Release notes too? How does someone know what version they have of an activity in Fructose or Glucose? Its helpful to claim backward compatible from Update.1. However, I believe many people will be upgrading from 656 too. Maybe we have to say: upgrade all your activities in that case? ** A few more questions on this: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. - Black box testing of all activities is not feasible unless the authors do it themselves. Can we grep all the activity source code for the functions (or objects or whatever) that have changed and determine which activities might break? I haven't learned much about activity creation and bundling yet so pardon my ignorance if this is a naive question. Until we get a better grip on downstream relationships with activity authors I think the only short term answer is better documentation. Can someone put up a wiki page that explains what has changed and tells activity authors what
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 15:14, Greg Smith [EMAIL PROTECTED] wrote: GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. I've been thinking about having a mailing list specifically for activity authors. Many of them do not need all the info posted to devel@lists.laptop.org or [EMAIL PROTECTED], and may appreciate a specific list with lower noise (to them). The benefit to us would be a greater chance of reaching all activity developers. (Those who speak English, anyhow.) It should probably be on lists.sugarlabs.org, since activities are specific to Sugar. Any comments? - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Uh, no, sorry to burst your bubble. N... (besides, why would you want to run your old version when you get fresh newness every +-6 months? :-) Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, 2008-07-14 at 09:14 -0400, Greg Smith wrote: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Upgrading a distribution is a very broad thing indeed. There are many components and considerations involved. I'm unable to think up any specific examples, but in general I think I disagree with your statement. Software that runs on one version of a distribution will be dependent on components which get upgraded/removed during the distribution upgrade, so in the end that piece of software will end up not working. The way that distributions get around this is by upgrading everything at once. In your example, staying with the old firefox would result in a broken firefox, but the distro upgrade software would make sure that it updates firefox to one compatible with the new distro components. You might not realise that Firefox got upgraded, it might look and feel identical to the old one, but it did. This is possible for distributions because both firefox (the application) and it's dependencies (underlying libraries etc) are all under control of one entity: the package manager. This isn't true in our case, where libraries are controlled by the rpm/yum package manager, but applications (activities) are not. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. If schools agree that this a good idea (it also wipes all the data and provides students with a lot more room); then what I would push for is that saved data can continue to work on upgraded activities -- this is something that the activity developers have to worry about, but it decreases the test effort quite a bit and recommends that schools retest activities between school years. Kim On Mon, Jul 14, 2008 at 9:14 AM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, Responding to all in one pass. From Scott - The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. GS - Sounds good but it still requires all activity developers to update their activities which I think is the central problem. Also, we still need to warn users in advance, especially if they upgrade via USB. Definitely will help so let's do it if its not too much work. From Michael - 2 - Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions GS - How certain are these and is there any documentation of them or what activity changes they will require? We should agree that they are must have items worth requiring activity upgrade before doing them and we should document what it will cost activity developers if we do. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. and related comments GS - Does anyone have the contact info for the developers of all the currently available activities? Can we document the changes they need to make in 8.2.0 and contact them? Let's also ask them what they think about us requiring they rewrite in each release. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. GS - I'm asking if we can tell developers here are the things you can do which will be safe. That is, make some kind of promise of backward compatibility for some subset of all functionality. http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html GS - Will read Monday, thanks. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? GS - I thought it was precise :-) and I meant not. I want to know if we can promise that *any* activities will continue to work. I hoped that these Sugar activities are the only ones using some APIs (e.g. collaboration) and therefore the only ones susceptible to breakage. In the future if
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
2008/7/14 Kim Quirk [EMAIL PROTECTED]: I've been thinking about this problem for the last year -- when it first became obvious (to me) that: 1 - we were definitely NOT going to be able to lock down APIs for at least a year or two 2 - we have no control over the activity developers and the maintainability of any given activity (unless we decide to 'own' it) 3 - all standard 'best practices' for ensure that 'customers' can keep working seamlessly through upgrades have to be dropped for the OLPC project Agreed on all of the above. And the only 'real' solutions I have come up with are: 1 - completely separate the activities from the OS in order to help people understand that most activities are NOT supported or maintained by OLPC; they need to be able to upgrade activities as needed and not wait for new releases from OLPC This is one of those steps that makes sense politically, but doesn't really pan out so well in practice. We really *do* need to have maintainability of a subset of activities. It's unfortunately that defining the set we want to 'own' gets people so flustered, but I still think we may find we need to make some form of commitment in this regard. 2 - push for 'school year' releases (fall and spring); where a school will pick a release and use it for the entire school year so we don't have to worry about upgrades in between that time Yup. and, most recently you will hear me pushing for: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. I think we need to find a way to make solid, secure updates without wiping the machines clean each year; otherwise we're contradicting our goals for learning, as I see it. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 4:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. What if the web interface to the backups in the school server is as good or better than the local journal? Does it change any bit this issue? Sure. I'd love to see a really good backup solution that works seamlessly with the new Journal. In a sense, my point is that this is supposed to happen over time, just as memories fade over time. Perhaps we'll want to distort time a bit at the end of a school year and shove, say, enough of the Journal into backup to free up 1/2 the space on the laptop, but requiring manual restore (and access to the school server) every time a kid wants anything from the previous year sounds a bit frustrating to me, however good the UI is. More importantly, though, this backup solution doesn't solve other issues such as, for instance, my groups, my friends, my settings, and my installed activities. Regardless of what activities the school clean updates/installs, if a kid downloaded This or That, I think that should remain on the machine. We need to make sure, of course, that we a) provide an easy to use update system with notification, in case it's been updated to work with the newer OS b) gracefully handle failure of activities (the current timeout is poor). If the backup has some extra magic that can be used to automatically restore installed activities, friends, groups, setttings, etc., then we're just mixing terminology. That's not a clean install, but an upgrade install which is designed to keep user settings and files intact across the upgrade. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hmmm... I'm not sure that we have to lose all the information just becuase we did a clean install. If the backup of user data can be recovered (especially on a file by file basis). Don't we keep the meta data, so if the user choose to bring those items back into their laptop don't they still have date and time stamps, etc.? Kim On Mon, Jul 14, 2008 at 10:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 4:24 PM, Eben Eliason [EMAIL PROTECTED] wrote: 2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I think this would be a real shame, honestly. It completely tosses out the benefits of the Journal as a structure for ones interactions and created objects. It means I can't incorporate photos that I took over the summer, or last year, into a story I wrote (for instance, even a what I did this summer essay that we've all written at least once). It means I can't go back and look at some math homework I did to refresh myself on how a particular algorithm works. It means I can't create a new etoys project from an experiment I made last year but didn't have time to continue. It means that I lose references to all the friends/groups I've made. It means that my computer is reset to factory state and I have to change my personal preferences all over again. What if the web interface to the backups in the school server is as good or better than the local journal? Does it change any bit this issue? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:02 AM, Kim Quirk [EMAIL PROTECTED] wrote: Hmmm... I'm not sure that we have to lose all the information just becuase we did a clean install. If the backup of user data can be recovered (especially on a file by file basis). Don't we keep the meta data, so if the user choose to bring those items back into their laptop don't they still have date and time stamps, etc.? I feel like my previous message covered most of the points you ask about. 1) As great as the backup system may be (and I hope it is!), it's still unnecessary and suboptimal to require *anything* that was in a child's Journal require a manual backup step to use, and especially so because that requires access to the school server. Consider, for instance, a child at home who needs to look at a document from last year to inform her completion of tonight's homework assignment. Backups should be happening on the order of daily anyway, and entries should fall off over time anyway; the only thing we might want to do with the backup system is drop off a larger portion near the end of the school year (say, 1/2 the capacity) to make room for lots more stuff over the summer and following year. This should still use some heuristics (starred items, frequency of use, recency of use, etc) to determine what should go and what should stay. 2) Like I mentioned, I don't think the current backup solution really handles /installed/ activities, groups, friends, or settings at present. Perhaps we should start thinking about how it could; I'm not sure. All of these things should remain constant across the upgrade. If this is what you feel as well, I have no argument. =) I merely point out that this is NOT a clean install, and we shouldn't refer to it as such. It's a smart upgrade which retains user settings and (at least most) data. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
2008/7/14 Kim Quirk [EMAIL PROTECTED]: 3 - Encourage schools to completely reflash (cleaninstall) their laptops each year. At the end of the school year, you save away kids data (hopefully that is done automatically) and you do a cleaninstall of the next year's image; retest all the latest versions of Activities that you want to use; and provide 'clean' laptops to the kids at the start of the next school year. I also disagree: this is unnecessary and eliminates the benefit of being able to roll back to your previous system if your upgrade broke something -- which you might not find out about until months later, potentially. The other points sound reasonable. I think we need to include a 'contact email' field in the activity.info for each activity (i'm kinda shocked we haven't done so yet) so that we can get in touch with maintainers, and then write a more rigorous guide to testing your release before deployment which helps countries go through the steps necessary to qualify the release + activities before they put it in a school. We need to allow local creation and maintenance of activities: OLPC can't hope to write all the needed activities itself. But at the same time we need to empower the countries to set standards of quality and kick the butts of activity authors if needed to get fixes made. If the activity is written under contract by the MoE, for example, then they should have a process/contract in place for revalidating and potentially patching it each year. (Hopefully improving it, too, not just maintaining it in stasis.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:22 AM, C. Scott Ananian [EMAIL PROTECTED] wrote: The other points sound reasonable. I think we need to include a 'contact email' field in the activity.info for each activity (i'm kinda shocked we haven't done so yet) so that we can get in touch with This is something I brought up recently in another context. I think such a contact email would be really beneficial so, for instance, the Log activity can actually send logs to the people who actually care when that button is pressed. The problem with this design, of course, is that it exposes the email in a place where spammers can easily find it. This is really of concern mostly because we expect kids to create and maintain activities eventually as well. Of course, assuming the kids have an email account at all to provide, there's surely no way to prevent them from being spammed at all...should the field be optional? optional unless under contract? - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:32 AM, Eben Eliason [EMAIL PROTECTED] wrote: when that button is pressed. The problem with this design, of course, is that it exposes the email in a place where spammers can easily find Yes, that is life in the 200x's. Every major package management system has this feature. Deal with it tune your filters. it. This is really of concern mostly because we expect kids to create and maintain activities eventually as well. Of course, assuming the No one's forcing the kids to provide email addresses. We're just strongly suggesting that activities which are maintained by someone (either by OLPC for G1G1 or by countries for their deployments) have working addresses. Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. kids have an email account at all to provide, there's surely no way to prevent them from being spammed at all...should the field be optional? optional unless under contract? It is optional, but its presence should be noted as one of the positive factors when evaluating whether an activity you wish to include in your deployment is high quality. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 6:37 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... Cannot amo (addons.mozilla.org) handle this issue? David Farning is working on it, but it's a big task and could use some help. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 12:37 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 6:32 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: Also, there's nothing saying that this has to be a particular person's email address. It could be a list, or a mailinator account, or pass through an anonymizer or something else. I suppose some activity authors might prefer to provide a link to some web page with the contacts... And I'd strongly prefer that they *not* do so. First off, it's pointless to do so, since the web page is a lot easier to spam-spider than the activity bundle. But fundamentally, I want to be able to use semi-automated tools to email all G1G1 activity authors, and having to trawl through web pages to find where the email addresses have been hidden is not my idea of a good time. The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 3:14 PM, Greg Smith [EMAIL PROTECTED] wrote: RE: Marco's comments. GS - Thanks! Can you start adding the names of all activities that we know should/will work to the Release notes too? I can add the Fructose ones, where are the release notes? :) How does someone know what version they have of an activity in Fructose or Glucose? By looking at the Sucrose release notes. (This is not the case for the release notes we made so far, because they only include the changed modules, I'll make sure it's the case for the next release). Its helpful to claim backward compatible from Update.1. However, I believe many people will be upgrading from 656 too. Maybe we have to say: upgrade all your activities in that case? Yeah, I don't think there is a way around that. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:49 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: And I'd strongly prefer that they *not* do so. First off, it's pointless to do so, since the web page is a lot easier to spam-spider than the activity bundle. But fundamentally, I want to be able to use semi-automated tools to email all G1G1 activity authors, and having to trawl through web pages to find where the email addresses have been hidden is not my idea of a good time. Different projects has different channels of communication, depending on the reason you are contacting them and the maintainer personal tastes. As an activity author I would not be comfortable about being contacted through semi-automated tools about bugs in my activity for example. Maybe it's just me... The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. It doesn't allow you to report bugs semi-automatically. But it certainly allows you to find out manually the bug tracker the project uses. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 5:24 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 10:49 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The activities database at http://wiki.laptop.org/go/Activities already has a 'source url' field for the web page. What is needed is a means to (a) contact the maintainers, and (b) report bugs. A webpage URL does neither of these things. It doesn't allow you to report bugs semi-automatically. But it certainly allows you to find out manually the bug tracker the project uses. What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. They could be made available on a web site instead, or we could aim at integrating log with trac. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. They could be made available on a web site instead, or we could aim at integrating log with trac. GNOME, for example, has bug-buddy which reports crashes to bugzilla. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 5:39 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: They could be made available on a web site instead, or we could aim at integrating log with trac. GNOME, for example, has bug-buddy which reports crashes to bugzilla. The goal from the beginning has been to minimize cost-of-entry to develop applications for our platform. Requiring that people set up bugzilla in order to receive bug reports is a high bar! Requiring that they have an email address is not. By all means let's make our emails integrate nicely with bug reporting systems -- all sane bug trackers have an email gateway. But let's not turn the horse tail first by forcing all our activity authors to implement the same or similar bug trackers. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:36 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 5:35 PM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 14, 2008 at 11:30 PM, Eben Eliason [EMAIL PROTECTED] wrote: What an email does do is allow, for instance, the Log activity to actually be useful in practice, since the send log button can send the log to the people who might actually look at it and make any necessary changes to their code. Again, I would personally *hate* to receive these logs on my mail address or on the main mailing list of my project. THEN SET UP A DIFFERENT MAILING LIST! or write a mail filter. or designate another person to monitor the mailing list. Or use mailinator and check it via RSS on some schedule. A mailing list for random communications about my activity? No, thanks. I will simply not specify an email adress in the activity.info and ask people to report tickets through the project bug tracker. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 11:42 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: The goal from the beginning has been to minimize cost-of-entry to develop applications for our platform. Requiring that people set up bugzilla in order to receive bug reports is a high bar! Requiring that they have an email address is not. Not really if we provide something like track-hacks.org. By all means let's make our emails integrate nicely with bug reporting systems -- all sane bug trackers have an email gateway. But let's not turn the horse tail first by forcing all our activity authors to implement the same or similar bug trackers. I never said we should *not* support email. I said we should *also* support different communication means. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote: On Mon, 2008-07-14 at 09:14 -0400, Greg Smith wrote: - Leaving aside how its done technically, I believe that Linux distributions are fully backward compatible. That is, you can go to the latest supported Distribution and leave your Firefox (or any application) on its older release and it will still work fine. Let me know if that is not correct. I think that is what we need to strive for, eventually. Upgrading a distribution is a very broad thing indeed. There are many components and considerations involved. I'm unable to think up any specific examples, but in general I think I disagree with your statement. Software that runs on one version of a distribution will be dependent on components which get upgraded/removed during the distribution upgrade, so in the end that piece of software will end up not working. I disagree as well. Applications are fundamentally embedded within the system in which they run. This is particularly true within in the free / open source software environment in which our work is grounded. In such distributions, a specific version of a given application typically relies upon version ranges of various software libraries. These libraries encode systems which are required by the application but which are general enough that they may be used by multiple applications for different ends. Sharing code in this manner yields savings in terms of developer time and disk space, but it introduces a complex software dependency management problem. In practice, the complex interdependencies which arise due to this pattern of code sharing have encouraged the development of applications (the package managers) which automatically manage system upgrade and software installation by resolving dependencies between software packages. And in turn, the use of these systems has encouraged the process of code sharing by making commonly shared software libraries more accessible to developers. As Daniel notes, the package manager is the core software management entity in a typical distribution: On Mon, Jul 14, 2008 at 10:05:46AM -0400, Daniel Drake wrote: This is possible for distributions because both firefox (the application) and it's dependencies (underlying libraries etc) are all under control of one entity: the package manager. This isn't true in our case, where libraries are controlled by the rpm/yum package manager, but applications (activities) are not. ... Yet the barrier we have established between system and application prevents our utilization of such a system for software distribution management. We have attempted to structure our system such that applications are independent from the underlying operating system. We desire this distinction because it purportedly allows us to modularize user-level software systems into discreet non-interacting bundles, yielding benefits for system security and software distribution. In return for these benefits we must manage an optimization problem whose solubility decreases in step with the number of potentially useful activities developed for the XO. We must decide which libraries should be pulled from application-bundle into the system, and which should be pushed out of the system and into applications. Additionally, we must implement our own schemes to inform users of application / system compatibilities. (Note the concurrent thread on Activity versioning on the devel list.) We further isolate ourselves from our upstream distributions by requiring that every application be ported to our software distribution schema. We incur costs in creating our own custom solution to the problem of package management which handles software on one side of the application / system barrier. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Sat, Jul 12, 2008 at 12:56 AM, Greg Smith [EMAIL PROTECTED] wrote: I understand that we do not have backward compatibility in 8.2.0 as it currently stands. For Glucose we are supposed to be backward compatible with Update.1. ABI breaks should be reported as bugs. Can we bound the test problem by saying that all well behaved activities will continue to work? If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. We will work on ABI policy an document it, we will hopefully find time to introduce more automated testing. But at the speed of change of both Glucose and the distribution, I think it's impossible to say for sure if an activity will work without testing it. Bugs happens. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Do you really mean not there? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). For Glucose that's already the case for Update-1 - 8.2.0. If something broke it's a bug. We don't have control on most of the distribution modules though, so I guess we will have to accept occasional breaks like the gtksourceview one. Marco ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Fri, Jul 11, 2008 at 06:56:35PM -0400, Greg Smith wrote: We should definitely have backward compatibility for activities! Your desire to maintain backwards compatibility for activities is a worthy goal but you need to be aware that there remain several areas in which we will likely break compatibility in order to carry on further development, both at the system and activity levels. Off the top of my head: Activity toolbars Bitfrost protections Power-management work Datastore APIs Collaboration APIs APIs which hamstring our software on other distributions In each of these cases, we may have the ability to gradually deprecate old APIs by installing compatibility layers which implement them on top of new primitives. However, we will be well advised to carefully weigh the cost of maintaining these compatibility layers versus organizing the labor, as a community, necessary to port all the activities we can find to the new APIs. Michael A blow-by-blow: That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. In my opinion, we will simply have to include the cost of updating activities in our estimates of the cost required to deliver features which require API changes. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. As above - it is our responsibility, when making breaking changes, to help carry our downstream partners along with us. It is also our responsibility to make breaking changes whenever doing so will improve the overall capability of children working with our software to learn. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. We mainly have bugs in 8.2.0. When we fix the bugs, we expect that we will have 'pretty good' compatibility at the API level. Obviously, there will be less compatibility at the UI level. Can we bound the test problem by saying that all well behaved activities will continue to work? Not really. What we _can_ do is to keep really good records of what activities are around and to invest in automated test facilities like tinderbox and sugarbot which might permit us to measure our compatibility status at an affordable cost. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. As hinted above, I do not believe that we can spare activities from API breakage. At best we can somewhat increase the amount of time in which it is possible run software based on deprecated assumptions. Any other suggestions on how to bound this test challenge appreciated! Titus Brown has written some persuasive arguments at http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html that I commend to your attention. e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Your statement is too ambiguous to safely promise. Can you be more precise about what you actually want to promise? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). Again, please say more about what you're thinking of. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. It's not prima facie much better to ensure compatibility AT THE COST of leaving critical features unimplemented. As with all things, we'll need to discuss it on a case-by-case basis. Let's talk more about this on the Tuesday call. Tuesday call? ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
The general solution to this problem is trac #4951, the activity updater, which I've landed recently. Trac #7495 says that the first boot after an upgrade should open the activity updater, so that a version of the activity compatible with the new OS can be installed if necessary. The activity update protocol understands simple base OS dependencies, so that you can specify a different version for 8.1 and 8.2 (for example). The [[Activity_bundles]] wiki page documents the update_url tag. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On Sat, Jul 12, 2008 at 00:56, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, We should definitely have backward compatibility for activities! In my opinion, there should be compatibility from one release to the next. APIs should not break from release to release unless critically necessary. If there is a new way of doing things which is better, the old way should still work - but it should warn in the log files that a deprecated API is being used. We should announce API deprecations - and API breaks where necessary - in advance of a new release (as well as release notes) so that activity authors are well aware of what is happening. This is done for Python releases, for example, giving people details on how to update python code from one version to another. Indefinite support of backwards compatibility certainly has been a major cause of platforms deteriorating (I'm thinking of Windows here). That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. 65x releases did not have Rainbow running, so activities could access and write to places on the filesystem which are no longer possible. For that reason we can only really focus on activities which already run on Rainbow. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. My understanding is that we made no particular guarantees, and while we did not intentionally break APIs, some things may have broken along the way. I think our development process should include some sort of compatibility management - perhaps as I mentioned above with API support between two consecutive releases - and this could be enforced or monitored with some sort of test activity (or test suite) that uses the various Sugar APIs and reports on failures. Can we bound the test problem by saying that all well behaved activities will continue to work? Unfortunately I think our APIs are insufficiently documented (or have been) so that even core activities are not guaranteed to be well behaved. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. I think a better criteria would be responsive activity authors who make some kind of commitment to keep their activities up to date from release to release. I don't think we should spend resources testing arbitrary third party activities, but where we can maintain a responsive developer community we can include them in the process. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Not all activities were updated in Sucrose release 0.81.4 - some were updated in previous Sucrose releases. The activities listed in http://wiki.sugarlabs.org/go/Modules are ones where the maintainers have agreed to use the Sucrose release cycle (and other conditions listed in http://wiki.sugarlabs.org/go/ReleaseTeam#New_activities). These are activities which the Sugar project lists as demo activities, and may or may not coincide with OLPC's deployed activities (in the long term, as other users of Sugar emerge) - but they are certainly candidates for OLPC's use. Thus I would say that activities *not* on that list are the ones that are *not* guaranteed to work with 8.2.0, because the authors did not step up and take an interest in the new release. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). API breaks should be discussed during a development cycle as the need for them emerges, hopefully as early as possible in the cycle so there are no surprises. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. On the other hand, newer activities can require a newer OS. That can be handled if we have good activity documentation on the download and activity pages. Yes. You've been talking about running old activities on a new release - I would include new versions of activities here which may require a newer OS/release. Perhaps we should change the activity service name (e.g. org.laptop.Chat) when an activity is updated in such a way that it can no longer run on old releases. Perhaps that should also be done when a newer version of an activity can no longer collaborate with an older version. Sounds like we have a big activity test challenge ahead for 8.2.0... BTW is this the full list of all known
Re: Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
On 7/12/08, Morgan Collett [EMAIL PROTECTED] wrote: On Sat, Jul 12, 2008 at 00:56, Greg Smith [EMAIL PROTECTED] wrote: Hi Guys, We should definitely have backward compatibility for activities! In my opinion, there should be compatibility from one release to the next. APIs should not break from release to release unless critically necessary. If there is a new way of doing things which is better, the old way should still work - but it should warn in the log files that a deprecated API is being used. Problems arise independently of API when libraries not part of the base system are used. For example, I have an activity that uses goocanvas and the glibmm libaries, which I package in the activity bundle. I tried first using glibmm from F9, but it didn't work on F7-based builds. I then substituted glibmm from F7, and it works on 656, 703/8, and all the recent joyrides. I don't know the best way to handle this generally, I suppose it is up to individual activity owners to make sure their stuff works all over. bobby We should announce API deprecations - and API breaks where necessary - in advance of a new release (as well as release notes) so that activity authors are well aware of what is happening. This is done for Python releases, for example, giving people details on how to update python code from one version to another. Indefinite support of backwards compatibility certainly has been a major cause of platforms deteriorating (I'm thinking of Windows here). That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. 65x releases did not have Rainbow running, so activities could access and write to places on the filesystem which are no longer possible. For that reason we can only really focus on activities which already run on Rainbow. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. My understanding is that we made no particular guarantees, and while we did not intentionally break APIs, some things may have broken along the way. I think our development process should include some sort of compatibility management - perhaps as I mentioned above with API support between two consecutive releases - and this could be enforced or monitored with some sort of test activity (or test suite) that uses the various Sugar APIs and reports on failures. Can we bound the test problem by saying that all well behaved activities will continue to work? Unfortunately I think our APIs are insufficiently documented (or have been) so that even core activities are not guaranteed to be well behaved. If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. I think a better criteria would be responsive activity authors who make some kind of commitment to keep their activities up to date from release to release. I don't think we should spend resources testing arbitrary third party activities, but where we can maintain a responsive developer community we can include them in the process. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? Not all activities were updated in Sucrose release 0.81.4 - some were updated in previous Sucrose releases. The activities listed in http://wiki.sugarlabs.org/go/Modules are ones where the maintainers have agreed to use the Sucrose release cycle (and other conditions listed in http://wiki.sugarlabs.org/go/ReleaseTeam#New_activities). These are activities which the Sugar project lists as demo activities, and may or may not coincide with OLPC's deployed activities (in the long term, as other users of Sugar emerge) - but they are certainly candidates for OLPC's use. Thus I would say that activities *not* on that list are the ones that are *not* guaranteed to work with 8.2.0, because the authors did not step up and take an interest in the new release. In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). API breaks should be discussed during a development cycle as the need for them emerges, hopefully as early as possible in the cycle so there are no surprises. In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking
Activity Backward Compatibility (was re: Re: joyride 2128 smoketest)
Hi Guys, We should definitely have backward compatibility for activities! That is, activities that used to work (maybe starting at 656) must continue to work. If a new release requires that all activity authors have to recode some of their work, that will be a major deterrent to working with us. Its also a deterrent to deployments upgrading, assuming they find out their activities are broken before they upgrade. I understand that we do not have backward compatibility in 8.2.0 as it currently stands. Can we bound the test problem by saying that all well behaved activities will continue to work? If we can define well behaved and not test activities that meet that criteria it will save us a lot of test time. Any other suggestions on how to bound this test challenge appreciated! e.g. can we say that all activities not listed on this page: http://wiki.sugarlabs.org/go/ReleaseTeam/Releases/Sucrose/0.81.4 will work the same in 8.2.0 as they did in previous releases? In the future if some piece of core code will cause previously supported activities to no longer work, I hope we can discuss and accept or reject that in advance (sorry if I missed that debate on this round). In the worst case we have to test as many activities as possible but its much better to ensure API changes are not breaking things from the OS level. On the other hand, newer activities can require a newer OS. That can be handled if we have good activity documentation on the download and activity pages. Sounds like we have a big activity test challenge ahead for 8.2.0... BTW is this the full list of all known activities? http://wiki.laptop.org/go/Activities Let's talk more about this on the Tuesday call. Thanks, Greg S Chris Ball wrote: Hi, On Wed, 2008-07-09 at 21:06 +0200, Morgan Collett wrote: My 2c worth here... There haven't been API breaks for activities. I've had to do nothing to my activities to keep them working from 8.1.0 to joyride current. Some external things have bitten us though. gtksourceview API change prevents Pippy-20 from launching (that's the version installed by Bert's script, even today) http://dev.laptop.org/ticket/3488 And an Sugar API change caused Pippy to stop being able to build activities: http://dev.laptop.org/ticket/7205 - Chris. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
On Wed, Jul 09, 2008 at 02:29:17PM -0400, Kim Quirk wrote: With almost 400,000 deployed in the world, we need to have some good discussions on the backward compatibilty and upgradability of Activities. Some of the bugs Charlie is writing up from the QA first look at joyride may be answered by upgrading an activity to a newer one. So here are the questions we need to discuss: 1 - Is there anyway to ensure backward compatibility of activities (the 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. 2 - For support purposes, do we need or want to say that activities will be backward compatible only across the year designator (8.1 activities will work with 8.2; but from 8.x to 9.x, the activities will need to be updated and probably retested and checked for new translations). 3 - Since I think it is going to be really hard to do either 1 or 2 above, then we have to have a strategy for easy activity upgrades. We've talked about this for a long time... do we have a proposal that we can really implement as part of the 8.2 release? Problem: We release a new activity that works on our development stream, but how does a user know if it is supported on their system? How do they know to download it? What if it has system dependencies which are unmet on the user's existing system? Commonly utilized solution (at least in the Linux world): Use a package manager to manage such details for the user. For each packaged version of an activity, record which versions of other system libraries and applications it requires and where to download it. When the user attempts to install a package, check that its dependencies are met in the existing system. If they are not, ask the user if they wish to make the required upgrades and inform them of the consequences (in terms of memory usage and other software breakage). Such a system could also be used to deliver security updates and manage incremental system upgrades. (For all discussion of security I've seen on the devel list, the distribution of security-related software updates is not something I have noticed. How are we planning on doing this outside of olpc-update?) The problem of software deployment which you note in #3 is _exactly_ the kind of problem that package management system could be used to solve. We already ship one on the laptop (yum)! Perhaps we could be using it to handle our activity updates? If the problem is that yum is slow and awful, then maybe we need to start thinking about using apt. In the long run I have trouble imagining how this problem will be solved without roughly approximating the behavior of apt or rpm package management systems. I suggest we start exploring methods to install and upgrade activities using such systems. I do not know if this is something we can manage for the 8.2 release, but I would be more than willing to start working on it as soon as necessary. Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
On Wed, 2008-07-09 at 21:06 +0200, Morgan Collett wrote: 2008/7/9 Kim Quirk [EMAIL PROTECTED]: 1 - Is there anyway to ensure backward compatibility of activities (the 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. My 2c worth here... There haven't been API breaks for activities. I've had to do nothing to my activities to keep them working from 8.1.0 to joyride current. I have started documenting v8.2.0 activity incompatibilities here: http://wiki.laptop.org/go/Release_Notes/8.2.0#Activity_Incompatibilities Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
On Thu, Jul 10, 2008 at 10:53:20AM -0400, Michael Stone wrote: We already ship one on the laptop (yum)! Perhaps we could be using it to handle our activity updates? If the problem is that yum is slow and awful, then maybe we need to start thinking about using apt. Here are several problems you might think about: 1) We'd like people to be able to package activities on a wide variety of systems including on Windows. To the best of my knowledge, it currently requires nontrivial Unix expertise to produce most Unix packaging formats. I suggest we assist in .xo - .rpm / .deb and obtain the benefits of a package manager on whatever fraction of the XOs run linux. If we retain .xo files and an installer for Windows, then we are doing as well as we can be expected to on Windows. At present are we even sure that Activities are going to run on Windows? Activity maintainers will have to port them. 2) We'd like people to be able to install activities with relatively low privilege -- in particular, without root privilege. Linux packaging formats and guidelines often assume that the person installing packages has access to root authority (or is able to do something comparable like chroot + fakeroot). What can we do about this? For example: By default XO users have access to root privelages (Terminal + su). Why is it not acceptable for them to have access in the context of activity installation and upgrade? * RPM supports relocation and (for some packages) installation as an unprivileged user. However, privilege is needed in order to update the system rpm database. Perhaps we could teach RPM how to maintain two databases; one privileged and one not? The typical use case for such an arrangement is a multi-user system in which users would like to install custom software without disturbing the system at large. In the case of the XO there are no other users. The actions of the principal user affect only that user. * Alternately, we could imagine running activities in a copy-on-write (CoW) filesystem (union-mounted, FUSE, vserver, ...) with either a false sense of privilege (fakeroot) or a restricted form of real privilege (vserver, selinux, ...). Then we could install packages for activities which need them with relatively little hassle. - How could we share disk usage costs between such activities? - Could we ever update the packages inside these containers? This would be very messy. I conclude from your comments that our current security model discourages the use of existing package-based Linux software distribution systems. I find it interesting that these same systems are crucial components in generic 'soft' Linux security models. I suggest that, if we can adjust our security model to accept it, a package system could be used for both software installation and updates and the resolution of security concerns via security-oriented updates. How are we planning on providing security updates? Do you agree that a package manager-based solution is tenable? -Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
On Thu, Jul 10, 2008 at 2:15 AM, Erik Garrison [EMAIL PROTECTED] wrote: Commonly utilized solution (at least in the Linux world): Use a package manager to manage such details for the user. For each packaged version of an activity, record which versions of other system libraries and applications it requires and where to download it. When the user attempts to install a package, check that its dependencies are met in the existing system. If they are not, ask the user if they wish to make the required upgrades and inform them of the consequences (in terms of memory usage and other software breakage). Such a system could also be used to deliver security updates and manage incremental system upgrades. (For all discussion of security I've seen on the devel list, the distribution of security-related software updates is not something I have noticed. How are we planning on doing this outside of olpc-update?) I'm personally less concerned with the particulars of security updates, but would say only that I'd prefer them to be pushed to the machines automatically if desired, or at least made a one-click update otherwise, ideally with some form of notification that an update is available. For that matter, olpc-update should ultimately be replaced by a similar push/notification scheme, with a simple button press (likely in the about this XO section of the control panel) to update. We could even extend this section when a dev key is detected, to make installing cutting edge builds simple as well. We might also want to provide a link to the release notes in the same place. The problem of software deployment which you note in #3 is _exactly_ the kind of problem that package management system could be used to solve. We already ship one on the laptop (yum)! Perhaps we could be using it to handle our activity updates? If the problem is that yum is slow and awful, then maybe we need to start thinking about using apt. In the long run I have trouble imagining how this problem will be solved without roughly approximating the behavior of apt or rpm package management systems. I suggest we start exploring methods to install and upgrade activities using such systems. I do not know if this is something we can manage for the 8.2 release, but I would be more than willing to start working on it as soon as necessary. So, there are two reasons that I'm /really/ hesitant to jump into the average packaging model. 1. Activity bundles, to the extent possible, are designed to be as self-contained as possible. This is a trade-off, as obviously required components that aren't on the system take up extra space in the bundle, and may even be duplicated. Early on we decided this was an acceptable cost to support non- or intermittently-connected circumstances, and to make possible ubiquitous peer to peer bundle-sharing over the network. 2. We highly dislike the idea of presenting kids with installation procedures of any kind. For that matter, it's almost a shame that we even have to do the technical step of unzipping the bundles to officially install them, unlike, for instance, .app bundles on OSX which run from anywhere, and are installed inasmuch as they reside /somewhere/ (even external devices). I'd really like to see us find a way to make our bundles run in place, so that kids can run large or infrequently used activities off of USB sticks, for instance. But, back to the point, the only thing a kid should have to decide when installing an activity is that they actually want to do so. It seems that the only dependency info that does make sense is which packages are required in the core build (can we somehow wrap API versions into this equation as well?) for it to run. That is, either everything that this activity expects to have in Sugar itself is present, or it's not, and we can then make basic recommendations on what activities are compatible with what releases of Sugar based on that. - Eben ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
On Thu, Jul 10, 2008 at 02:35:23PM -0400, Erik Garrison wrote: On Thu, Jul 10, 2008 at 10:53:20AM -0400, Michael Stone wrote: Here are several problems you might think about: 1) We'd like people to be able to package activities on a wide variety of systems including on Windows. To the best of my knowledge, it currently requires nontrivial Unix expertise to produce most Unix packaging formats. I suggest we assist in .xo - .rpm / .deb and obtain the benefits of a package manager on whatever fraction of the XOs run linux. If we retain .xo files and an installer for Windows, then we are doing as well as we can be expected to on Windows. At present are we even sure that Activities are going to run on Windows? Activity maintainers will have to port them. You misunderstand. A design goal of the .xo[l] format is for casual developers whose primary platform is not Unix to be able to contribute content to the XO. While there are certainly work-arounds that could be built, for example a web-based builder or a really portable packaging tool, it's presently challenging to build packages in the common formats absent far more Unix know-how than is necessary to write activities. 2) We'd like people to be able to install activities with relatively low privilege -- in particular, without root privilege. Linux packaging formats and guidelines often assume that the person installing packages has access to root authority (or is able to do something comparable like chroot + fakeroot). What can we do about this? For example: By default XO users have access to root privelages (Terminal + su). Why is it not acceptable for them to have access in the context of activity installation and upgrade? XO users in some of our large deployments do not have access to root privileges at all (save via developer key or privilege escalation attack). * RPM supports relocation and (for some packages) installation as an unprivileged user. However, privilege is needed in order to update the system rpm database. Perhaps we could teach RPM how to maintain two databases; one privileged and one not? The typical use case for such an arrangement is a multi-user system in which users would like to install custom software without disturbing the system at large. In the case of the XO there are no other users. The actions of the principal user affect only that user. You're not considering changes that country deployment teams make to the XO which they expect will not be modified by end users of the XO (who do not take active steps to control their system, e.g. by requesting a developer key). * Alternately, we could imagine running activities in a copy-on-write (CoW) filesystem (union-mounted, FUSE, vserver, ...) with either a false sense of privilege (fakeroot) or a restricted form of real privilege (vserver, selinux, ...). Then we could install packages for activities which need them with relatively little hassle. - How could we share disk usage costs between such activities? - Could we ever update the packages inside these containers? This would be very messy. Maybe yes, maybe no. It works quite well for building software (e.g. pbuilder and mock) and for hosting servers (vserver). I conclude from your comments that our current security model discourages the use of existing package-based Linux software distribution systems. I find it interesting that these same systems are crucial components in generic 'soft' Linux security models. How familiar are you with Bitfrost? I suggest that, if we can adjust our security model to accept it, a package system could be used for both software installation and updates and the resolution of security concerns via security-oriented updates. Which aspect of our security model would you suggest altering? How are we planning on providing security updates? When connectivity is available, via olpc-update (which is quite bandwidth-efficient) and via our regular software releases to country deployments otherwise. Do you agree that a package manager-based solution is tenable? I believe that an acceptable package management system could be built but I'm not aware of one that presently exists which satisfies our other requirements. Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
With almost 400,000 deployed in the world, we need to have some good discussions on the backward compatibilty and upgradability of Activities. Some of the bugs Charlie is writing up from the QA first look at joyride may be answered by upgrading an activity to a newer one. So here are the questions we need to discuss: 1 - Is there anyway to ensure backward compatibility of activities (the 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. 2 - For support purposes, do we need or want to say that activities will be backward compatible only across the year designator (8.1 activities will work with 8.2; but from 8.x to 9.x, the activities will need to be updated and probably retested and checked for new translations). 3 - Since I think it is going to be really hard to do either 1 or 2 above, then we have to have a strategy for easy activity upgrades. We've talked about this for a long time... do we have a proposal that we can really implement as part of the 8.2 release? Kim On Wed, Jul 9, 2008 at 11:25 AM, Murphy, Charles [EMAIL PROTECTED] wrote: I've been running a smoketest on the recent joyride-2128 build, and have just posted the results of what i've done so far at http://wiki.laptop.org/go/Test_Group_Release_Notes#Joyride_Builds . Here's a short summary of some of the more glaring issues: - The two XOs tested could not see each other on either simple mesh or on an AP with a schoolserver (both laptops are registered to the schoolserver in question, schoolserver.media.mit.edu). - Browse could not download .xo or .xol files. - Clipboard could not paste into Write. - Record has problems saving and playing back photos and videos. I'm not finished with the smoketest yet, but these issues seem bad enough to merit posting to devel and the wiki right away. I'll continue posting results to the wiki as they come in. Charles Murphy WPI Class of 2010, IMGD-Tech [EMAIL PROTECTED] Cell: (781)710-6950 ___ 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: joyride 2128 smoketest
On Wed, 2008-07-09 at 21:06 +0200, Morgan Collett wrote: My 2c worth here... There haven't been API breaks for activities. I've had to do nothing to my activities to keep them working from 8.1.0 to joyride current. Some external things have bitten us though. gtksourceview API change prevents Pippy-20 from launching (that's the version installed by Bert's script, even today) http://dev.laptop.org/ticket/3488 I don't think there's any way to protect against this, since activity writers were not predicting the future when they wrote their code. So in answer to Kim's question: 1 - Is there anyway to ensure backward compatibility of activities (the 8.1.1 activities will work with 8.2)? -- seems like a long shot to me. No. But hopefully there is not very much breakage. Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride 2128 smoketest
Hi, On Wed, 2008-07-09 at 21:06 +0200, Morgan Collett wrote: My 2c worth here... There haven't been API breaks for activities. I've had to do nothing to my activities to keep them working from 8.1.0 to joyride current. Some external things have bitten us though. gtksourceview API change prevents Pippy-20 from launching (that's the version installed by Bert's script, even today) http://dev.laptop.org/ticket/3488 And an Sugar API change caused Pippy to stop being able to build activities: http://dev.laptop.org/ticket/7205 - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride builds
On Sunday 29 June 2008, Tomeu Vizoso wrote: Hi, from joyride 2083, we don't get announcements, and 2084 is the last build offering images and that can be updated with olpc-update. Anybody knows what's going on? somebody removed 2085 and 2086 I restarted the announcer even though it seemed to be running ok. -- Dennis Gilmore signature.asc Description: This is a digitally signed message part. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride builds
Am 29.06.2008 um 11:58 schrieb Tomeu Vizoso: Hi, from joyride 2083, we don't get announcements, and 2084 is the last build offering images and that can be updated with olpc-update. Anybody knows what's going on? No, but I found out ;) The streams where moved from http://xs-dev.laptop.org/~cscott/olpc/streams to http://xs-dev.laptop.org/~cscott/xo-1/streams and curl does not follow the 301 Moved Permanently redirect. I now adapted my script to wget and changed to the new URL, so the list diff page works again: http://dev.laptop.org/~bert/joyride-pkgs.html Also, I removed the old update.1-joyride diff and replaced it by this currently useful one: http://dev.laptop.org/~bert/olpc3-joyride.html But the email announcer is nowadays operated by Reinier, don't know if his script needs changes too. - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride builds
On Sun, Jun 29, 2008 at 1:18 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 29.06.2008 um 11:58 schrieb Tomeu Vizoso: Hi, from joyride 2083, we don't get announcements, and 2084 is the last build offering images and that can be updated with olpc-update. Anybody knows what's going on? Yes, joyride-2085 and joyride-2086 failed to build, because I botched a filename in a pilgrim patch for trac #3569. The streams where moved from http://xs-dev.laptop.org/~cscott/olpc/streams to http://xs-dev.laptop.org/~cscott/xo-1/streams and curl does not follow the 301 Moved Permanently redirect. Incidentally, the streams moved on Fri Dec 21 14:15:06 2007 -0500 according to pilgrim's git log, but I'd kept a symlink around with the old name for convenience. I recently replaced the symlink with an apache redirect, which apparently upset curl. Sorry. Also, I removed the old update.1-joyride diff and replaced it by this currently useful one: http://dev.laptop.org/~bert/olpc3-joyride.html Actually, the update.1 is the currently useful diff, as explained in my earlier email. olpc3 was a throwaway branch, which is now thrown away. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride-2009 from 1949 (No standard activities)
I too just upgraded to Joyride-2009 last night. I jumped from joyright 1949 to joywrong 2009 (about a 4 week difference)... Had 'standard' G1G1 activities, now it's only the ones which I've custom installed. So. it looks like joyride is going the route of Update.1 ? Shipping with no activities ? -iXo On Wed, Jun 4, 2008 at 7:14 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:07 PM, Marcus Leech [EMAIL PROTECTED] wrote: Michael Stone wrote: Dov, First, please file a ticket that sugar fails to start up if /home/olpc is empty/missing. Please CC at least mstone and marco on it. Next, put your /home back in place and try to start Sugar. If you're successful, then go to the list view and click some of the stars so that they become filled with color. Then return to the ring view. Your activities should be present. File bugs if they aren't. Finally, which activities were you expecting to see in the ring view when you updated to joyride-2005? Thanks, Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel On a related note, I upgraded from Ship.2 656 to joyride-2002 yesterday on some of my lab machines, and ain't no activities at all. I ran into this a few weeks ago with my own personal XO, and I can't remember the solution (which, I think, involved downloading and installing an RPM). http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes shows ways of installing the activities. ___ 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: Joyride-2009 from 1949 (No standard activities)
On Wed, Jun 4, 2008 at 4:38 PM, Ixo X oxI [EMAIL PROTECTED] wrote: I too just upgraded to Joyride-2009 last night. I jumped from joyright 1949 to joywrong 2009 (about a 4 week difference)... Had 'standard' G1G1 activities, now it's only the ones which I've custom installed. So. it looks like joyride is going the route of Update.1 ? Shipping with no activities ? Yes. http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes lists the ways in which you can reinstall the activities. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride-2009 from 1949 (No standard activities)
On Wed, Jun 04, 2008 at 04:41:38PM +0200, Morgan Collett wrote: On Wed, Jun 4, 2008 at 4:38 PM, Ixo X oxI [EMAIL PROTECTED] wrote: I too just upgraded to Joyride-2009 last night. I jumped from joyright 1949 to joywrong 2009 (about a 4 week difference)... Had 'standard' G1G1 activities, now it's only the ones which I've custom installed. So. it looks like joyride is going the route of Update.1 ? Shipping with no activities ? Yes. http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes lists the ways in which you can reinstall the activities. You'll want them in /home/olpc/Activities That way they won't be wiped during the system updates. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
Le mercredi 23 avril 2008 à 19:31 -0400, Benjamin M. Schwartz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | Simon Schampijer wrote: | | Chris Ball wrote: | | Hi, | | | | Can anybody suggest a relatively functional Joyride with the new UI | | ? I'm at the end of a think pipe, and probably won't have time to | | download a second image if the first is marginal... | | | | 1896 ? | | | | The new Journal design landed in 1895, and there were many sugar changes | | in 1894. I think 1892 is a decent bet. | | | | - Chris. | | | | 1895 has latest journal which has some changes for the new UI as well - | | I run it here fine. | | In 1896, I am consistently unable to open Write. Everything else seems to | work. I guess I don't recommend 1896, for that reason. I don't know | when this bug was introduced. As usual, I spoke too soon. The only activity that works under 1896 is Terminal. Everything else dies without producing any logfiles. It appears that this is due to the presence-service change in 1896. The only change is this new presence-service is https://dev.laptop.org/git?p=projects/presence-service;a=commitdiff;h=507e53d55d2f0767f35777e2db40abd654605f08 It shouldn't affect activities launching. G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
Le mercredi 23 avril 2008 à 19:31 -0400, Benjamin M. Schwartz a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | Simon Schampijer wrote: | | Chris Ball wrote: | | Hi, | | | | Can anybody suggest a relatively functional Joyride with the new UI | | ? I'm at the end of a think pipe, and probably won't have time to | | download a second image if the first is marginal... | | | | 1896 ? | | | | The new Journal design landed in 1895, and there were many sugar changes | | in 1894. I think 1892 is a decent bet. | | | | - Chris. | | | | 1895 has latest journal which has some changes for the new UI as well - | | I run it here fine. | | In 1896, I am consistently unable to open Write. Everything else seems to | work. I guess I don't recommend 1896, for that reason. I don't know | when this bug was introduced. As usual, I spoke too soon. The only activity that works under 1896 is Terminal. Everything else dies without producing any logfiles. It appears that this is due to the presence-service change in 1896. Write does work for me with 1896 (as the few others activities I tried). G. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
Hi, Can anybody suggest a relatively functional Joyride with the new UI ? I'm at the end of a think pipe, and probably won't have time to download a second image if the first is marginal... 1896 ? The new Journal design landed in 1895, and there were many sugar changes in 1894. I think 1892 is a decent bet. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
Chris Ball wrote: Hi, Can anybody suggest a relatively functional Joyride with the new UI ? I'm at the end of a think pipe, and probably won't have time to download a second image if the first is marginal... 1896 ? The new Journal design landed in 1895, and there were many sugar changes in 1894. I think 1892 is a decent bet. - Chris. 1895 has latest journal which has some changes for the new UI as well - I run it here fine. Best, Simon ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Simon Schampijer wrote: | Chris Ball wrote: | Hi, | | Can anybody suggest a relatively functional Joyride with the new UI | ? I'm at the end of a think pipe, and probably won't have time to | download a second image if the first is marginal... | | 1896 ? | | The new Journal design landed in 1895, and there were many sugar changes | in 1894. I think 1892 is a decent bet. | | - Chris. | | 1895 has latest journal which has some changes for the new UI as well - | I run it here fine. In 1896, I am consistently unable to open Write. Everything else seems to work. I guess I don't recommend 1896, for that reason. I don't know when this bug was introduced. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID8UdUJT6e6HFtqQRAjzJAJ9xuuaU1l0qqJgzbK32d7mOBheNFQCaAuU7 vQZTcRHXT+E7jOXGtMGxotg= =91tl -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin M. Schwartz wrote: | Simon Schampijer wrote: | | Chris Ball wrote: | | Hi, | | | | Can anybody suggest a relatively functional Joyride with the new UI | | ? I'm at the end of a think pipe, and probably won't have time to | | download a second image if the first is marginal... | | | | 1896 ? | | | | The new Journal design landed in 1895, and there were many sugar changes | | in 1894. I think 1892 is a decent bet. | | | | - Chris. | | | | 1895 has latest journal which has some changes for the new UI as well - | | I run it here fine. | | In 1896, I am consistently unable to open Write. Everything else seems to | work. I guess I don't recommend 1896, for that reason. I don't know | when this bug was introduced. As usual, I spoke too soon. The only activity that works under 1896 is Terminal. Everything else dies without producing any logfiles. It appears that this is due to the presence-service change in 1896. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFID8baUJT6e6HFtqQRAnzBAJ9uVgOVSFJLjjIDATwDno7YbFv4QwCeJaru nQvdKR436VRtGKasLl+HSjU= =wuft -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
Hi, In 1896, I am consistently unable to open Write. Everything else seems to work. I guess I don't recommend 1896, for that reason. I don't know when this bug was introduced. The tinderbox (which I'm not quite ready to promote again yet) says that it could launch Write, and that Write opened its root window, on 1894 and 1895, and it hasn't run against 1896 yet. So, we can suspect that it's either in 1896 only or local to your build. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride
I'm running Joyride 1894, manually updated to 1896 level. My installed sugar-presence-service is 0.79.3-1.olpc2 [Had a bit of trouble with 'telepathy-plugin.py' -- changed some single quotes to double quotes.] Write (and all other Activities I've tried) work for me. mikus (G1G1) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride is reopened for development.
Hi, We'd like to invite a discussion about process changes to ensure that our Joyride builds continue to be stable and usable. Ideas welcome! And here's my own entry, which limits itself to what we should do in the short-term, before process changes: * Stagger new features so that we maximise our chance of having a working build all the time, and so that we can take performance measurements with independent variables. * The two major features waiting to be pushed to Joyride are tomeu's faster work, which greatly improves activity launch time, and his implementation of the new Sugar shell design. We should push the faster work first so that we can measure its performance impact before and after the new UI. * Continue to have (all) activities present in Joyride builds. * Joyride should be a showcase for XO development, and including plenty of activities will help to get those activities tested. If you have an activity that works and is ready for testing by the community at large, feel free to push it into Joyride. Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride builds are incomplete
A new working joyride build is out: http://xs-dev.laptop.org/~cscott/olpc/streams/joyride/build1658/ Best, Simon Mark Bauer wrote: I would like to try the latest builds, but all builds (6 of them) after joyride-1643 are incomplete? dev.laptop.org/~bert/joyride-pkgs.html and the rsync rsync://updates.laptop.org both show only up to 1643 as good? Is there a better place to look? Thanks Mark ___ 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: Joyride and Update.2
On Feb 6, 2008, at 15:13 , Marco Pesenti Gritti wrote: Hello, is joyride open for Update.2 development? If not when do we plan to reopen it? How about having three builds - like stable, testing, and unstable? Currently, joyride is swinging back and force between testing and unstable which is rather annoying ... - Bert - ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride---Update.1 transition
Hi, Something I'm curious about (for a set of slides I'm working on) is how stuff transitions from Joyride to Update.1 builds--both the mechanics (how the bits get copied), and the procedural and decision processes involved. http://wiki.laptop.org/go/Update.1_process describes the decision process. As it suggests, the bits are copied by tagging RPMS that are already in Joyride into the Update.1 branch in Koji. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride-1563 broken, olpc.fth missing, fails to boot [FIX]
You don't really need the entire olpc.fth - the following lines should suffice: ok setenv ramdisk n:\boot\olpcrd.img ok boot n:\boot\vmlinuz root=mtd0 rootfstype=jffs2 Those lines are short enough to type manually. The rest of olpc.fth is just automated reflash and support for boot-alt. Most of the cmdline arguments (ro, console=, fbcon=) are unnecessary - the only required ones are the root specifiers. Mitch James Cameron wrote: If you do this, and need to fix it, here is how I did it ... only valid for developer machines without write-protect, of course: 1. boot into OFW and enable the wireless and telnetd, ok essid quozl.linux.org.au ok telnetd (naturally you will use a different essid). 2. note the IP address and telnet to it from another system, % telnet 10.0.0.147 3. on this other system, obtain a copy of /boot/olpc.fth from build joyride-1551 and display it on your screen, without any line-wraps, rsync \ rsync://updates.laptop.org/build-joyride-1551/root/boot/olpc.fth \ . cat olpc.fth 4. cut and paste the FORTH definitions one at a time, 5. type the last command and press enter, ok olpc-fth-boot-me If you cut and paste this, some letters may not echo, because USB is turned off at this point, which stops the telnet reasonably quickly. Your telnet session on the other system will hang. Not important. 6. wait for a few seconds, and the Linux kernel boot log should appear, on the screen of the XO, 7. on the XO, as root, copy the olpc.fth file from where it is in /versions to where it should be in the new pristine tree, 8. reboot, problem solved. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride-1563 broken, olpc.fth missing, fails to boot [FIX]
If you do this, and need to fix it, here is how I did it ... only valid for developer machines without write-protect, of course: 1. boot into OFW and enable the wireless and telnetd, ok essid quozl.linux.org.au ok telnetd (naturally you will use a different essid). 2. note the IP address and telnet to it from another system, % telnet 10.0.0.147 3. on this other system, obtain a copy of /boot/olpc.fth from build joyride-1551 and display it on your screen, without any line-wraps, rsync \ rsync://updates.laptop.org/build-joyride-1551/root/boot/olpc.fth \ . cat olpc.fth 4. cut and paste the FORTH definitions one at a time, 5. type the last command and press enter, ok olpc-fth-boot-me If you cut and paste this, some letters may not echo, because USB is turned off at this point, which stops the telnet reasonably quickly. Your telnet session on the other system will hang. Not important. 6. wait for a few seconds, and the Linux kernel boot log should appear, on the screen of the XO, 7. on the XO, as root, copy the olpc.fth file from where it is in /versions to where it should be in the new pristine tree, 8. reboot, problem solved. -- James Cameronmailto:[EMAIL PROTECTED] http://quozl.netrek.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride image Jffs2 on usb ?
On Dec 29, 2007 6:36 PM, Ivan Krstić [EMAIL PROTECTED] wrote: On Dec 28, 2007, at 9:32 PM, Mr frÿffe9dÿffe9ric pouchal wrote: There is a file that ends with jffs2.usb Does it mean that you can use jffs2 on usb ? No, and you don't want to be using JFFS2 on a USB hard drive. It is a flash filesystem. From a quick glance at the pilgrim source, however, generation of those .usb files for the JFFS2 image flavor strikes me as a mistake. Scott, can you elucidate? As is documented at http://wiki.laptop.org/go/olpc-update the osXYZ.usb files are used for olpc-updating to the new build from a USB key or SD card. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: joyride image Jffs2 on usb ?
On Dec 28, 2007, at 9:32 PM, Mr frÿffe9dÿffe9ric pouchal wrote: There is a file that ends with jffs2.usb Does it mean that you can use jffs2 on usb ? No, and you don't want to be using JFFS2 on a USB hard drive. It is a flash filesystem. From a quick glance at the pilgrim source, however, generation of those .usb files for the JFFS2 image flavor strikes me as a mistake. Scott, can you elucidate? -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Joyride 1436 a bust
On 12/17/07 14:06, Marcus Leech wrote: Multitudinous modprobe errors on start. See the thread about 1432. If you need to test this build, just do a depmod -a manually and reboot. The fix is already on its way. Maybe someone could revert to the previous version of the kernel package for the time being? -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
