The quake3-9999 has several issues; general ones with subversion and paxctl, specific ones depending on subversion revision. First problem is the workaround to incorporate the SVN revision into the build system. The Makefile issues a `svnversion` command when there is a '.svn' folder (look for the comment "Add svn version info"). To make this work, quake3-9999.ebuild:73 creates a symlink from '${ESVN_WC_PATH}/.svn' to the working directory. Using subversion-1.7.7 however, `svnversion` outputs 'Unversioned directory', which apperently breaks the build as well. Turns out subversion does not like the symlink svn: warning: W155007: '/var/tmp/portage/games-fps/quake3-9999/work/trunk' is not a working copy Just comment line 73 in the ebuild to continue for now. This will result in binaries which just have version '1.36' as opposed to e.g. '1.36_SVN2396'. Now the build fails due to usage of the 'OF' zlib macro, which was renamed to '_Z_OF' within Gentoo, see #383179 and https://bugs.icculus.org/show_bug.cgi?id=5521 for upstream bug. Edit line 83 of the ebuild to match 'append-flags ${CPPFLAGS} -DOF=_Z_OF'. I'm not entirely certain that this is the best fix. Now the build completes successfully, but `ioquake3` won't launch due to missing libraries. I don't quite remember the entire SVN history of ioquake3, but the with the current default make options (USE_RENDERER_DLOPEN=1) you get a ioquake3.* binary with separate renderer_*.* libraries. There is a opengl1 renderer, which is the same code as in id Quake 3. There is also an optional new renderer rend2 with make option BUILD_RENDERER_REND2=1 (see rend2-readme.txt for information). The renderer can be changed at runtime by setting the cvar 'cl_renderer' to 'opengl1' or 'rend2' respectively (e.g. open in-game console with shift+esc, type "/set cl_renderer rend2; vid_restart"). One can also choose to build separate binaries with integrated renders by setting USE_RENDERER_DLOPEN=0 (resulting in a new $(CLIENTBIN)_rend2$(FULLBINEXT) file for rend2, e.g. ioquake3_rend2.x86_64). When going with the separate render libraries approach, those files will need to be installed as well. Current ioquake3 code checks $PWD and BASEDIR (which defaults to ${GAMES_DATADIR}/quake3 in the ebuild). I would assume that users prefer the seperate renderer libraries approach (I for one would :) ). Last but not least the ioquake3.* and ioq3ded.* binaries need to `paxctl -m`ed to play well with the PaX patchset.
Created attachment 333884 [details, diff] Quick&dirty fixes to get ebuild running as described
Created attachment 333886 [details] Build log for subversion issue
Created attachment 333888 [details] Build log for zlib macro issue
Created attachment 333890 [details] Run log for missing renderer libraries issue
The new canonical source for ioquake3 is now Git at https://github.com/ioquake/ioq3 (see http://lists.ioquake.org/pipermail/ioquake3-ioquake.org/2013-January/004933.html for more info).
+ 03 Jan 2013; Sergey Popov <pinkbyte@gentoo.org> quake3-9999.ebuild: + Set new repo address for live ebuild, wrt bug #449510
+ 03 Jan 2013; Sergey Popov <pinkbyte@gentoo.org> quake3-9999.ebuild: + Add workarounds for zlib and renderers loading, wrt bug #449510. Thanks to + robo9k <robo+gentoo AT 9k.lv> for discovering these issues Unfortunately, this is not proper solution - ebuild should not install libraries into /usr/share. But, if understand source code properly, there can be only one basedir for loading pk3 files and other stuff(and it's already defined as "${GAMES_DATADIR}/${PN}"... So, this is just a dirty hack, but it works for me.
Created attachment 334274 [details, diff] Patch to load renderer from system libraries as well Disclaimer: untested
The game currently searches the directory of the binary and the BASEPATH, which is pre-defined to /usr/share/games/quake3 in the ebuild, but can be set by the user upon launch with e.g. `ioquake3 +set fs_basepath "/somewhere/else"` (e.g. to use the ioquake3 engine with other games). If you want to search the usual system libraries as well, you could apply the attached syslibrary patch. I'll post an improved version of the ebuild lateron, if you don't mind?
There's an upstream bug about FHS compliance, which would include our renderer library issue: https://bugzilla.icculus.org/show_bug.cgi?id=5767
this bug is out of date with the ebuild in portage. There might still be relevant issues but untangling them from this bug isn't ideal. file bugs for individual issues if any and we'll deal them them on a finer granularity.
