[phpBB Debug] PHP Warning: in file [ROOT]/includes/functions.php on line 4280: ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression'
Oolite Bulletins • Having both trunk and release autopackages installed
Page 1 of 1

Having both trunk and release autopackages installed

Posted: Sat Aug 15, 2009 5:26 pm
by Diziet Sma
Since the nightly builds for linux seem to have died about 9 months ago with SVN1855, and since some people probably also would like to keep their 1.72.2 installation pure, yet still be able to run trunk, I have been experimenting with creating trunk autopackages in a similar fashion to the trunk installers I make for Windows.

I have gotten close to success now, but have run into a problem or three which I'd like to get some fresh perspectives on.

To begin with, all my Linux trunk autopackage builds are done on a clean (Oolite not installed) Kubuntu 9.04 installation running in VirtualBox, using the instructions from Getafix's How to build Oolite source on Ubuntu thread. They are tested in another Kubuntu 9.04 installation with 1.72.2 pre-installed, also running in VirtualBox.

So you can see what I've done so far, here are my changes to the standard code. I began by modifying default.apspec as follows. I've used <quote> instead of <code> so that I can highlight my additions in red.
# -*-shell-script-*-

# Modified by Diziet Sma for trunk installation purposes.

RootName: @oolite-linux.berlios.de/oolite:$SOFTWAREVERSION
DisplayName: Oolite-Trunk for Linux
ShortName: oolite-trunk
Maintainer: Dylan Smith <dyls@alioth.net>
Packager: Dylan Smith <dyls@alioth.net>
Summary: Oolite is an Elite tribute game that is easily expandable.
URL: http://oolite.aegidian.org
License: GNU GPL version 2
SoftwareVersion: 1.73
AutopackageTarget: 1.0
CPUArchitectures: x86

# Only uncomment InterfaceVersion if your package exposes interfaces to other software,
# for instance if it includes DSOs or python/perl modules. See the developer guide for more info,
# or ask on autopackage-dev if you don't understand interface versioning in autopackage.
# InterfaceVersion: 0.0

Oolite for Linux is an independent recreation and interpretation of the
classic space game Elite. Choose your side of the law. Choose your
profession. Above all, reach the Elite rating.

# we do the executable separately as this allows Autopackage to check
# the libc version. Note: autopackage doesn't seem to compress, that's
# why we are using tar files :/
make debug=no # don't build a debug version!
cp FreeDesktop/oolite-trunk.desktop $build_root
cp FreeDesktop/oolite-trunk-icon.png $build_root
cp oolite.app/oolite $build_root/oolite
tar zcf $build_root/oolite.app.tar oolite.app --exclude .svn
cd deps/Linux-x86-deps
cp oolite.src $build_root
cp oolite-update.src $build_root
tar zcf $build_root/oolite.deps.tar * --exclude .svn
echo $SOFTWAREVERSION >$build_root/release.txt


import <<EOF

# Dependency checking
#require @whatever.you/need 1.0

# Put your installation script here
outputStatus "Making Oolite directory in $PREFIX/lib/Oolite-trunk"
mkdirs $PREFIX/lib/Oolite-trunk
mkdirs $PREFIX/lib/Oolite-trunk/AddOns
mkdirs $PREFIX/lib/Oolite-trunk/doc
outputStatus "Unpacking trees"
tar zxf oolite.app.tar
tar zxf oolite.deps.tar
copyFiles oolite.app $PREFIX/lib/Oolite-trunk
copyFiles oolite-deps $PREFIX/lib/Oolite-trunk
copyFile release.txt $PREFIX/lib/Oolite-trunk/release.txt
outputStatus "Inserting oolite into app dir"
copyFile oolite $PREFIX/lib/Oolite-trunk/oolite.app/oolite
chmod +x $PREFIX/lib/Oolite-trunk/oolite.app/oolite
outputStatus "Installing documentation"
echo "This is the first time you've run the game. Here is the README file -" > README-PREAMBLE.TXT
echo "more docs can be found at $PREFIX/lib/Oolite-trunk/doc" >> README-PREAMBLE.TXT
echo "Press q to exit this document and launch the game" >> README-PREAMBLE.TXT
copyFiles *.TXT $PREFIX/lib/Oolite-trunk/doc
outputStatus "Creating shell scripts"
echo "#!/bin/sh" > oolite-trunk
echo "OOLITE_ROOT=$PREFIX/lib" >> oolite-trunk
echo "TOPLEVEL=$OOLITE_ROOT/Oolite" >> oolite-trunk
cat oolite.src >> oolite-trunk
echo "#!/bin/sh" > oolite-trunk-update
echo "OOLITE_ROOT=$PREFIX/lib/" >> oolite-trunk-update
echo "TOPLEVEL=$OOLITE_ROOT/Oolite" >> oolite-trunk-update
cat oolite-update.src >> oolite-trunk-update
installExe oolite-trunk oolite-trunk-update
installIcon oolite-trunk-icon.png
installDesktop "Game" oolite-trunk.desktop
outputStatus "Complete"

# Usually just the following line is enough to uninstall everything
The above all seems to work as planned. As you might guess from the above, I also had to rename /trunk/FreeDesktop/oolite.desktop and /trunk/FreeDesktop/oolite-icon.png to oolite-trunk.desktop and oolite-trunk-icon.png respectively, besides editing oolite-trunk.desktop internally to refer to oolite-trunk-icon.png.

All of this results in an autopackage that installs alongside a 1.72.2 installation quite neatly, with separate scripts and directories for almost everything. They appear as two separate items in the Autopackage Software Manager as well.

The biggest difference I've noticed so far is that (unlike with my windows trunk installers), both versions share the same oolite-saves and Logs directories. I would like to fix this if possible, but am not sure if it can be done, or how to do it.

Another problem is that a separate launching icon is not created in the menu under "Games" and I cannot determine why.

The biggest problem however, is that when I launch the game (by typing "oolite-trunk" from a bash shell), is that the game crashes with the following message (from the end of the oolite-trunk script)
"Erk. It looks like Oolite died with an error. When making an error report, please copy + paste the log above into the report. (Press Ctrl-C to continue)"
and the following Error Log is generated.

Code: Select all

[log.header]: Opening log for Oolite version <unknown version> (x86-32 test release) under Linux at 2009-08-15 08:34:28 -0500.
1 processor detected.
Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[sdl.init]: initialising SDL
[joystickHandler.init]: Number of joysticks detected: 0
[display.mode.list]: CREATING MODE LIST
[display.mode.list.native]: X11 native resolution detected: 800 x 600
[display.mode.list]: Added res 640 x 480
[display.initGL]: Creating a new surface of 800 x 543
[rendering.opengl.version]: OpenGL renderer version: 2.0.0 ("2.0 Chromium 1.9")
Vendor: Humper
Renderer: Chromium
[rendering.opengl.extensions]: OpenGL extensions (66):
GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_multisample GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_EXT_texture_env_combine GL_ARB_texture_env_dot3 GL_EXT_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_program GL_ARB_window_pos GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_func_separate GL_EXT_blend_subtract GL_EXT_texture_env_add GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_texture3D GL_IBM_rasterpos_clip GL_NV_fog_distance GL_NV_fragment_program GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_texgen_reflection GL_NV_texture_rectangle GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_SGIS_generate_mipmap GL_CR_state_parameter GL_CR_cursor_position GL_CR_bounding_box GL_CR_print_string GL_CR_tilesort_info GL_CR_synchronization GL_CR_head_spu_name GL_CR_performance_info GL_CR_window_size GL_CR_tile_info GL_CR_saveframe GL_CR_readback_barrier_size GL_CR_server_id_sharing GL_CR_server_matrix GL_ARB_shading_language_100 GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_fragment_shader
[dataCache.found]: Found data cache.
  [dataCache.rebuild]: Data cache version (1.72.2) does not match Oolite version ((nil)), rebuilding cache.
[searchPaths.dumpAll]: ---> OXP search paths:
("/home/test/.local/bin/Resources/oolite/Resources", AddOns, "/home/test/.Oolite/AddOns")
[dataCache.retrieve.failed]: Failed to retreive"search path modification dates" cache object search paths -- no such cache.
[dataCache.set.success]: Updated entry search paths in cache "search path modification dates".
[dataCache.set.success]: Updated entry modification dates in cache "search path modification dates".
[dataCache.retrieve.failed]: Failed to retreive"dictionaries" cache object Config/descriptions.plist merge:basic -- no such cache.
[dataCache.retrieve.failed]: Failed to retreive"ship registry" cache object ship data -- no such cache.
[dataCache.retrieve.failed]: Failed to retreive"ship registry" cache object player ships -- no such cache.
[shipData.load.begin]: Loading ship data...
  [startup.exception]: ***** Unhandled exception during startup: OOShipRegistryLoadFailure (Could not load any ship data.).

Closing log at 2009-08-15 08:34:29 -0500.

So far as I can determine, the trunk program is attempting to use resources from the 1.72.2 resources directory, and possibly doing the same for other things such as GNUstep resources also.

I suspect I will need to modify oolite.src and oolite-update.src to fix this, but am not sure if this is the case, nor am I sure of what changes I would need to make.

One last question: would it be a better idea to build the debug version rather than the release version I am making at the moment?

Posted: Sat Aug 15, 2009 6:13 pm
by another_commander
It looks like it sees GNUstep related folders created by 1.72.2 as you say(like the one containing the cache), but it does not seem to be able to locate any resources whatsoever, 1.72.2 or 1.73 alike. Unfortunately I cannot dare making any educated guesses, my Linux experience is very limited.

Posted: Sat Aug 29, 2009 12:41 am
by Diziet Sma

What, there isn't one Linux or Autopackage guru around to read this thread? :?: Maybe I need to email Dylan...

Posted: Sat Aug 29, 2009 1:12 am
by Kaks
Getafix did create the present autopackage, so if anyone can figure this out without too many problems, I'm pretty sure he's the man! :)

Posted: Sat Aug 29, 2009 3:07 pm
by zevans
I'll have a proper look at this tomorrow, but meanwhile I've found that building the Debian package from scratch works properly and I've been installing nightlies that way for some time now. There are definitely steps in the Debian build target logic that are missing from other make targets.

You could always make pkg-deb to get it built and then just ignore the packages and use whatever target it is that does an install...

Posted: Sat Aug 29, 2009 3:50 pm
by Diziet Sma
Thanks.. I'd appreciate that.. but maybe I need to clarify a little. I can build from trunk source fine, and it works well.. what I'm trying to achieve is something like what I've done with the windows trunk-installer I provide. The object is to be able to have both 1.72.2 and trunk installed side-by-side without any interference or conflict between them. They need to be independently upgradeable or uninstallable without causing problems also.

Oh yeah.. Debian packages are good, but not every flavour of Linux uses them.. Autopackages on the other hand, are universally usable regardless of distro, which is why I want to go that route.

Posted: Fri Sep 04, 2009 10:09 pm
by Getafix
@Diziet Sma
I can summarize the following issues:
1. Need for two "~/.Oolite" folders for Logs, Addons and two "~/oolite-saves" folders.
These are user owned files and are created in the user's home folder. I believe code modification is needed for this.

2. Need two separate launching icons.
Make sure the Name section of .desktop file reads

Code: Select all

Make sure the Exec section of .desktop file reads

Code: Select all

3. oolite.src modification.
Use the latest oolite.src after >2379 and perform the following modifications:
Modification 1:

Code: Select all

# Usage: ./oolite-trunk
Modification 2:

Code: Select all

if [ ! -f ~/.oolite-trunk-run ]
   touch ~/.oolite-trunk-run
4. oolite-update.src modification.
Don't care about this file.

5. oolite-trunk crashes when executed from shell.
Delete the "trunk/deps/Linux-x86-deps/oolite-deps/lib/*" files and copy in there the libraries installed by 1.72.2 package (/usr/lib/Oolite/oolite-deps/lib/*).
Use the latest default.apspec from >2379 and perform all the changes you have highlighted in your previous post.
Some more modifications are needed here:
Modification 1:

Code: Select all

SoftwareVersion: 1.73t #Put a 't' to indicate that you take it from trunk
Modification 2:

Code: Select all

echo "TOPLEVEL=$OOLITE_ROOT/Oolite-trunk" >> oolite-trunk 

Try these changes and send some feedback.

Posted: Fri Sep 04, 2009 10:16 pm
by Diziet Sma
Thanks Getafix! :D I'll give it a whirl this weekend..

Posted: Wed Sep 09, 2009 7:59 pm
by Getafix
Diziet Sma wrote:I'll give it a whirl this weekend..
Here follows some additional info you should consider, before trying
to install your oolite package in a system different than the one you
use to build oolite.

During the package creation, the system libraries are used to build the
oolite executable. However, these are NOT :!: the libraries distributed
to the end user, within the oolite package.

The oolite executable is distributed with the libraries stored in
"deps/Linux-x86-deps/oolite-dep/lib". When oolite package is installed,
these are the libraries which will be used.

If the "deps/Linux-x86-deps/oolite-dep/lib" libraries are not
the same (i.e or at least compatible) with your system's libraries, then
the oolite executable installed by the package will not be able to run.

The following setup:
"/usr/lib/libgnustep-base.so.1.14" (an ubuntu based system wide libgnustep-base installation)
will not generate a correct package. Because the oolite executable will
look for v1.14 (the one it was built with), while the package will have
distributed v1.12.

In that example you should do:

Code: Select all

cp /usr/lib/libgnustep-base.so.1.14 <your-oolite-folder>/deps/Linux-x86-deps/oolite-dep/lib/.
rm <your-oolite-folder>/deps/Linux-x86-deps/oolite-dep/lib/libgnustep-base.so.1.12
We have reached to the following minimum set of libraries which have to
be distributed within the package:
  • libavcall
  • libcallback
  • libdirect
  • libdirectfb
  • libfusion
  • libgnustep-base
  • libobjc
  • libpng
  • libSDL
  • libSDL_mixer
NOTE: In case you have any suggestion which could shorten this list,
I urge you to come forward and speak up!


Posted: Fri Sep 25, 2009 10:38 pm
by Getafix
@Diziet Sma
You may get the trunk autopackages, you wished, from here.
It will not mess your oolite test release installation. Read this post for more info.


Posted: Sat Sep 26, 2009 2:54 am
by Diziet Sma
Thank you, Getafix.. much appreciated.. :D 8)