Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#2052 closed defect (wontfix)

Tux-paint fails to install

Reported by: cgaray Owned by: alsroot
Priority: Unspecified by Maintainer Milestone: Unspecified
Component: activities.sugarlabs.org Version: 0.88.x
Severity: Blocker Keywords:
Cc: bernie Distribution/OS: Fedora
Bug Status: Unconfirmed

Description

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)

Attachments (3)

wt.png (24.5 KB) - added by cgaray 9 years ago.
what is this?
Tuxpaint-5.log (233.6 KB) - added by mikus 9 years ago.
XO-1 build os1 (F14) - output log from tuxpaint activity
logs.CSN750001F8.2010-09-08.12-19-36.tar.bz2 (367.1 KB) - added by mikus 9 years ago.
XO-1 build os1 (F14) - system dump after tuxpaint failed to launch

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by cgaray

what is this?

comment:1 Changed 9 years ago by cgaray

  • Cc bernie added
  • Component changed from sugar to activities.sugarlabs.org
  • Distribution/OS changed from Unspecified to Fedora
  • Owner changed from tomeu to alsroot
  • Severity changed from Unspecified to Blocker
  • Status changed from new to assigned
  • Version changed from Unspecified to 0.88.x

comment:2 Changed 9 years ago by bernie

lol :-)

comment:3 follow-up: Changed 9 years ago by alsroot

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

comment:4 in reply to: ↑ 3 Changed 9 years ago by 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

Changed 9 years ago by mikus

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

Changed 9 years ago by mikus

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

comment:5 follow-up: Changed 9 years ago by 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.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 9 years ago by alsroot

  • Resolution set to wontfix
  • Status changed from assigned to closed

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.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 9 years ago by 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?

comment:8 in reply to: ↑ 7 ; follow-ups: Changed 9 years ago by 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.

comment:9 in reply to: ↑ 8 Changed 9 years ago by 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.

comment:10 in reply to: ↑ 8 Changed 9 years ago by 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.

Note: See TracTickets for help on using tickets.