Oolite Bulletins

Fun times. Ubuntu Karmic has 1.19 as well as 1.16, and since oolite is the only thing I use GNUstep for, I'd rather not install both versions...

Should 1.19 work? The package I built from SVN just now is insisting on 1.16, but is that just because the box I built it on is 1.16?

I'd have thought the dependency would be >= 1.16, so is there some reason it's allergic to 1.19 or is there something I (and Getafix / dsalt please could tweak?

The dependency -is- >=1.16, but (one of) the dependant package names is libgnustep-base1.16 - so it's inherently restricted to 1.16 if you build on an older version of Ubuntu. Just the way they decided to name/package GNUstep I suppose.

Having just built Oolite on Karmic, it works fine compiling and running (briefly) under libgnustep-base1.19, so there shouldn't be an inherent problem with the newer gnustep libraries.

There was a problem reported on Slackware with gnustep 1.19.1:
https://bb.oolite.space/viewtopic.php?t=6823

but the same problem doesn't seem to exist in Karmic (gnustep 1.19.0).

Since 1.19.0 is an obsolete development version, and Oolite doesn’t have any particular use for it and hasn’t been tested with it, there is unlikely to be any advantage to using it.

Ahruman wrote:

Since 1.19.0 is an obsolete development version, and Oolite doesn’t have any particular use for it and hasn’t been tested with it, there is unlikely to be any advantage to using it.

Ah, so what replaces 1.19.x and is un-obsolete? If 1.19 is known bad I'd quite like to let the beta boys know!

Having just looked on the GNUstep website, the current stable release is 1.18.0, and the current development release is 1.19.3:

http://wwwmain.gnustep.org/resources/do ... ep%2F#core

TBH, I find it odd that Karmic Koala, being a Long Term Service release of Ubuntu, would choose to bundle development versions of upstream packages. If that is their policy, they might as well replace Oolite 1.65 with Oolite 1.73.x (or even 1.74(!)) as well ...

Exactly, Micha, we ask only for consistency!

I mean, if Ubuntu is going to do that, why don't I just use upstream debian? Where is the value-add?

why don't I just use upstream debian? Where is the value-add?

The value-add is that Ubuntu releases a heck of a lot more often than Debian (stable) - and hence has more up-to-date software which is important for your average desktop user. They also invested a large effort into making the Distro quite easy to use - not something I would claim of an out-of-the-box Debian install quite yet (although it certainly has improved as well) Debian OTOH has a very strong focus on releasing something stable for the long term.

That said, one of my desktop machines runs Debian Unstable, mostly for historical reasons (Ubuntu wasn't around when I initially installed it) and despite the name, tends to be more stable than other popular OS's. My server runs Debian stable - no need to run the latest & greatest on that, just something rock-solid.

I have gnustep-base 1.19.3 (gnustep-gui 0.17.1 and gnustep-make 2.2.0) running with Oolite on openSUSE 11.1 and Fedora 11 if that is helpful.

A rather lame reply to say that running gnustep-base 1.19.3 and gnustep-gui 0.17 didn't work well with saved games with an 'in progress' assignment such as UPS, or delivering cargo, or any other type of mission.

Loading a saved game with this information would result in a Cobra Mk III OXP not found, and that cobra3-player wasn't a valid ship. Deleting out the mission information from the savegame seemed to clear this error, but made missions a bit difficult

Reverting back to 1.18.0 and 0.16.0 respectively has it working as expected. This was tested on Fedora 11 x86_64 and openSUSE 11.1 i586 builds.

Thanks for the info!

And since no-one has mentioned it yet, welcome to the friendliest board this side of Riedquat too!

<off-topic> Thanks from an old time Acorn Electron player. Must have had the 1.0 release of Elite at the time - Galactic Hyperdrive never worked on it, and Acornsoft's recommendation was to load the save game on later released version on a BBC or the Electron and jump, and then play back on my Electron. I played for ages and never got beyond Dangerous - began to think that was a bug as well ... </off-topic>

Without wanting to tread on anyone's toes, I'm in the process of getting Oolite built for Fedora and openSUSE on the openSUSE Build Service. There's also another guy who has it building for openSUSE there as well. The theory being this should cater well for the non-Debian players.

jervine wrote:

A rather lame reply to say that running gnustep-base 1.19.3 and gnustep-gui 0.17 didn't work well with saved games with an 'in progress' assignment such as UPS, or delivering cargo, or any other type of mission.

Loading a saved game with this information would result in a Cobra Mk III OXP not found, and that cobra3-player wasn't a valid ship. Deleting out the mission information from the savegame seemed to clear this error, but made missions a bit difficult :)

Reverting back to 1.18.0 and 0.16.0 respectively has it working as expected. This was tested on Fedora 11 x86_64 and openSUSE 11.1 i586 builds.

I can replicate the problem with gnustep-base 1.19.3 on Slackware 13 x86_64, and confirm that reverting to 1.18.0 fixes it. I dug into it for a little while to make sure it wasn't a side effect of an Oolite bug, but it does appear to be a GNUstep problem to me.

(For what it's worth, the problem is that [OOShipRegistry shipInfoForKey] returns nil when it shouldn't, because [NSDictionary objectForKey] seems to be giving the wrong result. Looking for (e.g.) the "cobra3-player" key in _shipData yields nil, but manually creating an enumerator and hunting through the dictionary shows that it really is there. At that point I assumed GNUstep was broken and gave up.)

- Yet Another Jameson