Tux-paint fails to install

[cgaray]

Tried to install version 4 and 5 and both failed. 5 didn't even tried to and 4 starts and then hangs.

Tested on sugar 0.88 build 258py.

I also got a weird message (attached screenshot)

[cgaray]

what is this?

[bernie]

lol :-)

[alsroot]

cgaray, could you attach full log in debug mode ( http://wiki.sugarlabs.org/go/BugSquad/Get_Logs)

[alsroot]

Replying to alsroot:

cgaray, could you attach full log in debug mode ( http://wiki.sugarlabs.org/go/BugSquad/Get_Logs)

use v5, v4 has 0install related bugs

[mikus]

XO-1 build os1 (F14) - output log from tuxpaint activity

[mikus]

XO-1 build os1 (F14) - system dump after tuxpaint failed to launch

[mikus]

XO-1 build os1 (experimental F14 build) with sugar-0.89.8

Tried to launch Tuxpaint-5. 0install called home, then asked if I trusted Alexey Lim.
I indicated yes - but Tuxpaint failed to launch.

[alsroot]

Replying to mikus:

XO-1 build os1 (experimental F14 build) with sugar-0.89.8

Tried to launch Tuxpaint-5. 0install called home, then asked if I trusted Alexey Lim.
I indicated yes - but Tuxpaint failed to launch.

Tuxpaint on ASLO does not contain binaries build against F14 (in fact, it also doesn't support many other environments, thats why it has experimental status). It is pretty not trivial task to support binaries using current ASLO and .xo files. (Work for more reliable scheme is in progress.)

If there is need in Tuxpaint for particular deployment and current .xo doesn't work, ping me( http://wiki.sugarlabs.org/go/User:Alsroot#Contacts) and I'll build it for your disro.

[sascha_silbe]

Replying to alsroot:

Tuxpaint on ASLO does not contain binaries build against F14 (in fact, it also doesn't support many other environments, thats why it has experimental status). It is pretty not trivial task to support binaries using current ASLO and .xo files. (Work for more reliable scheme is in progress.)

Shouldn't it just try to build locally if there's no matching binary in the bundle?

[alsroot]

Replying to sascha_silbe:

Replying to alsroot:

Tuxpaint on ASLO does not contain binaries build against F14 (in fact, it also doesn't support many other environments, thats why it has experimental status). It is pretty not trivial task to support binaries using current ASLO and .xo files. (Work for more reliable scheme is in progress.)

Shouldn't it just try to build locally if there's no matching binary in the bundle?

In other words you are asking why it doesn't do all things right? ;)

Well, not all things at once. Building on user side will the last resort in 0sugar but at first time it will try to download already built binaries(in environment that is the same as user's) from bazaar.sl.o.

[mikus]

Replying to alsroot:

Shouldn't it just try to build locally if there's no matching binary in the bundle?

Well, not all things at once.

I realize that SugarLabs NEEDS to use 0install to accomodate the various environments. But I as an independent tester am in effect functioning as the distributor for my own "country".

Back before 0install was merged into Tux-paint, I was able (via yum) to manually ADD missing packages (e.g., libpaper) to my system, if running Tux-paint depended upon a particular package being present. It would be nice if, when 0install failed to get binaries from bazaar.sl.o, it would log (clearly) what was needed. I (as the virtual "country distribution provider") could then be responsible for manually adding those binaries to my environment, and be able to run the Activity despite 0install itself not having access to something.

[sascha_silbe]

Replying to alsroot:

Well, not all things at once. Building on user side will the last resort in 0sugar but at first time it will try to download already built binaries(in environment that is the same as user's) from bazaar.sl.o.

Given that we can only build binaries for a very limited number of environments (the number is distributions is  huge and so far we only have x86/amd64 hardware) I would expect the fallback to be implemented sooner rather than later. Of course it's a matter of priorities and I can understand why you care more about the million users using a few distros on a single hardware platform (XO = x86). But please consider that you'll get more testing if it works on other systems, too.