quozl at laptop.org
Wed Jun 3 02:07:00 EDT 2015
On Wed, Jun 03, 2015 at 05:37:47AM +0200, Tony Anderson wrote:
> Obviously, Ubuntu is non-starter for an XO deployment.
Yes. But given that this is the sugar-devel@ list, I wouldn't want
people to think it is a TuxMath or Sugar problem. My tests on Ubuntu
show it isn't.
> There are deployments which require signed images (e.g. Rwanda).
Yes, but that's their decision.
> The original idea in Sugar was that activities needed to satisfy any
> software dependencies not supplied by Sugar. The tuxmath-2.xo met
> that requirement up to 0.94.
Yes. So what you are looking for is someone to fix TuxMath on Fedora
18, and then package it in the same way as before, as a TuxMath-4.xo.
I'm not planning to do that.
But whoever you engage to do that; and there are several people and
organisations you can engage; they can have the confidence that the
problem is better understood than before.
You'll end up with something that can be used on any Fedora 18 build,
but no later version. Unsustainable again.
> For example, geogebra depends on jre and supplied that dependency.
> If use of geogebra requires installation of jre in the image then
> every XO will use the required storage whether geogebra is installed
> or not.
Yes, that's an another example of manual dependency resolution, and a
consequence of a non-native application being forced kicking and
screaming into the .xo gaol. I can't recommend it.
For deployments who make their own builds, this dependency resolution
is quite easy.
> The obvious problem is that activities which depend on object
> modules work only on the XO-1 and XO-1.5. In the original spirit,
> this would mean two (or more) versions of an activity - one for the
> x86 and one for arm.
That's not a problem.
Paint is an activity that has binaries of all three varieties; 32-bit
x86, 64-bit x86_64/amd64, and armv7l; look in the fill directory.
Paint also works fine if these binaries are missing or fail to load.
That's not something that can be said for TuxMath and Geogebra
> Another change is that with an XO-1 running on an SD card, there may
> be free storage available to include these packages in the build.
> The addition of these packages must be an official part of the
> signed image so that activities can be modified to use them. This
> would mean that deployments of XO-1 would have to acquire SD cards
> for each laptop (in Rwanda there are thousands of XO-1s deployed so
> the cost to acqure and to distribute the SD cards is not trivial).
My recommendation is to spend that effort on technical education of
the critical people to get either access to the deployment keys,
injection of your own key, or mass unlock.
I don't plan to make XO-1 SD card builds with activities or packages
not in the NAND Flash builds. That's a multiplier of effort that I
> > In addition to what Gonzalo said in earlier reply, this need to
> > change the .info file was fixed for Sugar 0.105.0, so please
> > upgrade. What's your upgrade plan? Have you made sure the next
> > version of Sugar will meet your needs?
> At the moment, the deployments I am working with are using 12.2.1 on
> the XO-1 and 13.2.1 on the other models. I hope to upgrade for the
> next version of BERNIE for the next school year (by the Malaysia
> Summit). I expect that the image at that point will be based on
> Fedora 22 and so will require extensive testing.
But I'm not planning a Fedora 22 build. My question was about Sugar;
we're on sugar-devel at . Are you saying you won't be upgrading Sugar
unless you can get a signed build?
If so, your only upgrade option at the moment is to Sugar 0.104, which
is in 13.2.3 for XO-4 and XO-1.75, and in 13.2.4 for XO-1.5 and XO-1.
Once Sugar 0.106 is released, I'm considering making a signed build
based on Fedora 18. If you committed to testing that for deployment
in the new year, it would gain greater priority.
So have you been testing Sugar 0.105? If you don't, then when a build
based on Sugar 0.106 arrives your task will be far larger, and any
blocking problems you find will block your deployment of it.
According to the schedule, you have until the end of the month:
To test Sugar 0.105.2, please upgrade using German's packages, which
you can do on a signed build:
> I had hoped to use an SD card with each model so I could be able to
> boot the current image or the new image as needed for
> troubleshooting. When I installed the newer images they ignored the
> SD card and flashed the internal store. What might work is running
> the current builds on the SD card. However, the install of the newer
> images updates the firmware which may make it impossible to run the
> older releases.
You did it wrong. Installing to SD card is supported on 13.2.4
using a locked XO-1:
Installing to SD card on the other models requires an unlocked laptop,
and careful manual steps:
There is no signed SD card build for the XO-1.5, XO-1.75 and XO-4.
Yes, you cannot downgrade firmware on a locked laptop. Unlock it:
> I am working on a method to test the ASLO activities to see which
> are still viable. In the case of GCompris, the 'unsustainable'
> install technique works well so the 100 GCompris activities in ASLO
> are not needed. This still leaves about 300 to be tested. So far I
> have been unable to get any Sugar Web Activity to work - it appears
> that Sugar is not displaying the index.html (For example, when I
> display the index.html of the Web Welcome in Browse, it works as
> expected; however, launching from the list/home view shows no
> errors, but nothing appears on the screen.)
That's a new one. Perhaps you'd like to post that as a separate issue
rather than hide it on the end of a rather long thread? ;-)
More information about the Sugar-devel