Attached is quake2-0.14.1-ebuild.tar.bz2. This is the quake2 linux port done by relnev, centered at http://icculus.org/quake2/. It should probably go into app-games/quake2.
Created attachment 4066 [details] tarball of quake2-0.14.1.ebuild and other files this tarball contains: -Edited Makefile quake2/files/Makefile -Start scripts for the bin dir quake2/files/sdlquake2.start quake2/files/quake2.start quake2/files/q2ded.start -Readme for installing data and other bits quake2/files/README-postinstall -The ebuild quake2/quake2-0.14.1.ebuild What it does not contain: The data paks. Those you have to buy :)
nice, ill take a look at it after the 1.4 freeze ;)
instead of doing: tarball_version=`echo $P | sed -e 's/quake2-//'` name=quake2-r${tarball_version} S=${WORKDIR}/$name SRC_URI="http://icculus.org/quake2/files/$name.tar.gz" you can use the built in bash replacement: MY_P="${P/-/-r}" S="${WORKDIR}/${MY_P}" SRC_URI="http://icculus.org/quake2/files/${MY_P}.tar.gz"
also, now we use virtual/x11 for X
instead of using syntax like this: if (use sdl); then try this: if [ `use sdl` ] ; then the reason for this is that () executes a new copy of the bash shell and if you were to use statements in there like 'die', it would only affect that sub shell ... (die blah) would kill the subshell, not the main shell that is executing the ebuild
are you running Gentoo 1.4 ? you commented out the aalib section saying it didnt work for you, but when i uncommented it, it worked on my machine ...
No, I'm still using 1.2. Is there a way to test for the compiler version (other than the obvious gcc --version, of course)? Also, I've made the changes you suggested in my own tree, and I'm almost done with a 0.15 ebuild- i think I've figured out the qmax thing, so I'll attach a new tarball when i'm done.
Created attachment 4974 [details] quake2-0.14.1.ebuild (rewritten some what) here, check this for some suggestions ;)
*sigh* It looks like in the time it was just sitting on my computer, someone else DID make an ebuild. Heh. Well, mine (#9927) appears redudant now. I didn't think to look again before I submitted it (only, apparently, immediately after). Check it out for my approach. Will look at yours. ::)
*** Bug 9927 has been marked as a duplicate of this bug. ***
ah well i guess ill just add it and let users bitch about it ;) http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2/quake2-0.14.1.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup
Created attachment 5565 [details] .14.1 and .15 ebuilds, plus a makefile change from what's currently in portage Here's the newer stuff- all that's left is the QMAX build that I'm still kicking around. This contains: quake2-0.14.1.ebuild quake2-0.15.ebuild files/Makefile
done and might i add, if only all games had linux ports this fscking good http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2/quake2-0.15.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup
Hiya ::) I am still using my personal Quake 2 ebuild (which turned-out to be redundant). Well, an evolved version anyway. Here are some reasons why: 1. There are multiple Quake 2 source-ports, and there will be more. Refering to this one as simply "quake2" implies that it is The Official Quake 2. I suggest calling it "quake2-relnev" 2. Mine stores it's data in a source-port-independent location, and in a source-port-independent way. It does so using by keeping it's data seperately, in /usr/share/games/quake2-relnev and linking to the basic Quake 2 data in /usr/share/games/quake2-data. I finally just submitted my quake2-data ebuild, to pull the data off of CD or out of a user-specified location. 3. Style: I'm a snob, and prefer my way to yours. :;) I would say that the first two warrant changes, whether or not the third does is less clear. ::) I just submitted bug #11506 ( at http://bugs.gentoo.org/show_bug.cgi?id=11506), which installs the Quake 2 data from CD or otherwise. I think it would be good if this ebuild was slightly modified to use it. Try adding lines such as this to src_install(): # Now populate baseq2 with symlinks and source-port specific files dosym /usr/share/games/quake2-data/baseq2/pak0.pak /usr/share/games/quake2-relnev/baseq2/pak0.pak dosym /usr/share/games/quake2-data/baseq2/pak1.pak /usr/share/games/quake2-relnev/baseq2/pak1.pak dosym /usr/share/games/quake2-data/baseq2/pak2.pak /usr/share/games/quake2-relnev/baseq2/pak2.pak dosym /usr/share/games/quake2-data/baseq2/players /usr/share/games/quake2-relnev/baseq2/players dosym /usr/share/games/quake2-data/baseq2/video /usr/share/games/quake2-relnev/baseq2/video ... and the same for ctf, rogue, and xatrix sub-directories Are the gamei386.so files portable across source-ports (and redundant, rather than conflicting)? If so, one could just symlink baseq3 instead of the individual paks (any additional ones will need to be individually sym-linked by hand - not a big deal, but it would be nice if one didn't have to). Sorry, I was going to re-write the ebuild with most of my complaints fixed and attach it, but it is late and I wanted to at least mention my new quake2-data ebuild. I kept getting lost trying to modify the quake2 ebuild to change the things I had mentioned, and the result would have looked more like the one I already have than the one in Portage. If you want me to, I will attach mine after I incorporate changes from yours. I was not confident that all I USE flags would work in all cases. Which brings me to my last complaint for this comment ::) Why use a custom Makefile, when you can use sed to modify the existing one? It is more self-contained, using fewer Gentoo-specific downloads, and you don't have to replace the file and try to figure-out what you cut last-time when a new version comes-out. Counter-comments welcome ::) - Daniel Mannarino
ill look at these suggestions when i have time
Created attachment 6427 [details] quake2-relnev-0.15-r1.ebuild (A Slightly Different Approach) Okay, here's my attempt to merge the best of our ebuilds. - Daniel
Created attachment 6428 [details] files/sdlquake2-relnev.start Here's the script to start the sdl binary
Created attachment 6429 [details] files/quake2-relnev.start Here's the script to start the plain binary
Created attachment 6430 [details] files/q2ded.start And here's the dedicated server script
from e-mail: look into QMAX support
Ok, did the QMAX stuff. I don't mean to ignore your changes, Daniel, but I'm just going with what's currently in there. Some of your changes I agree with, some I don't. Just in response to your points, though: 1. Really, the only other port that could qualify for the "quake2" name without suffix is quakeforge's, but it's not really any better than this (and, actually, I'd say worse, just because of the mess they had to make to get it to use autoconf). There won't ever be an "official" quake2, per se, because the official one won't compile on linux :) 2. I did something much the same, except I made quake2-qmax depend on quake2, and left the data in /usr/share/games/quake2, then symlinked it. 3. eh :) To answer one of your lower questions, no, the game*.so isn't even compatible across compiles, heh. It breaks savegames if you recompile. Also, your point about sed vs a new Makefile is well taken, but I find sed code evil and ugly. More personal preference :) Anyway, this one installs a QMAX-version of quake2. It's set up to be installed in app-games/quake2-qmax. Data is symlinked from app-games/quake2, which this depends on, so that's good. Start scripts installed as <script>-qmax. Also, i patched the source to use $HOME/.quake2-qmax as the config dir, so it doesn't touch the normal quake2 config. None of the vid_ref drivers really appear to work except for sdlgl, but I left the X one in case I was just unlucky. Running sdlquake2-qmax will get you sdlgl by default, since softsdl doesn't seem to work either. Eh, YMMV. Test!
Created attachment 8872 [details] app-games/quake2-qmax-0.15 See comment above.
Hiya Actually, you know, I've been meaning (literally for weeks, yikes) to visit this again to say "Hi: I don't really remember what most of my changes did; it probably introduced new problems (even though it seems to work for me); yours seems to work fine anyway; just forget I posted :;)" There is only one change that I really feel strongly about, and that is the name. I think it should be quake2-relnev. The seperate quake2-data ebuild is perhaps a little much. Requiring manual sym-linking is probably not too much to ask of the user: It's too much space for me to have multiple Quake 2 data sets though. Making a QuakeForge 2 ebuild is going to require more ambition than I have at the moment (though the tarball is sitting amongst a pile of others I had intended to make ebuilds for in my home directory). qfusion I successfully compiled/ran, but it is somewhat confusing as to where it stands (based on Quake 2 source, but adds in many Quake 3 features, and uses Quake 3 data - actually requires Quake 3!). Anyway, I'm rambling now. I withdraw objections to this ebuild, except for the name. ::) -- Daniel Mannarino
Created attachment 12953 [details] Modified Makefile to the ${filesdir} This Makefile uses the CFLAGS from make.conf
Created attachment 12954 [details] Makefile which uses CFLAGS from make.conf Tested only on x86. RELEASE_CFLAGS could be merged into one linem because portage takes care of CFLAGS.
ok, it is now called quake2-revnel and has been totally reworked try the sob out :) oh and lets open problems with this ebuild as new bugs, danke http://cvs.gentoo.org/cgi-bin/viewcvs.cgi/gentoo-x86/app-games/quake2-revnel/quake2-revnel-0.15.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup
