Oolite & Lucid (Ubuntu 10.04)

Post by **Micha** » Tue May 04, 2010 5:45 pm

lucid apt-get lines are now active and builds for test/maint/trunk are online. Enjoy.

(Tested binaries on my laptop, works fine including audio. Laptop was upgraded from Karmic to Lucid (i386) a few days ago. NVidia 945GM gfx, Intel N10 audio)

Post by **Getafix** » Tue May 04, 2010 7:27 pm

Micha wrote:
...works fine including audio...

Does this apply to "Spoken Messages" too?

Post by **Micha** » Tue May 04, 2010 11:36 pm

Getafix wrote:
Micha wrote:
...works fine including audio...
Does this apply to "Spoken Messages" too?

Yes. espeak-support has been on by default for a while now for Debian packages (At least since 1.73.4)

tinker · Post by **tinker** » Sun May 23, 2010 10:52 am

I am having some serious problems getting anything to work correctly.

Using 10.4 64 bit I have tried repository install, package install and building from source with different problems for each method.

Install 1.73testing via repository I get esound support for the first time ever, but I cannot load any saved games as my ship is not available. As the oxp with the ship is installed and working and all the names matched I was a bit puzzled until I also noted in the log that it could not load "Missiles&Bombs.js" which is logical as the script is actually called "Missiles & Bombs.js". It seems the program installed from the repository is parsing file names incorrectly which also accounted for it not finding my ship.

Next I tried the 64bit autopackage and that worked OK including saved games but there is no esound support. I can at least play this version and if I was not aware that esound could work then I would not of missed it.

Next plan was to build from source but that turned out to be a problem using

Code: Select all

svn co -r2579 http://svn.berlios.de/svnroot/repos/oolite-linux/branches/1.73-maintenance/

I get a 504 Gateway Time-out.

I tried to check out trunk with the same error though I can access the page via a browser. As I need a trunk install to test some new oxp's the only option left was to try the repository trunk package. This turned out to have the same error as the testing package, no save games available possibly due to file name parsing errors.

In a fit of deseration I tried something silly I used

Code: Select all

svn checkout svn://svn.berlios.de/oolite-linux/trunk

note the main difference being checkout instead of co, and it worked I now have rev, 3397 and can get on with building it.

Post by **Micha** » Sun May 23, 2010 7:48 pm

Could you please post which OXP(s) you're using and having trouble with?

Also, which ship does your saved game have?

tinker · Post by **tinker** » Mon May 24, 2010 8:54 am

I do not think I am having problems with oxp's. I have over 50 loading and running with the autopackage install but that install does not have spoken messages, there are no options for voice on the setup page.

The debian package does have voice but will not load any saved game as it cannot find the ship, yellow ? of doom. The ship is a Fer de Lance rusty, originally from the rusties pack but I load it from Realistic Shipyards oxp.

The "Missiles & Bombs.js" error that I noticed when using the deb package is a part of Missiles & Bombs v2.4.oxp. The script is called by

Code: Select all

<string>Missiles & Bombs.js</string>

which is parsed by the deb version to "Missiles&Bombs.js" which is of course the wrong name, the autopakage install works OK. If I change the file name then I can get it to load in the deb version but, of course, then it does not work in the autopackage version. There is definitely a difference in the way names a parsed between the two.

I have since built a copy of trunk and that works exactly the same as the deb version, spoken message OK but no loading saved games.

I assume other people have used the deb installer OK which is leading me to think something I have in my box is the cause, though I have read other reports of not being able to load saved games.

Post by **Micha** » Mon May 24, 2010 5:39 pm

Thanks for the details.

Tracked down the bug and it is indeed inside GNUstep. Not much we can do about it in the short term except ask people to use the autopackage versions, which ships with an older version of the GNUstep libraries.

tinker · Post by **tinker** » Tue May 25, 2010 9:40 pm

Is this a problem specific to libgnustep-base.so.1.18?

My system has libgnustep-base.so.1.19 and .16 and I was wondering if it would be possible to drop either of these into the Linux-deps tree and build with them. This is probably too simple a solution I suspect, but I can see no other way to get a working trunk version to test some new oxp's.

Post by **Micha** » Tue May 25, 2010 10:50 pm

GNUstep base versions <= 1.19.1 and >= trunk (1.21.1) as of today are ok. Everything in between is broken.
You can certainly build a good custom libgnustep-base and install it in your system. Or use the version of gnustep shipped in the dependencies with the Oolite sources.

tinker · Post by **tinker** » Thu May 27, 2010 10:53 am

Micha wrote:
GNUstep base versions <= 1.19.1 and >= trunk (1.21.1) as of today are ok. Everything in between is broken.
You can certainly build a good custom libgnustep-base and install it in your system. Or use the version of gnustep shipped in the dependencies with the Oolite sources.

Are you sure of this? Perhaps I am doing something wrong, I svn updated trunk, rebuilt and have still got the same problem.

Post by **Micha** » Thu May 27, 2010 11:59 am

If you do:

Code: Select all

$ ldd oolite.app/oolite

what version of libgnustep-base is your Oolite binary linked against?

tinker · Post by **tinker** » Thu May 27, 2010 12:58 pm

I see it is not using the inbuilt deps one. I have

Code: Select all

 libgnustep-base.so.1.19 => /usr/lib/libgnustep-base.so.1.19 (0x00007f15f4315000)

but that should also work according your previous post.

Post by **Getafix** » Thu May 27, 2010 1:50 pm

@tinker
Please, post the result of the following:

Code: Select all

$ ls -l /usr/lib/libgnustep-base.so*

This will give us the gnustep sub-version.

tinker · Post by **tinker** » Thu May 27, 2010 2:49 pm

Now I see a problem

Code: Select all

lrwxrwxrwx 1 root root      23 2010-05-17 11:29 /usr/lib/libgnustep-base.so -> libgnustep-base.so.1.19
lrwxrwxrwx 1 root root      25 2010-05-14 15:59 /usr/lib/libgnustep-base.so.1.19 -> libgnustep-base.so.1.19.3
-rw-r--r-- 1 root root 4810800 2010-01-22 11:22 /usr/lib/libgnustep-base.so.1.19.3

Post by **Micha** » Thu May 27, 2010 3:06 pm

Sorry for the confusion - I failed to post the critical piece of info that Ubuntu Lucid comes, by default, with libgnustep-base 1.19.3.

My bad. I had posted it elsewhere and lost track of where I'd said what.