#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)
Change History (13)
Changed 13 years ago by cgaray
comment:1 Changed 13 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 13 years ago by bernie
lol :-)
comment:3 follow-up: ↓ 4 Changed 13 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 13 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
comment:5 follow-up: ↓ 6 Changed 13 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: ↓ 7 Changed 13 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: ↓ 8 Changed 13 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: ↓ 9 ↓ 10 Changed 13 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 13 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 13 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.
what is this?