[Sugar-devel] How to install TuxMath and TuxPaint on Release 13.2.5+ on "ALL" XOs!

[Jerry Vonau]

> 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>
> > > 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