[gcompris-devel] Release 8.5PRE1

Bruno Coudoin bruno.coudoin at free.fr
Sun Apr 6 14:45:07 UTC 2008


Le vendredi 28 mars 2008 à 15:39 +0100, Lars Vogdt a écrit :
> Hi all
> 
> On Sun, 23 Mar 2008 19:02:38 +0100, Bruno Coudoin <bruno.coudoin at free.fr>
> wrote:
> > What you can do to help:
> > - Test it on your platform and report here compilation and execution
> > issue.
> 
> ... here are my first test results:
> all results are from the same specfile containing 
> %configure  --enable-sqlite --enable-gnet

It makes me thing to removed --enable-gnet as it's a deprecated feature.
It's just useless to compile it.


> running with "make check" results in:
> 
> Executing(%check): /bin/sh -e /var/tmp/rpm-tmp.1347
> + umask 022
> + cd /usr/src/packages/BUILD
> + cd gcompris-8.5PRE1
> + make check
> Making check in po
> make[1]: Entering directory `/usr/src/packages/BUILD/gcompris-8.5PRE1/po'
> make[1]: *** No rule to make target `../boards/administration.xml.in',
> needed by `gcompris.pot'.  Stop.
> make[1]: Leaving directory `/usr/src/packages/BUILD/gcompris-8.5PRE1/po'
> make: *** [check-recursive] Error 1
> error: Bad exit status from /var/tmp/rpm-tmp.1347 (%check)

True, I need some cleanup there.

> running without the check: build proceedes successfully. Packages should be
> available in a few hours here:
> http://download.opensuse.org/repositories/home:/lrupp/openSUSE_10.3/
> 
> 
> openSUSE Factory x86_64 (gcc4.3):
> gcc -DHAVE_CONFIG_H -I. -I../.. -I../../intl -DDATADIR=\""/usr/share"\"
> -I../../src -I../../src/goocanvas/src -pthread -I/usr/include/gtk-2.0
> -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo
> -I/usr/include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2
> -I/usr/include/libpng12 -I/usr/include/gstreamer-0.10
> -I/usr/include/libxml2 -I/usr/include/librsvg-2    -I/usr/include/libxml2  
> -DGNOME_DISABLE_DEPRECATED         -O2 -fmessage-length=0 -Wall
> -D_FORTIFY_SOURCE=2 -fstack-protector  -Wall -Werror -MT bar.o -MD -MP -MF
> .deps/bar.Tpo -c -o bar.o bar.c
> cc1: warnings being treated as errors
> bar.c: In function 'gc_bar_start':
> bar.c:245: error: call to function '_force_bar_down' without a real
> prototype
> bar.c:54: note: '_force_bar_down' was declared here
> make[4]: *** [bar.o] Error 1

I hopefully made a fix for that.


> > - Graphism should be moved to svg everywhere it makes sense. This is
> > especially
> >   important for the skins images but also for the activities images,
> > background
> >   and items (matou already started a long time ago and proposed to
> 
> That means fixing many python codelines as I see in src/*, right?

Yes. Python and C code have to be changed.

> Perhaps a fallback would be an idea?

What do you mean ?

> Questions: 
> 1) 
> I found many files (png and ogg) which are binary identical but in
> different directories. 
> I'm currently using fdupes [1] to create symlinks and save disc space. 
> Perhaps this is something you can also do in your autopackage?

This is a drawback of the new internal organisation where each activity
is self contained. I am please to learn about fdupes. My idea is to put
links in svn where appropriate. Thus all packaging system should
transparently avoid duplicate files.

> 2)
> I also like to move from *.wav to *.ogg to reduce space, too. 
> But this would currently result in patching the sources - as these contain
> hardcoded file endings like 
> src/clickgame-activity/clickgame.c:  gc_sound_play_ogg
> ("sounds/youcannot.wav", NULL);
> src/ballcatch-activity/ballcatch.py:       
> gcompris.sound.play_ogg("sounds/youcannot.wav")
> which confuses me, btw - as the name "sound_play_ogg" doesn't seem to play
> wav files. (sorry, haven't looked deeper into this) Is this right?
> Can you perhaps include a "fallback" mechanism which tries to load "*.ogg"
> files first - and falls back to "*.wav"? 

We already use ogg for voices, but not for sound effects. Ogg files
introduce a lag between a click and the decoding start. For this reason,
It's much better to keep our effects as wav.

> 3)
> For me it looks like runit.sh expects the gcompris binary in the gcompris
> directory. This would cause problems if you create packages following the
> FHS.
> Perhaps the script can even cause problems if someone calls
> /usr/local/share/gcompris/./runit.sh
> /usr/local/share/gcompris/scalesboard-activity/ 
> for example (haven't tested it yet)?

The runit.sh script is not used in regular packaging. It is used to test
a single activity from the source code and for launching individual
packaged activities like we do on the OLPC XO.

-- 
Bruno Coudoin
http://gcompris.net Free educational software for kids
http://toulibre.org Logiciel Libre à Toulouse





More information about the Gcompris-devel mailing list