[Sugar-devel] How to install TuxMath and TuxPaint on Release 13.2.5+ on "ALL" XOs!
tony_anderson at usa.net
Fri Oct 16 08:01:03 EDT 2015
For what it's worth, TuxPaint can be readily installed on 13.2.5 as a
gnome application. It is part of GCompris which can also be easily
installed on a
13.2.5 system with enough storage (XO-1 with 1GB works but limits the
The GCompris install (XO-1.5) is
sudo rpm -ivh libpaper-1.1.24-4.fc17.i686.rpm
sudo rpm -ivh tuxpaint-0.9.21-8.fc17.i686.rpm
sudo rpm -ivh gnucap-0.35-9.fc17.i686.rpm
sudo rpm -ivh gnuchess-5.08-2.fc17.i686.rpm
sudo rpm -ivh gcompris-12.11-1.fc17.i686.rpm
I believe the first two rpms are sufficient to install TuxPaint. It can be
On 10/15/2015 09:53 PM, Jerry Vonau wrote:
>> On October 15, 2015 at 4:24 PM James Cameron <quozl at laptop.org> wrote:
>> On Thu, Oct 15, 2015 at 08:56:06AM -0500, Jerry Vonau wrote:
>>>> On October 15, 2015 at 1:17 AM James Cameron <quozl at laptop.org>
>>>> Can you tell us the length of the testing you've done?
>>> Just opening the activity, poke around a bit with the intent that
>>> can make an evaluation and report bugs.
>>>> My tests of 2.0.3 on 31st August were horrifying. Too unstable. It
>>>> keeps crashing, within minutes. Errors like "Video Surface changed
>>>> from outside of SDL_Extras!"
>>> Did you mean to say 2.0.1 here? That is what yum installed from Fedora
>> No, I meant 2.0.3.
>>>> Tony reported similar on sugar-devel@ on 2nd June, with Segmentation
>>>> Fault. Looking back at the mail thread, we think these are Fedora
>>>> related issues; the same version of TuxMath works fine on Ubuntu, and
>>>> later Fedora.
>>> I'm unsure where version 2.0.3 you refer above to is coming from or who
>>> might of created the rpm as there is no such version released from
>>> seems like a one-off fork to me.
>>> F19 at tuxmath-2.0.1-4.fc19.i686.rpm, F20 at
>>> F21 at tuxmath-2.0.1-7.fc21.i686.rpm, F22 at
> Yes very, that is why I went with the Fedora version for testing.
>>> If your suggesting that Fedora might want to update the released
>>> version to
>>> 2.0.3, file a bug at Fedora against tuxmath stating such.
>> No thanks.
> Any reason why? Maybe not filed by you personally but that seems to be the
> accepted way when having to deal with upstream Fedora code. Or one forks
> the code and supports the fork IMHO.
>>>> In the end, he agreed we need "someone to fix TuxMath
>>>> on Fedora 18, and then package it in the same way as before, as a
>>> When you say "same way as before" as in bundle all the different
>>> libraries with the .xo file? That is a waste of space for XO-1s with
>>> unneeded files.
>> Yes, but that's what the public wanted, despite the waste of space.
> Well I might suggest have a different bundle_id for the different
> platforms, with the activities named as such. Maybe something like
> tuxmath-4-arm.xo with the bundle_id=arm.org.tuxpaint might be the way to go
> forward without much more effort. That idea is not thought all the way
> through and is open for discussion.
>>> Too bad that supported_arches= didn't make it into the activity.info
>>> that would gone a long way in sorting out the question of which arches
>>> activity can run on and could possibly be used by ALSO to inform the
>>> downloading before installing something that it will not work at all on
>>> their machine's platform. Would(should?) something like that be worthy
>>> GSOC effort?
>> No, not at this stage of the evolution of Sugar. That horse has
>> bolted, in my opinion.
>>>> The difference between your TuxMath-3.1.xo and TuxMath-3.2.xo is the
>>>> latter has "max_participants = 1", meaning it can't be shared by
>>>> collaboration. That's better.
>>> Agreed, trying to share audio might cause issues, that was the idea
>>> using max_participants=1 in the activity.info file, that was thought up
>>> while I was part of AU in the past and made it into sugar proper.
>>>> Your arm/ directory is empty. We have XO-1.75 and XO-4 packages
>>> That would explain where version 2.0.3 is coming from but above you
>>> that 2.0.3 was buggy. I would like some clarification please, might it
>>> a later version of some dependence also or is missing one?
>> Good idea. But I've no answer.
> Well the user base of whatever number of XOs/classmates that SL claims are
> in use might be looking for one.
>>>> When you have it working with OSBuilder, please submit a patch.
>>> No patching needed, would just be entries in the build's ini file to
>>> the above repo, install the rpms and activities.
>> The .ini files are in git, so changing them would be a patch, sorry if
>> that was not clear.
> The OSbuilder part was posted, should a deployment want to use
> tuxmath so I don't think I need to send one in for the official release.
>>> Looks like German has already done that, otherwise why would the yum
>>> live on dev.laptop.org like rpmdropbox does?
>> I've no answer.
> Maybe German does?
>>>> I'm glad this isn't turning out to be one of those rainbow pooing
>>>> unicorn events,
>>> When I'm involved it never is, IMHO that would apply to those events
>>> talks are given about a subject but don't really do anything useful to
>>> the deployment or end-user's life easier.
>>>> and that somebody is actually working on it!
>>> Well I'm not bug fixing, just opening the door for others to test and
>> Same here. Oh well.
> Knowing your limited bandwidth I did do a quick shakedown of .106 on F23
> SoaS, much better now that it boots.
>>>> Meanwhile, I'm looking for kernel developers to help with porting to
>>>> later kernels on all XO laptops so that we can go to a more recent
>>> Off topic for this thread until released, but what is
>>> missing/doesn't work?
>> Agreed, off topic. No later kernel will boot on XO-1.75 or XO-4.
> If you do get a kernel/initrd.img/olpc.fth to test booting with I'll toss
> that on a usbkey an give it a go.
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
More information about the Sugar-devel