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
available storage).
The GCompris install (XO-1.5) is
#install gcompris
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
easily 'sugarized'.
Tony
On 10/15/2015 09:53 PM, Jerry Vonau wrote:
On October 15, 2015 at 4:24 PM James Cameron <qu...@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 <qu...@laptop.org>
wrote:
Can you tell us the length of the testing you've done?
Just opening the activity, poke around a bit with the intent that
educators
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
for
me.
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
fedora
seems like a one-off fork to me.
F19 at tuxmath-2.0.1-4.fc19.i686.rpm, F20 at
tuxmath-2.0.1-5.fc20.i686.rpm,
F21 at tuxmath-2.0.1-7.fc21.i686.rpm, F22 at
tuxmath-2.0.1-7.fc22.i686.rpm.
Interesting.
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
TuxMath-4.xo"
When you say "same way as before" as in bundle all the different
arches'
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
file,
that would gone a long way in sorting out the question of which arches
the
activity can run on and could possibly be used by ALSO to inform the
person
downloading before installing something that it will not work at all on
their machine's platform. Would(should?) something like that be worthy
of
GSOC effort?
No, not at this stage of the evolution of Sugar. That horse has
bolted, in my opinion.
Agreed.
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
behind
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
already:
http://dev.laptop.org/~german/rpms/tuxmath/
That would explain where version 2.0.3 is coming from but above you
said
that 2.0.3 was buggy. I would like some clarification please, might it
need
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
enable
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
repo
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
where
talks are given about a subject but don't really do anything useful to
make
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
find
them.
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
Fedora.
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.
Jerry
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
.
_______________________________________________
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
