[etoys-dev] Build 47: Still Problem Updating to latest Etoys

Bert Freudenberg bert at freudenbergs.de
Wed Dec 2 06:35:48 EST 2009


On 02.12.2009, at 07:16, Milan Zimmermann wrote:
> On November 30, 2009, Bert Freudenberg wrote:
> > The .xo bundle did not change at all between these versions (in fact, not
> >  for a year or so). The only file that changes in it is the NEWS file. I
> >  should stop updating the bundle because it is unnecessary - new etoys
> >  versions for the XO require a new rpm, not a new xo bundle. I just don't
> >  have a good idea what the versioning scheme for the bundle should look
> >  like.

> I guess Etoys.activity (and everything below) should typically remain the same for future releases

Yes.

> , but does that mean the os and the activity updater is ignoring version numbers from the activity.info?

No, why?

> I understand from here:
> http://dev.laptop.org/ticket/9459
> that the version number stored in /etc/olpc-release defines that the updater will look into http://etoys.laptop.org/xo/11.0  for the version number corresponding to that release. But the link points to 108 - as you said I assume that should be updated but probably does not matter, but how does the activity updater in control panel know where to look for the latest version, does it simply look for the latest Etoys-ijk.xo in 
> http://etoys.laptop.org/rpms/?C=M;O=D
> ?.

No, the updater looks in

	http://etoys.laptop.org/xo/11.0

because our activity.info file specifies update_url as

	http://etoys.laptop.org/xo

If you examine its HTML source code you can see the embedded "micro format" annotations:

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

If the updater finds multiple of these annotations it would use the highest-numbered, but on the Etoys page we only have one.

Here is a description of update_url:

	http://wiki.laptop.org/go/Activity_Bundles#.info_file_format

I think deployments can override the update_url so they can provide their own versions. This also gets used if a bundle does not specify its own update_url.

And, the pre-installed activity versions for F11 is looked up here:

	http://wiki.laptop.org/go/Activities/G1G1/11.0

I just changed that to 113, so this should be in the next OLPC build. You would have to use the USB method (osXY.zd) to verify this, since olpc-update does not touch the activities I think.

> Anyway,  I do not understand the XO activity versioning, and whether to report any problem with the updater, in the 46 version it was reporting wrong versions on update, but now is fine, without any of the numbers (in activity.info, /etc/olpc-release, and http://etoys.laptop.org/xo/11.0)
> being changed....

What version did it report? 

If I run the updater on my machine now, it does not report a new version. I have 108 installed.

Actually, I have to change the version now. So it should update to 113 next time you run the activity updater.

> Sorry for these long questions, ignore it unless there is a simple known explanation :)
> Thanks,
> Milan

I thought it's pretty simple, but seeing it written down makes obvious it isn't. And it's not even the full story yet. Read on for the future, not sure yet if it will simplify or complicate matters.

Sugar 0.86 introduces a totally different updater. IIUC, it ignores the bundle's update_url and only looks for the latest version on

	http://activities.sugarlabs.org/

For that the updater does not use the micro-format HTML annotations but an XML format:

	http://wiki.sugarlabs.org/go/Features/Sugar_Update_Control_ASLO

Additionally, if you use the Browse activity to visit the site, the server automatically chooses which version to display based on the Browser's Sugar version.

So for that to work I had to additionally specify which Etoys bundle version to use for which Sugar release:

	http://activities.sugarlabs.org/en-US/sugar/addons/versions/4030

Phew. I hope I covered all the scattered pieces ...

I'll send a separate mail about the activity version name changes in Sugar 0.88. This is long enough already ;)

- Bert -



More information about the etoys-dev mailing list