|
Description
Matija "hook" Šuklje
2005-09-22 07:25:34 UTC
i saw it also, its sounds good and i second that request 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/ 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 Created attachment 72426 [details]
oolite-bin-1.55.1.ebuild
Enclosed is a working ebuild.
Created attachment 74126 [details]
oolite-bin-1.60.1_beta2.ebuild
Here is a more elegant ebuild. Plus version bump.
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. Created attachment 74135 [details]
oolite-bin-1.60.1_beta2.ebuild
Thanks - changes made as specified.
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.
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.
Created attachment 77177 [details]
oolite-bin-1.62.1_rc1.ebuild
Here's an ebuild with MY_PV tweaked for the latest beta.
New stable release on 29-Jan - rename the ebuild to oolite-bin-1.62.2.ebuild Created attachment 78488 [details]
oolite-bin-1.62.2.ebuild
Added dependencies for modular X.
Created attachment 80149 [details]
oolite-bin-1.62.3.ebuild
Stable version bump. Tidied dependencies. Added USE flag for replacement sounds.
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.
(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? ;-))))))))) 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. 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, 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.
(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. (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. What about writing an ebuild that compiles the game from sources, so it can be played on amd64 too? Created attachment 83703 [details]
oolite-bin-1.62.5.ebuild
Stable version bump. Added ~amd64 and new USE flags.
Created attachment 92651 [details]
oolite-bin-1.65.ebuild
Tidied ebuild, with version bump.
It is an opensource game. I really would be in favour of having an ebuild that compiles the stuff. (In reply to comment #24) > having an ebuild that compiles the stuff. Be my guest to finish the ebuild in comment #8. It would be great to have an ebuild that worked on amd64. I see this bug has been open for a while though :( Raphael 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. *** Bug 127338 has been marked as a duplicate of this bug. *** *** Bug 127335 has been marked as a duplicate of this bug. *** 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. 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?
Created attachment 121889 [details]
oolite-bin-1.66_beta1.ebuild
Fixed changed URL for kleptohud.
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 Created attachment 122127 [details]
oolite-bin-1.66_beta1.ebuild
Uses proper libxslt for amd64, hopefully.
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. Created attachment 126833 [details]
oolite-bin-1.69_beta1.ebuild
Version bump & fixes icon.
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 on attachment 126833 [details]
oolite-bin-1.69_beta1.ebuild
Broken link.
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.
Created attachment 139612 [details, diff]
requirement from 1.65-r1 ebuild - fixes 'shard_obj_dir' error
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
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.
Created attachment 140027 [details]
updated version with full install and desktop/menu entry
fixed typo... now it's working for sure :)
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
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. 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
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 :) 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.
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.
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!" :) 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. 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. 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. 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" :) 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 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).
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). 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. 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. (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. 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. oolite-1.72 released on berlios: http://developer.berlios.de/projects/oolite-linux/ (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) ;) 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 and we are now upto 1.72.2 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 you can use my live ebuild layman -a rion && autounmask =games-action/oolite-9999 && emerge oolite > 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
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. 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... I'm now running 1.75, you guys really should consider a case to stabilize this and get it into the official portage tree. updated ebuilds in the overlay. (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: 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 seems to be fixed. please resync Yep, nice one, Oolite now happily building. Thanks for sorting it out. bumped to oolite-1.85_alpha1 btw it does not inherit games eclass anymore. so repoman pretty much happy =) if anyone is still curious, 1.90 is in the overlay (In reply to Sergey Ilinykh from comment #79) > if anyone is still curious, 1.90 is in the overlay Thanks, I will try it. |
