$summary
The build of this version in the overlay fails to build because of something with python. please check it.
Created attachment 336676 [details] games-fps/doomsday-1.9.10.ebuild This is the ebuild from my own overlay (paddymac). I'm not sure if this is the same one you tried, but it works great for me. Also please note that, if you enable the FMOD use flag, you'll need a newer version of FMOD than is currently in Portage. See bug 453748. If you still have trouble, post your error message.
Created attachment 336678 [details, diff] doomsday-1.9.10-driver_openal.cpp.patch
Created attachment 336680 [details, diff] doomsday-1.9.10-threadsafe.patch
Created attachment 336682 [details] metadata.xml
I also used the version from your overlay. this is the only version which exist for gentoo actually. but it fails.
Is failing emerge your ebuild a result of a wrong fmod version?!?
An unsuitable version of FMOD will only cause a build failure *if* the FMOD use flag is enabled, but that shouldn't happen because the ebuild has a minimum version requirement to ensure a suitable version of FMOD is installed. Please attach the appropriate log(s) and/or post the exact error message you're getting in order to provide sufficient information to address the issue.
Created attachment 336824 [details] Emerge failed outout. [ebuild U ] games-fps/doomsday-1.9.10::paddymac [1.9.8::gentoo] USE="doom heretic hexen openal sdl%* snowberry tools%* -debug% -demo -fluidsynth% -fmod% -freedoom -resources" 0 kB I always see "syntax error" i think it has something to do wih python. see attachment for part of the output.
Created attachment 336850 [details] games-fps/doomsday-1.9.10.ebuild The only error I discovered in the ebuild was a typo which caused the tools use flag to not work, but this was only responsible for a small QA error message. I'm attaching an ebuild which fixes that small issue. However, I was able to reproduce the more significant error message you were getting by switching my system python interpreter to 3.2. My current recommendation is to use 'eselect python' to at least temporarily switch your active system python interpreter to 2.7 so that you can successfully emerge Doomsday. You'll probably have to use Python 2.7 in order to use the Snowberry front-end as well. I'll look at this further to see what else can be done about the matter.
yes ok. but i think the right way would be to explicitly use only the 2.x python with this ebuild. in eselect python i can set defaults for python 2 and python 3. you should change the ebuild to use the python 2 slot binary. or better set the ebuild in such a way that the sintax is compatible with python 3. or better python 2 and 3 at least.
I also think that python 3 is now the default if you new install gentoo. so maybe you should set a info message in he ebuild or block the package if you have set the wrong python version.
python eclass is in deprecation phase and should not be used any longer use one of: distutils-r1 (distutils packages) python-r1 (non-distutils packages supporting multiple abi) python-single-r1 (non-distutils packages not supporting multiple abi) python-any-r1 (mostly for packages that only need python during build-time) see: http://www.gentoo.org/proj/en/Python/python-r1/dev-guide.xml https://wiki.gentoo.org/wiki/Python-r1 https://wiki.gentoo.org/wiki/Python-r1/examples also eclass manpages: http://devmanual.gentoo.org/eclass-reference/distutils-r1.eclass/index.html http://devmanual.gentoo.org/eclass-reference/python-r1.eclass/index.html http://devmanual.gentoo.org/eclass-reference/python-single-r1.eclass/index.html http://devmanual.gentoo.org/eclass-reference/python-any-r1.eclass/index.html
Created attachment 336868 [details] games-fps/doomsday-1.9.10.ebuild This new ebuild along with the accompanying patch should fix the issue. The eclass doesn't really help much, although I did switch to python-single-r1.eclass. There is a variable which can be set called SCRIPT_PYTHON, but the only thing this determines is the path to the python binary in the launch-doomsday script for Snowberry; I set the variable to /usr/bin/python2. There are 4 files in the build system which simply call "python" and therefore use the system default interpreter. The patch simply changes these references to "python2". I also realized that the ebuild was installing two menu entries for Snowberry, so I removed the redundant entry. Thanks to KuriKai in #doomsday for helping me with this.
Created attachment 336870 [details] doomsday-1.9.10-python_build.patch
I think we should skip this release, it has startup problems and game freezes (after fixing the startup problems)
Created attachment 338126 [details] doomsday-9999.ebuild for those impatient people here is a live ebuild
the game is working fine for me if i only change python 2.x to default before emerging it. after changing back to 3.x the gameplay as stable as the versions before. no freezes on my pc. big thanks!
(In reply to comment #18) > the game is working fine for me if i only change python 2.x to default > before emerging it. that is no longer needed.
You didn't describe the crash that you experienced. If you experienced a bug involving errors like "QEglContext::swapBuffers(): "Bad surface (0x300D)"", that may not be a Doomsday bug (I'm not certain). It might be an issue with QT because there is a similar issue with stellarium (see bug 438848). If that bug is experienced, recompile qt-gui and qt-opengl with the "egl" USE flag disabled.
Your help is unwelcome. Further version bump requests from you will result in devrel requests.
(In reply to comment #20) > You didn't describe the crash that you experienced. If you experienced a bug > involving errors like "QEglContext::swapBuffers(): "Bad surface (0x300D)"", > that may not be a Doomsday bug (I'm not certain). It might be an issue with > QT because there is a similar issue with stellarium (see bug 438848). If > that bug is experienced, recompile qt-gui and qt-opengl with the "egl" USE > flag disabled. nope, the bug is here http://sourceforge.net/p/deng/bugs/1105/
