Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 106890 - Oolite - an open "remake" of Elite [ebuild request]
Summary: Oolite - an open "remake" of Elite [ebuild request]
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement with 3 votes (vote)
Assignee: Default Assignee for New Packages
URL: http://oolite-linux.berlios.de/
Whiteboard:
Keywords: EBUILD
: 127335 127338 (view as bug list)
Depends on: 127335 127337 127338 127340
Blocks:
  Show dependency tree
 
Reported: 2005-09-22 07:25 UTC by Matija "hook" Šuklje
Modified: 2018-12-03 12:57 UTC (History)
20 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
oolite-bin-1.55.1.ebuild (oolite-bin-1.55.1.ebuild,1.10 KB, text/plain)
2005-11-07 19:35 UTC, Paul Bredbury
Details
oolite-bin-1.60.1_beta2.ebuild (oolite-bin-1.60.1_beta2.ebuild,1.18 KB, text/plain)
2005-12-05 20:35 UTC, Paul Bredbury
Details
oolite-bin-1.60.1_beta2.ebuild (oolite-bin-1.60.1_beta2.ebuild,1.05 KB, text/plain)
2005-12-05 22:09 UTC, Paul Bredbury
Details
oolite-1.60.2_beta3.ebuild (broken) (oolite-1.60.2_beta3.ebuild,1.71 KB, text/plain)
2005-12-27 09:45 UTC, Paul Bredbury
Details
oolite-bin-1.60.2_beta3.ebuild (oolite-bin-1.60.2_beta3.ebuild,1.22 KB, text/plain)
2005-12-30 05:29 UTC, Paul Bredbury
Details
oolite-bin-1.62.1_rc1.ebuild (oolite-bin-1.62.1_rc1.ebuild,1.25 KB, text/plain)
2006-01-15 10:27 UTC, Paul Bredbury
Details
oolite-bin-1.62.2.ebuild (oolite-bin-1.62.2.ebuild,1.66 KB, text/plain)
2006-01-29 18:45 UTC, Paul Bredbury
Details
oolite-bin-1.62.3.ebuild (oolite-bin-1.62.3.ebuild,2.03 KB, text/plain)
2006-02-19 00:04 UTC, Paul Bredbury
Details
oolite-bin-1.64_beta1.ebuild (oolite-bin-1.64_beta1.ebuild,2.08 KB, text/plain)
2006-03-23 11:44 UTC, Paul Bredbury
Details
oolite-bin-1.62.5.ebuild (oolite-bin-1.62.5.ebuild,2.88 KB, text/plain)
2006-04-02 04:05 UTC, Paul Bredbury
Details
oolite-bin-1.65.ebuild (oolite-bin-1.65.ebuild,3.03 KB, text/plain)
2006-07-24 15:17 UTC, Paul Bredbury
Details
oolite-1.65.ebuild (oolite-1.65.ebuild,1.07 KB, text/plain)
2007-01-04 14:34 UTC, Alex Buell
Details
oolite-bin-1.66_beta1.ebuild (oolite-bin-1.66_beta1.ebuild,2.99 KB, text/plain)
2007-06-13 06:47 UTC, Paul Bredbury
Details
oolite-bin-1.66_beta1.ebuild (oolite-bin-1.66_beta1.ebuild,3.64 KB, text/plain)
2007-06-13 17:36 UTC, Paul Bredbury
Details
oolite-bin-1.66_beta1.ebuild (oolite-bin-1.66_beta1.ebuild,3.53 KB, text/plain)
2007-06-15 10:42 UTC, Paul Bredbury
Details
oolite-bin-1.69_beta1.ebuild (oolite-bin-1.69_beta1.ebuild,3.54 KB, text/plain)
2007-08-03 23:07 UTC, Paul Bredbury
Details
fixed-up source ebuild... the only part missing - install (oolite-1.65-r1.ebuild,1.25 KB, text/plain)
2007-12-30 06:32 UTC, Dmitry S. Makovey
Details
requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error (obj_dir_fix-1.65.patch,473 bytes, patch)
2007-12-30 06:33 UTC, Dmitry S. Makovey
Details | Diff
requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error (obj_dir_fix-1.65.patch,371 bytes, patch)
2007-12-30 09:02 UTC, Dmitry S. Makovey
Details | Diff
updated version with full install and desktop/menu entry (oolite-1.65-r2.ebuild,1.78 KB, text/plain)
2008-01-04 08:10 UTC, Dmitry S. Makovey
Details
updated version with full install and desktop/menu entry (oolite-1.65-r2.ebuild,1.78 KB, text/plain)
2008-01-04 08:18 UTC, Dmitry S. Makovey
Details
Fixed everything from comment #44 (oolite-1.65-r3.ebuild,1.51 KB, text/plain)
2008-01-04 21:32 UTC, Dmitry S. Makovey
Details
More cleanup as per comment #46 (oolite-1.65-r4.ebuild,1.37 KB, text/plain)
2008-01-04 23:08 UTC, Dmitry S. Makovey
Details
implemented changes suggested by gentoo-gnustep ML (oolite-1.65-r5.ebuild,1.32 KB, text/plain)
2008-01-04 23:42 UTC, Dmitry S. Makovey
Details
Figured out portable "cp" replacement to "tar" (oolite-1.65-r6.ebuild,1.24 KB, text/plain)
2008-01-05 00:15 UTC, Dmitry S. Makovey
Details
implemented ugly hack for DTDs (oolite-1.65-r7.ebuild,1.49 KB, text/plain)
2008-01-06 09:15 UTC, Dmitry S. Makovey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matija "hook" Šuklje 2005-09-22 07:25:34 UTC
A FOSS game very similar and true to the idea of Elite, a 3D space-simulation  
game. 
 
It would be a nice addition to portage :]
Comment 1 Andrew Wienecke 2005-09-30 21:30:29 UTC
i saw it also, its sounds good and i second that request
Comment 2 Samir van de Sand 2005-10-12 15:34:46 UTC
Hmm ...

I've just done some research on the developers website. They provide an
autopackage to install the game (including all dependencies).

http://download.berlios.de/oolite-linux/oolite-x86-installer-1.52-1.tar.gz

According the Gentoo Developement Guide autopackages should not be implemented
in portage, see
http://dev.gentoo.org/~plasmaroo/devmanual/ebuild-writing/functions/src_unpack/autopackage/
Comment 3 Wojciech Myrda 2005-10-15 14:03:08 UTC
Hmmm... Hmmm... Either I imagine things or on their site are also available
links for  building the game from the source, although they might not have been
there before, dont know.

http://download.berlios.de/oolite-linux/oolite-data-1.55-1.tar.gz
http://download.berlios.de/oolite-linux/oolite-src-1.55-1.tar.gz

Anyway I would join in aksing for the creation of an ebuild for the game.
Looking forward for seeing it in portage ;)

Regards
Comment 4 Paul Bredbury 2005-11-07 19:35:21 UTC
Created attachment 72426 [details]
oolite-bin-1.55.1.ebuild

Enclosed is a working ebuild.
Comment 5 Paul Bredbury 2005-12-05 20:35:09 UTC
Created attachment 74126 [details]
oolite-bin-1.60.1_beta2.ebuild

Here is a more elegant ebuild. Plus version bump.
Comment 6 Mr. Bones. (RETIRED) gentoo-dev 2005-12-05 21:25:51 UTC
Comments:

no need for sys-apps/sed
games goes last on inherit line
order top variables like the rest of the games ebuilds
no need for the pkg_postinst()

We'll probably pick this up after the beta.
Comment 7 Paul Bredbury 2005-12-05 22:09:26 UTC
Created attachment 74135 [details]
oolite-bin-1.60.1_beta2.ebuild

Thanks - changes made as specified.
Comment 8 Paul Bredbury 2005-12-27 09:45:29 UTC
Created attachment 75613 [details]
oolite-1.60.2_beta3.ebuild (broken)

Here is my aborted attempt at creating a source ebuild, if anyone is interested. GNUstep is a horror - it's much easier and faster to just install oolite-bin.
Comment 9 Paul Bredbury 2005-12-30 05:29:18 UTC
Created attachment 75792 [details]
oolite-bin-1.60.2_beta3.ebuild

I've added a line to remove unnecessary GNUstep library binaries that revdep-rebuild would otherwise moan about.
Comment 10 Paul Bredbury 2006-01-15 10:27:23 UTC
Created attachment 77177 [details]
oolite-bin-1.62.1_rc1.ebuild

Here's an ebuild with MY_PV tweaked for the latest beta.
Comment 11 Paul Bredbury 2006-01-29 17:33:40 UTC
New stable release on 29-Jan - rename the ebuild to oolite-bin-1.62.2.ebuild
Comment 12 Paul Bredbury 2006-01-29 18:45:03 UTC
Created attachment 78488 [details]
oolite-bin-1.62.2.ebuild

Added dependencies for modular X.
Comment 13 Paul Bredbury 2006-02-19 00:04:33 UTC
Created attachment 80149 [details]
oolite-bin-1.62.3.ebuild

Stable version bump. Tidied dependencies. Added USE flag for replacement sounds.
Comment 14 Paolo Pedroni 2006-03-23 10:57:45 UTC
I was trying to "extend" the ebuild to also cover amd64 systems (which need 32 bit versions of libxml, libxslt and libart_lgpl, see new bugs this one now depends upon), but I stumbled on a problem:
is there a way to specify different runtime dependancies depending on the architecture we're building for?
In oolite-bin's case the package has to depend on libsdl, sdl-gfx, sdl-image, sdl-mixer, etc. if built for x86, but on the corresponding emul-linux-x86 packages if built for amd64. How can one do that? Is it correct to do something like the following?

RDEPEND="x86? ( >=media-libs/libsdl-1.2.8-r1 )
	x86? ( >=media-libs/sdl-gfx-2.0.13-r1 )
	x86? ( >=media-libs/sdl-image-1.2.3-r1 )
	x86? ( >=media-libs/sdl-mixer-1.2.6 )
        amd64? ( >=app-emulation/emul-linux-x86-sdl-2.3 )
        amd64? ( app-emulation/emul-linux-x86-libxml2 )
        amd64? ( app-emulation/emul-linux-x86-libxslt )
        amd64? ( app-emulation/emul-linux-x86-libart_lgpl )
	x86? ( virtual/opengl )
	|| (
		(
			media-libs/mesa
			x11-libs/libX11
			x11-libs/libXau
			x11-libs/libXdmcp
			x11-libs/libXext )
		virtual/x11 )
        amd64? ( >= app-emulation/emul-linux-x86-xlibs )"

Forgive me if I've written something patently absurd, but I'm a real newbie as far as ebuilds go (but I'm willing to learn).

Thanks in advance.
Comment 15 Paolo Pedroni 2006-03-23 11:04:26 UTC
(In reply to comment #14)

I just checked the openoffice-bin ebuild and it looks like I was kinda right, now it's only a matter of getting someone to build the 32 bit libraries and cleaning up a bit, isn't it? ;-)))))))))
Comment 16 Paolo Pedroni 2006-03-23 11:13:24 UTC
One last thing for now: can someone add also bug #127335 to the dependancies? libSDL_gfx* libraries are not included in emul-linux-x86-sdl.
Comment 17 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-23 11:22:10 UTC
http://www.gentoo.org/proj/en/base/amd64/emul/emul-content.txt

See if the libraries you need are already in one of the emulation libs packages.

Anyway, you can put multiple dependencies in one block, 
Comment 18 Paul Bredbury 2006-03-23 11:44:56 UTC
Created attachment 82954 [details]
oolite-bin-1.64_beta1.ebuild

Here's a version bump to latest dev version, with a fix to MY_PN and change to filename.
Comment 19 Paolo Pedroni 2006-03-23 11:54:38 UTC
(In reply to comment #17)
> http://www.gentoo.org/proj/en/base/amd64/emul/emul-content.txt
> 
> See if the libraries you need are already in one of the emulation libs
> packages.

I checked and only libart_lgpl is already present (in emul-linux-x86-baselibs).
I thus closed bug #127340.

> 
> Anyway, you can put multiple dependencies in one block, 
> 

You mean something like:

RDEPEND="x86? ( >=media-libs/libsdl-1.2.8-r1
        >=media-libs/sdl-gfx-2.0.13-r1
        >=media-libs/sdl-image-1.2.3-r1
        >=media-libs/sdl-mixer-1.2.6
        virtual/opengl
        || (
                (
                        media-libs/mesa
                        x11-libs/libX11
                        x11-libs/libXau
                        x11-libs/libXdmcp
                        x11-libs/libXext )
                virtual/x11 ) )
        amd64? ( >=app-emulation/emul-linux-x86-sdl-2.3
        app-emulation/emul-linux-x86-libxml2
        app-emulation/emul-linux-x86-libxslt
        >=app-emulation/emul-linux-x86-xlibs )"

Thanks for your help.
Comment 20 Chris Gianelloni (RETIRED) gentoo-dev 2006-03-23 12:35:14 UTC
(In reply to comment #19)
> You mean something like:
<snip>

Yeah, exactly like that.  Except you put the final ")" in for x86, too.  We also tend to indent them, but that's not big deal and something we would do when we commit it.  Check out something like games-fps/quake3-bin for an example.
Comment 21 Cristiano Chiucchiolo 2006-04-01 22:46:50 UTC
What about writing an ebuild that compiles the game from sources, so it can be played on amd64 too?
Comment 22 Paul Bredbury 2006-04-02 04:05:09 UTC
Created attachment 83703 [details]
oolite-bin-1.62.5.ebuild

Stable version bump. Added ~amd64 and new USE flags.
Comment 23 Paul Bredbury 2006-07-24 15:17:45 UTC
Created attachment 92651 [details]
oolite-bin-1.65.ebuild

Tidied ebuild, with version bump.
Comment 24 Paul de Vrieze (RETIRED) gentoo-dev 2006-07-27 13:32:37 UTC
It is an opensource game. I really would be in favour of having an ebuild that compiles the stuff.
Comment 25 Paul Bredbury 2006-07-27 13:38:24 UTC
(In reply to comment #24)
> having an ebuild that compiles the stuff.

Be my guest to finish the ebuild in comment #8.
Comment 26 Raphael 2006-10-30 15:21:17 UTC
It would be great to have an ebuild that worked on amd64.  I see this bug has been open for a while though :(

Raphael
Comment 27 Chris Gianelloni (RETIRED) gentoo-dev 2006-10-31 05:10:38 UTC
Well, quite honestly, new ebuild requests generally are one of the things near the bottom of our TODO.  Our priorities (for the most part) are as follows:

- security bugs
- compile/runtime bugs
- version bumps
- new packages

Now, packages lower on the TODO do get done out of order, but usually only when one of the developers takes an interest in the package.  That isn't saying that the package won't be added to portage (otherwise, we'd WONTFIX it)... it just means that it might take a little while.  In the mean time, updating the ebuild in the bug *does* help as it shows that there is interest in the package from our users, which raises this package's priority in our "queue" of getting things done.
Comment 28 Simon Stelling (RETIRED) gentoo-dev 2006-12-14 13:22:13 UTC
*** Bug 127338 has been marked as a duplicate of this bug. ***
Comment 29 Simon Stelling (RETIRED) gentoo-dev 2006-12-14 13:26:16 UTC
*** Bug 127335 has been marked as a duplicate of this bug. ***
Comment 30 Alex Buell 2007-01-04 13:53:25 UTC
I'm currently working on a source ebuild, watch this space as I will upload an attachment once it's done. This source ebuild will automatically install GNUstep for you if not already done. 
Comment 31 Alex Buell 2007-01-04 14:34:03 UTC
Created attachment 105427 [details]
oolite-1.65.ebuild

This ebuild will automatically build and install GNUstep environment if not already installed, then download and build Oolite for you. Only thing it doesn't do yet is installing the game itself. I'm still debating whether this ebuild ought to be in GNUstep-games so that it can work off the GNUstep eclasses already included in the portage tree. Thoughts, anyone?
Comment 32 Paul Bredbury 2007-06-13 06:47:07 UTC
Created attachment 121889 [details]
oolite-bin-1.66_beta1.ebuild

Fixed changed URL for kleptohud.
Comment 33 Paul Bredbury 2007-06-13 17:36:33 UTC
Created attachment 121952 [details]
oolite-bin-1.66_beta1.ebuild

Grabs libart and libxslt 32-bit libs from Debian for amd64, so amd64 should work now hopefully. Discussion:

http://forums.gentoo.org/viewtopic-t-411004.html
Comment 34 Paul Bredbury 2007-06-15 10:42:25 UTC
Created attachment 122127 [details]
oolite-bin-1.66_beta1.ebuild

Uses proper libxslt for amd64, hopefully.
Comment 35 Stephen Bridges 2007-08-03 16:17:13 UTC
I thought I'd test this but fetching files for oolite-bin-1.66_beta1.ebuild failed as "File oolite-1.66-dev1-data.tar.gz doesn't exist".  Renaming to oolite-bin-1.69_beta1.ebuild did it, if the doicon line is commented out.
Comment 36 Paul Bredbury 2007-08-03 23:07:19 UTC
Created attachment 126833 [details]
oolite-bin-1.69_beta1.ebuild

Version bump & fixes icon.
Comment 37 Dmitry S. Makovey 2007-12-28 06:50:57 UTC
Due to re-shuffling on oolite's site line:

ALIOTH="ftp://ftp.alioth.net/oolite"

should be fixed as follows:

ALIOTH="ftp://ftp.alioth.net/oolite/src"
Comment 38 Paul Bredbury 2007-12-28 10:46:13 UTC
Comment on attachment 126833 [details]
oolite-bin-1.69_beta1.ebuild

Broken link.
Comment 39 Dmitry S. Makovey 2007-12-30 06:32:12 UTC
Created attachment 139611 [details]
fixed-up source ebuild... the only part missing - install 

I played around with ebuild a bit and fixed up some glaring errors and things that prevented it from building on my AMD64 box.

This one is still missing install (have no time to work on it right away, but maybe somebody else is interested in finishing it up? Otherwise I might come back fix the rest in a new year.
Comment 40 Dmitry S. Makovey 2007-12-30 06:33:38 UTC
Created attachment 139612 [details, diff]
requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error
Comment 41 Dmitry S. Makovey 2007-12-30 09:02:12 UTC
Created attachment 139613 [details, diff]
requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error

previous patch contained bad path's. this one has them fixed
Comment 42 Dmitry S. Makovey 2008-01-04 08:10:00 UTC
Created attachment 140023 [details]
updated version with full install and desktop/menu entry

I've finalized as much as I could the ebuild if somebody feels like fixing it any further please do so or let me know. It works for me now on my AMD64 box.
Comment 43 Dmitry S. Makovey 2008-01-04 08:18:15 UTC
Created attachment 140027 [details]
updated version with full install and desktop/menu entry

fixed typo... now it's working for sure :)
Comment 44 Mr. Bones. (RETIRED) gentoo-dev 2008-01-04 20:56:26 UTC
Some comments:

It looks very suspicious to me that the sdl deps are on needed for x86.

virtual/x11 should go away - it doesn't exist anymore

move the closing " up to the end of the deps to match the style of all the other ebuilds.

sort KEYWORDS

remove the second, commented-out inherit line

quoting for $S, $D, $FILESDIR

cd ${S} is unnecessary

-p is unnecessary for dodir

remove the chgrp and chmod in src_install

call prepgamesdirs at the end of src_install

create "${T}/oolite" in src_unpack and just install it in src_install

s/&/and/ in DESCRIPTION

just call egnustep_env once in src_unpack
Comment 45 Dmitry S. Makovey 2008-01-04 21:32:29 UTC
Created attachment 140128 [details]
Fixed everything from comment #44

(In reply to comment #44)
> Some comments:
> 
> It looks very suspicious to me that the sdl deps are on needed for x86.

true - never bothered to check there. fixed now.

> virtual/x11 should go away - it doesn't exist anymore

gone. list of dependencies is simplified now and should cover basic needs of package

> move the closing " up to the end of the deps to match the style of all the
> other ebuilds.

done

> sort KEYWORDS

done (although I think there's ppc build possible - have no hardware to test)

> remove the second, commented-out inherit line
> quoting for $S, $D, $FILESDIR
> cd ${S} is unnecessary
> -p is unnecessary for dodir
> remove the chgrp and chmod in src_install
> call prepgamesdirs at the end of src_install
> create "${T}/oolite" in src_unpack and just install it in src_install
> s/&/and/ in DESCRIPTION
> just call egnustep_env once in src_unpack

all above - done. Is there anything else to clean up to make it suitable for inclusion in portage?

P.S.
Thanks for input.
Comment 46 Mr. Bones. (RETIRED) gentoo-dev 2008-01-04 22:15:01 UTC
no need for the dodir for GAMES_BINDIR in src_install

use dogamesbin instead of cp for the executable install in src_install

use newicon to install the icon instead of specifying the full path for the desktop entry.

remove pointless quotes on the S= line

put RDEPEND first and just reference ${RDEPEND} in DEPEND

create "${T}/oolite" in src_unpack
Comment 47 Dmitry S. Makovey 2008-01-04 23:08:19 UTC
Created attachment 140133 [details]
More cleanup as per comment #46

fixed missing opengl dependency and cleaned up ebuild some more as per comment #46 and then some. Seems to be lean and clean now. 

Open for comment suggestions as usual :)
Comment 48 Dmitry S. Makovey 2008-01-04 23:42:14 UTC
Created attachment 140137 [details]
implemented changes suggested by gentoo-gnustep ML

masked ebuild by default with ~x86 and ~amd64 . cleaned up some GNUstep calls as per gentoo-gnustep suggestions. Except for usage of tar - "cp -pr" doesn't work on platforms like FreeBSD, Mac OS X etc. however package should build on those platforms (I have no access to any of those at the moment) so removing tar will decrease portability. Tar is needed for unpacking of sources anyway so it doesn't produce any "extra" dependency and as such I would like keep it intact.
Comment 49 Dmitry S. Makovey 2008-01-05 00:15:14 UTC
Created attachment 140141 [details]
Figured out portable "cp" replacement to "tar"

now tar is gone too as it turns out FreeBSD ported functionality from GNU cp into their cp with only difference of "-r/-R". build now reflects that.
Comment 50 Hypnos 2008-01-05 07:42:29 UTC
Good work!  I just tested it on x86, and seems to work well.  A few minor things left:

* The desktop entry doesn't show up in my GNOME menu, because the desktop file created doesn't have any categories.  The reason is that the "make_desktop_entry" procedure doesn't recognize the Portage path "gnustep-apps/oolite", so gives nothing for the category.  You need to pass an additional type parameter like "Game" to the procedure.  (If you don't know what the hell I'm talking about, read the "make_desktop_entry" procedure yourself in the eutils eclass.)

* The tar dependency is no longer needed.

* I know you inherited the gnustep-base eclass to evade the gnustep-gui dependency through gnustep-back-art, but the eclass says specifically that it is only to be used internally by other gnustep eclasses.  If there is any future breakage due to this, a gnustep dev will say "I told you so!"  :)
Comment 51 Mr. Bones. (RETIRED) gentoo-dev 2008-01-05 07:52:06 UTC
The package wouldn't be gnustep-apps/oolite it would probably be something like games-action/oolite so the desktop entry would work as expected.
Comment 52 Hypnos 2008-01-05 08:07:33 UTC
One more small but annoying thing:

Most of the plists in oolite reference an external DTD at apple.com.  This might be an artifact of oolite being developed on OSX/Xcode.  In any event, the plist tools which come with gnustep-base-0.14 can't handle it.  So, every time make_services is run, it spits out an error message.  Because of gnustep-make's scripts in /etc/profile.d, this is every time /etc/profile gets sourced; in my case, every time I load a new shell.

The solution on the Gentoo end would be to strip out those <!DOCTYPE ...> tags, as they seem unnecessary.  It would be easier to fix upstream.
Comment 53 Dmitry S. Makovey 2008-01-06 02:58:34 UTC
As for <!DOCTYPE ...> tags - it seems there's an error in make_services - it does download appropriate DTD but it downloads it into current directory however expects it in /tmp/ which well, smells like a bug if you ask me but it's a gnustep bug rather than oolite. This probably should be solved in gnustep eclasses - making <!DOCTYPE > sanitation "automatic" as it will produce errors with other XML plists as well - I'm 100% sure. Either that or fix make_services upstream (I wonder what's going to happen if machine is offline and DTD is un-fetch'able). Generic "strip" doesn't seem like a bad idea in that case.

as for category entry - yes, I filed it on my system under games-simulation (which might not be the final destination for it) and it does work under KDE (sorry - can't atest for GNOME as I have none around).

dependency on gnustep-2 is gone since it produced nasty side-effect of make_services crapping up on each and every login session on that machine (however if somebody merges gnustep-gui for whatever reason - it'll resurface again). also inheriting gnustep-base does produce only the necessary library dependancies rather then pulling in things that are not needed (Gentoo's "minimalistic" philosophy kicks in ;) ). In other words if at some point inheriting gnustep-base will break the fix is a simple replacement with "inherit gnustep-2". Would be nice if gnustep crowd produced some superset safe to use on top of gnustep-base without all those pesky deps from gnustep-2. Oolite is a game and doesn't use anything but the gnustep-base && gnustep-make.

Comment 54 Dmitry S. Makovey 2008-01-06 03:12:36 UTC
just confirmed - if make_services is run from under /tmp - <!DOCTYPE ...> is not a problem anymore as long as you have internet connectivity. So part of fix would be to write a wrapper for make_services which would "cd /tmp" before launching it, or just use that trick every time make_services is automatically launched.

Can't figure out if we could maybe fetch DTD and install it locally notifying make_services to pick it up locally rather then remotely... But that's out of my league - ObjC is not my "can of soup" :)
Comment 55 Hypnos 2008-01-06 05:18:05 UTC
This looks like an upstream bug.  I'm moving to the opposite side of the planet tomorrow, so I won't be able to look into this for a while.

You might want to hit up the #gnustep channel on freenode.net

This link might be useful as well:

http://www.aegidian.org/bb/viewtopic.php?t=3314
Comment 56 Dmitry S. Makovey 2008-01-06 09:15:24 UTC
Created attachment 140261 [details]
implemented ugly hack for DTDs

Implemented ugly hack for DTDs so that they don't refer to Apple but to GNUStep DTDs which seems to quiet down make_services, however I do not think it's was the right thing to do (make_services is the one failing here - not oolite).
Comment 57 Dmitry S. Makovey 2008-01-06 09:18:28 UTC
I have somewhat working version of ebuild for 1.70, however 1.70 is "devel" version and ebuild is rather ugly (don't think it's possible to fix until upstream normalizes 1.70). Should I post ebuild for 1.70 here or open another bug? Maybe it should go as oolite-dev? (I implemented is as a slot for now though).
Comment 58 Hypnos 2008-01-10 05:48:32 UTC
Maybe a dev can help here.  My guesses:

* Leave the hack in the ebuild (or better yet, create a patch for the oolite source tree), file an upstream bug, then note the GNUstep bug number in the ebuild where you are applying the patch.

* Forget about oolite-dev -- if it's too hard to maintain an ebuild because it changes upstream, or the game doesn't even work right, it'll never make it into the tree.
Comment 59 Dmitry S. Makovey 2008-01-18 08:52:42 UTC
just a quick update:

* submitting upstream is going to be tough as the game itself has "broken" DTDs (according to GNUStep, but not according to me ;), but all add-ons come with the same level of brokedness... if game ever made it into portage - adding it's add-ons there would reintroduce the problem

* I ended up running "dev" version myself and so far it's been pretty stable. So the biggest problem with it is mostly messy ebuild (it includes hardcoded paths to spidermonkey's header files - picked up recipe on forums: http://aegidian.org/bb/viewtopic.php?p=42188&highlight=#42188 ). I did not see any way to fix it though, other then just implement.
Comment 60 Vitaliy V. Osypenko 2008-02-02 12:44:16 UTC
(In reply to comment #57)
> I have somewhat working version of ebuild for 1.70, however 1.70 is "devel"
> version and ebuild is rather ugly (don't think it's possible to fix until
> upstream normalizes 1.70). Should I post ebuild for 1.70 here or open another
> bug? Maybe it should go as oolite-dev? (I implemented is as a slot for now
> though).
> 

Post it please, anywhere ;o), I'm using amd64 gentoo and installing of a dev binary package doesn't work. And I don't want to run it under wine.
Comment 61 Dmitry S. Makovey 2008-02-18 07:17:43 UTC
I've tarballed all my ebuilds and posted it here: http://www.makovey.net/my_projects/oolite-ebuilds.tgz for those interested in 1.70 and also for those lazy to download patches separately etc. etc. etc.
Comment 62 Azamat H. Hackimov 2008-11-23 16:19:54 UTC
oolite-1.72 released on berlios:
http://developer.berlios.de/projects/oolite-linux/
Comment 63 Dmitry S. Makovey 2008-11-24 00:11:15 UTC
(In reply to comment #62)
> oolite-1.72 released on berlios:

thanks. I'll take a look at it. I don't have any timelines though (on when to make ebuilds) ;)
Comment 64 Robert Rankin 2009-03-19 22:26:47 UTC
1.70 builds but fails to run with 

/usr/games/bin/oolite17: line 2: openapp: command not found

Hopefully we will have a new ebuild out soon
Comment 65 Robert Rankin 2009-03-19 22:28:04 UTC
and we are now upto 1.72.2
Comment 66 Dmitry S. Makovey 2009-03-20 01:52:19 UTC
Re Comment#64

# which openapp
/usr/GNUstep/System/Tools/openapp

# epm -qf /usr/GNUstep/System/Tools/openapp
gnustep-make-2.0.6
# equery depends gnustep-make
[ Searching for packages depending on gnustep-make... ]
gnustep-base/gnustep-base-1.16.3 (>=gnustep-base/gnustep-make-2.0)

as you can see openapp should be there if gnustep-base is installed. 

if it's an issue of PATH being not set check out your /etc/env.d/99gnustep :

PATH=/usr/GNUstep/System/Tools:/usr/GNUstep/Local/Tools

Re Comment #65

I've uploaded new package with all ebuilds:

http://www.makovey.net/my_projects/oolite-ebuilds-1.72.2.tgz

with ebuilds from the bundle above I was able to build and run 1.72.2 just fine (sorry - too lazy to do screenies to prove ;) )

enjoy
Comment 67 Sergey Ilinykh 2009-07-10 08:54:05 UTC
you can use my live ebuild
layman -a rion && autounmask =games-action/oolite-9999 && emerge oolite
Comment 68 Alex Buell 2009-09-21 18:47:35 UTC
> layman -a rion && autounmask =games-action/oolite-9999 && emerge oolite

@Rion:

I tried doing the above with the rion overlay but it didn't work. Any ideas why? I did add the rion overlay, and oolite is definitely in /usr/local/portage/layman/rion. I keep getting this: 

 autounmask version 0.27 (using PortageXS-0.02.09 and portage-2.1.6.13)

 * Using repositories:
     /usr/portage
     /usr/local/portage

 * The given category/package-version does not seem to exist. Listing existing versions:

 * gentoo (/usr/portage):
     none

 *  (/usr/local/portage):
     none
Comment 69 Paul de Vrieze (RETIRED) gentoo-dev 2009-09-30 20:03:53 UTC
Alex, you will need to source your layman make.conf file in your own make.conf file at /etc/make.conf. The layman make.conf file is normally at /usr/local/portage/layman/make.conf. When installing layman, it will also warn you about this.
Comment 70 Alex Buell 2009-09-30 20:15:54 UTC
Yeah, thanks, turned out to be a missing source command in make.conf, I'm quite happily playing Oolite now. Now if only it could go into the Portage tree...
Comment 71 Alex Buell 2010-11-25 19:29:11 UTC
I'm now running 1.75, you guys really should consider a case to stabilize this and get it into the official portage tree. 
Comment 72 Sergey Ilinykh 2011-03-28 06:21:21 UTC
updated ebuilds in the overlay.
Comment 73 Alex Buell 2011-03-28 14:54:44 UTC
(In reply to comment #72)
> updated ebuilds in the overlay.

Unfortunately, oolite-9999 fails to build due to this:

# emerge oolite
Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) games-action/oolite-9999 from rion
 * firefox-4.0.source.js-only.tbz RMD160 SHA1 SHA256 size ;-) ...                                                            [ ok ]
 * Package:    games-action/oolite-9999
 * Repository: rion
 * Maintainer: rion4ik@gmail.com
 * USE:        elibc_glibc kernel_linux userland_GNU x86
 * FEATURES:   preserve-libs sandbox splitdebug
>>> Unpacking source...
>>> Unpacking firefox-4.0.source.js-only.tbz to /var/tmp/portage/games-action/oolite-9999/work
 * subversion update start -->
 *      repository: svn://svn.berlios.de/oolite-linux/trunk
U    installers/posix/make_installer.sh
U    installers/posix/setup.body
Updated to revision 4496.
 *    working copy: /usr/portage/distfiles/svn-src/oolite/trunk

>>> Source unpacked in /var/tmp/portage/games-action/oolite-9999/work
>>> Preparing source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999 ...
 * apply patches -->
 * Applying oolite-gentoo.patch ...                                                                                          [ ok ]

>>> Source prepared.
>>> Configuring source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999 ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999 ...
make -j2 -f Makefile release 
make -f libjs.make debug=no
make[1]: Entering directory `/var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999'


Configuring Javascript library...

cd deps/Cross-platform-deps/mozilla/js/src/build-release && ../configure --disable-shared-js --enable-threadsafe --with-system-nspr --disable-tests --enable-trace-jscalls
Updating Javascript sources...
/bin/sh: line 0: cd: deps/Cross-platform-deps/mozilla/js/src/build-release: No such file or directory

cd deps/Cocoa-deps/scripts && ./update-mozilla.sh
make[1]: *** [deps/Cross-platform-deps/mozilla/js/src/build-release/config_stamp] Error 1
make[1]: *** Waiting for unfinished jobs....
libjs is up to date.
mkdir -p deps/Cross-platform-deps/mozilla/js/src/build-release
make[1]: Leaving directory `/var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999'
make: *** [LIBJS] Error 2
emake failed
 * ERROR: games-action/oolite-9999 failed (compile phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  56:  Called src_compile
 *   environment, line 2499:  Called die
 * The specific snippet of code:
 *       emake -f Makefile $(use debug && echo debug || echo release) || die
 * 
 * If you need support, post the output of 'emerge --info =games-action/oolite-9999',
 * the complete build log and the output of 'emerge -pqv =games-action/oolite-9999'.
 * This ebuild is from an overlay named 'rion': '/var/lib/layman/rion/'
 * The complete build log is located at '/var/tmp/portage/games-action/oolite-9999/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/games-action/oolite-9999/temp/environment'.
 * S: '/var/tmp/portage/games-action/oolite-9999/work/oolite-dev-source-9999'

>>> Failed to emerge games-action/oolite-9999, Log file:
Comment 74 Sergey Ilinykh 2011-03-28 16:00:27 UTC
Ah, parallel build issue. I'll try to fix it.
but for now as workaround use MAKEOPTS="-j1" in your make.conf
in the worst case I'll insert -j1 right into ebuild
Comment 75 Sergey Ilinykh 2011-03-28 18:30:42 UTC
seems to be fixed. please resync
Comment 76 Alex Buell 2011-03-28 20:21:59 UTC
Yep, nice one, Oolite now happily building. Thanks for sorting it out.
Comment 77 Sergey Ilinykh 2017-03-05 18:58:28 UTC
bumped to oolite-1.85_alpha1
Comment 78 Sergey Ilinykh 2017-03-05 19:23:01 UTC
btw it does not inherit games eclass anymore. so repoman pretty much happy =)