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

[James Cameron]

On Fri, Oct 16, 2015 at 08:46:27AM -0500, Jerry Vonau wrote:
> 
> 
> > On October 16, 2015 at 4:02 AM James Cameron <quozl at laptop.org> wrote:
> > 
> > 
> > On Thu, Oct 15, 2015 at 08:53:21PM -0500, 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>
> > > > > > 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.
> > 
> > No reason to.
> > 
> > Sources here have several fixes after 2.0.3 that might be of interest:
> > 
> > http://anonscm.debian.org/cgit/tux4kids/tuxmath.git/log/
> > 
> 
> If I file the request at Fedora that will be handy, thanks.
>  
> > > 
> > > > 
> > > > > > 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.
> > 
> > Doesn't sound simple for the end user.  If they can't just click on a
> > bundle to install it, they will need hand holding.  When they need
> > hand holding, they either abandon the idea, or ask for help from the
> > close-to-mythical support gang.
> >
> 
> I don't see how the end-user click to install is affected, the activity
> developer would be preparing the .xo bundle for installation. I'm
> suggesting that if the bundle contains large libraries at activity
> packaging time one could include support for a single architecture while
> having the architecture info form part of the activity name. The bundle_id=
> part would be for the updater backend to be able to tell the difference
> between available support and maybe displaying on the SL's activity
> website. 

It is affected because there would be different downloads for different
architectures, and it is this that the simple end user would rebel
against.  A regression.

> > > > 
> > > > > 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.
> > 
> > Apart from Tony, my guess is that this subset of the user base is also
> > mythical.
> > 
> 
> ???? 
> 
> > > 
> > > > > > 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.
> > 
> > It wasn't in Adam's readme.txt, only some speculation that George is
> > seeking a way.
> >
> 
> The readme is intended for an at home do-it-yourself howto, I pointed
> George to the info on how to use the OS-builder module. 

Okay.  My request stands; when anybody has it working with OSBuilder,
please submit a patch to the .ini file or whatever else needs changing.

> > > > > 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.
> > 
> > You might also be interested in the Ubuntu build which has working
> > collaboration.  ;-)
> > 
> 
> No not really, as with any image the fix might be in the build scripts and
> not in the distribution proper.

The fix is to use an older version of Telepathy Gabble, with a
different package name, with the Sugar package depending on the name.

It's such a simple fix, and it works so well.

> It's still broken on Fedora, that is my
> concern. Remember SL is the upstream source for Fedora's source used to
> package up sugar for redistribution in fedora.
> 
> > http://wiki.sugarlabs.org/go/Ubuntu
> >
> 
> What I would be interested in is the build scripts that built the
> installer's iso image (noted as being x86_64) to create an i686 equivalent
> to test on XO-1.5. I think I could boot off of a usbkey for some quick
> testing but the i686 iso is not available to try.

The XO-1 and XO-1.5 do not boot from installers like PC systems do, so
that wouldn't help.

> Not being an Ubuntu user, how is the ARM support on Ubuntu?

No idea.

> Jerry

-- 
James Cameron
http://quozl.linux.org.au/