Hi, here is a brand-new ebuild for uhexen2, which is a game engine descended from Hexen 2. It is capable of playing the original Hexen 2 game and the "Portal of Praevus" mission pack, using some of the data files from the game CDs. Homepage: http://uhexen2.sourceforge.net/ Although the ebuild works, there are some issues: * uhexen2 requires that the data files in /usr/share/games/hexen2/data1/ be pre-patched to a version >=1.1, which in Linux requires the script "update_h2" found in hexen2-1.3.0-linux.i586.tgz at http://sourceforge.net/project/showfiles.php?group_id=124987&package_id=136554 * Midi playback, which is only available via timidity, has not been heard to work. This is a problem with uhexen2 rather than the ebuild.
Created attachment 68340 [details] games-fps/uhexen2/uhexen2-1.3.0.ebuild
Oops, my "1.1" should be "1.11", as reported at http://forums.gentoo.org/viewtopic-p-2721523.html
The midi problems were caused by bug 99590 - emerge =sdl-mixer-1.2.6 without the "mikmod" USE flag fixes the music.
Created attachment 72902 [details, diff] UHexen2 Ebuild Patch for AMD64 compile I submit a patch for this ebuild; it permitts to compile the source on AMD64 platforms. I hope it helps x86_64 users :) (Sorry for my bad english)
Created attachment 80515 [details] uhexen2-1.3.0.ebuild Here is a tidied ebuild for modular X, including the above patch.
Created attachment 85626 [details] Ebuild for UHexen2-1.3.1
Comment on attachment 85626 [details] Ebuild for UHexen2-1.3.1 I have attached a revisited ebuild (added some check for multilib compiling) with the new version of the package (1.3.1)
Created attachment 85671 [details] uhexen2-1.4.0.ebuild New version released.
Created attachment 90927 [details] uhexen2-1.4.0.ebuild Big tidyup, and integration with hexen2-demodata to play the demo maps.
Created attachment 90928 [details] uhexen2-1.4.0.ebuild Changed 1.1 to 1.11 in the einfo about patching the data files. Moved ${opts} to start of emake command, as stated in the Makefile.
Created attachment 90933 [details] uhexen2-1.4.0.ebuild Relaxed the filepath search restrictions on the demo version, for it to be able to find and use the demo data's coloured lighting.
Created attachment 90945 [details] uhexen2-1.4.0.ebuild Added desktop entry.
compile on amd64 end with error: nasm not found uhexen2-1.4.0.ebuild should be modified: DEPEND="${UIDEPEND} x86? ( >=dev-lang/nasm-0.98.38 ) amd64? ( >=dev-lang/nasm-0.98.38 )"
Created attachment 94348 [details] uhexen2-1.4.0.ebuild The Makefile says "Disable this manually for any other cpu." The problem was that the ebuild was not defining USE_X86_ASM. Here is a fixed ebuild. (I can't test it for amd64.)
With fixed ebuild compilation ends with this error: Building hexenworld master server.. make: Entering directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Master' gcc -c -O -march=i386 -Wall -DPLATFORM_UNIX -o cmds.o cmds.c gcc -c -O -march=i386 -Wall -DPLATFORM_UNIX -o sys_main.o sys_main.c gcc -c -O -march=i386 -Wall -DPLATFORM_UNIX -o net.o net.c gcc -o hwmaster cmds.o sys_main.o net.o make: Leaving directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Master' Building hexenworld client (software renderer) make: Entering directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' Host OS : Linux Target OS: UNIX Sanity : Error, command(s) nasm not found make: *** [sanity] Error 2 make: Leaving directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' Building hexenworld client (opengl renderer) make: Entering directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' rm -f *.o win_stuff/*.o core .tmp *.tmp make: Leaving directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' make: Entering directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' Host OS : Linux Target OS: UNIX Sanity : Error, command(s) nasm not found make: *** [sanity] Error 2 make: Leaving directory `/var/tmp/portage/uhexen2-1.4.0/work/hexen2source-1.4.0/hexenworld/Client' !!! ERROR: games-fps/uhexen2-1.4.0 failed. Call stack: ebuild.sh, line 1539: Called dyn_compile ebuild.sh, line 939: Called src_compile uhexen2-1.4.0.ebuild, line 123: Called die I think that hexenworld/build.sh needs to be fixed (inserting USE_X86_ASM variable somewhere)
Created attachment 94404 [details] uhexen2-1.4.0.ebuild Fixes USE_X86_ASM in hexenworld/Client/Makefile. The amd64 stuff in pkg_setup can probably be removed, by someone with some amd64 skill (which ain't me).
(In reply to comment #16) > Created an attachment (id=94404) [edit] > uhexen2-1.4.0.ebuild > > Fixes USE_X86_ASM in hexenworld/Client/Makefile. The amd64 stuff in pkg_setup > can probably be removed, by someone with some amd64 skill (which ain't me). > Unfortunately it's not possible, at this moment, because Hexenworld Client (software renderer version) fails on r_edge.c compiling. I've already reported this upstream! :)
Created attachment 101611 [details] uhexen2-1.4.1.ebuild A few new USE flags, and easier patching :)
(In reply to comment #18) > Created an attachment (id=101611) > uhexen2-1.4.1.ebuild > > A few new USE flags, and easier patching :) > few notes about the new 1.4.1 ebuild: - starting with gamedata-1.16, hexenworld actually works with the demo - hexen2 has a new dedicated server application (make -f Makefile.sv), you can add it to the ebuild if you want.
Created attachment 101681 [details] uhexen2-1.4.1.ebuild Allows hexenworld with demo. Added "dedicated" USE flag.
Created attachment 101868 [details] uhexen2-1.4.1.ebuild Forces opengl on amd64. Edits patch script.
Created attachment 101980 [details] uhexen2-1.4.1.ebuild amd64 fix for runtime segfault (tested by Davide Cendron).
I propose a new ebuild for the nearly next stable version of UHexen2, 1.4.2-pre3. This versione runs fine natively on 64bit, so i have changed accordingly the ebuild. These are the other major changes/improvements: - updated gamedata version (it's used the 1.19-pre3 version) - hexenworld pak files are installed only if "hexenworld" USE is enabled, and putted on right path (if "demo" is enabled, they are placed in $GAMES_DATADIR/hexen2/demo) - added "oss" USE: enable/disable OSS audio support - added "32bit" USE: if on AMD64, enable/disable compilation against 32bit libs - added "gtk" and "gtk2" USEs: enable/disable build of the graphical launcher, based on GTK libs. If both USEs are enabled, GTK2 is preferred - added "tools" USE: enable/disable build of some useful utility, available on "utils" subdir of source tree. In conjunction with "hexenworld" USE enabled, build some HexenWorld utility, available on "hw_utils" subdir of source tree. - now "dedicated" USE enable/disable ONLY build of Dedicated Server; "hexenworld", instead enable/disable build of ALL HexenWorld related binaries (Master/Server/Client) - now it's installed a desktop entry for HexenWorld client and one for the launcher, if they are installed. Feel free to hack/change/rape this ebuild ;)
Created attachment 116099 [details] uhexen2-1.4.2_pre3.ebuild
1.4.2-rc1 is out there: Being a release candidate, this should be better than the previous 1.4.2-pre3. Cheers.
Created attachment 120877 [details] uhexen2-1.4.2_rc1.ebuild Bump to version 1.4.2-rc1 Main changes: - removed "gtk2" USE flag, now the launcher is built with GTK2 support only (so enable "gtk" USE flag) - applied patch to improve the GTK launcher, and set the default path for game data files - applied patch to support "external" music files (see external_music.README for informations regarding how it works) - now the "software renderer" versions of binary games are always built (except on AMD64); the GL versions are built if "opengl" USE flag is enabled, or if on AMD64 (where the software versions don't build :-| ) - some tidyup and some fixes Make sure to get also below included patches. Feel free to test and improve this ebuild, waiting the 1.4.2 final release 8)
Created attachment 120879 [details, diff] uhexen2-1.4.2_rc1-cd_null-fix.diff Small patch to fix a compile error on cd_null.c
Created attachment 120881 [details, diff] uhexen2-1.4.2_rc1-h2launcher_improvements.diff Various improvements to GTK launcher
This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/svn/proj/sunrise/reviewed/games-fps/uhexen2/
Created attachment 126038 [details] uhexen2-1.4.2_rc2.ebuild Version bump (including some fixes/improvements).
Created attachment 132502 [details] uhexen2-1.4.2.ebuild Bump to version 1.4.2
Please use the new 1.4.2 version for 'demo data', as well, (hexen2demo-1.4.2-linux-i586.tgz or hexen2demo-1.4.2-linux-x86_64.tgz) The old 1.4.1 packages are outdated and removed from the download pages.
Created attachment 132585 [details] uhexen2-1.4.2.ebuild (In reply to comment #32) > Please use the new 1.4.2 version for 'demo data', as well, > (hexen2demo-1.4.2-linux-i586.tgz or hexen2demo-1.4.2-linux-x86_64.tgz) > The old 1.4.1 packages are outdated and removed from the download > pages. > You're right :) (but yesterday evening i can't view the 1.4.2 demodata package in SF download list, so i haven't updated the relevant items) :P
Please be advised of the following security bug before moving to the tree: http://secunia.com/advisories/28124/
Created attachment 138873 [details, diff] hexenworld Huffman vulnerability fix for uhexen2-1.4.2 fix issue announced at http://secunia.com/advisories/28124/ the fix is already in the CVS for quite some time and will be intergrated in the next release 1.4.3.
Created attachment 148930 [details] uhexen2-1.4.3.ebuild Bump to version 1.4.3
Created attachment 178887 [details] uhexen2-1.4.4_pre4.ebuild Added UHexen2 1.4.4 pre-release ebuild (i've also implemented some EAPI2 features)
there were two new -pre releases and there are no ebuilds. yet. (current is 1.4.4_pre6 i'll test ebuild bump and report
ebuild bump works if patch 00_Patches/midi_with_sdlaudio-test.diff is disabled - it seems to break build on midi_nul.c file, when enabled.
(In reply to comment #38) > current is 1.4.4_pre6 (In reply to comment #39) > ebuild bump works if patch 00_Patches/midi_with_sdlaudio-test.diff is disabled > - it seems to break build on midi_nul.c file, when enabled. 1.4.4-pre7 is out and it should fix the failure that you mention.
yes, i confirm that pre7 builds correctly with patch enabled for me, with as much as an ebuild bump from pre4
The '1.4.4_pre4' ebuild in Sunrise is no longer fetchable. As I see other issues (mentioned below) in it, I won't bump it myself but instead mask for removal in 30 days (keeping 1.4.3). If anyone's interested in bringing fresh _pre9 version, please visit #gentoo-sunrise with an updated ebuild. The issues I see right now are: 1) there should be a separate ebuild for gamedata -- there's no reason to reinstall the same files on each uhexen2 update, 2) xdelta probably has to become DEPEND too -- as the build fails without it, 3) the patches should be adjusted to work without switching directories (trivial to fix), 4) the CFLAGS mangling part is ugly and should certainly be rewritten, 5) elog should be used in postinst() instead of einfo. There's probably a lot more but that's just after a short seek.
*** Bug 181824 has been marked as a duplicate of this bug. ***
Created attachment 240087 [details] games-fps/uhexen2-1.4.4_pre9.ebuild
I just attached a new ebuild for uhexen2, updated to 1.4.4-pre9. It also contains a few changes, based both on my own ideas as well as other suggestions from this thread. Big changes: 1. Supports game data installation via new USE flags: 1a. cdinstall - games-fps/hexen2-data (bug 162606 - specifically hexen2-data-1.ebuild) 1b. portals - games-fps/hexen2-portals (bug 329773) 2. xdelta patching removed from uhexen2 ebuild and is instead performed by hexen2-data build (also uses xdelta3 directly now, which I find much easier than dealing with the xdelta3 vs. xdelta nonsense) Smaller changes: 1. Updated external-music-file-support.diff patch to apply from ${S}, as suggested in comment 42, though honestly the four new lines to make this change through sed seems more convoluted than simply changing directories temporarily. Regardless, it works fine either way. 2. postinst output updated a good bit to reflect hexen2-data, hexen2-portals, and xdelta changes. I also have it specific glhexen2 in the examples if opengl was enabled. 3. changed src_configure to src_prepare in accordance with latest ebuild guidelines. 4. Removed .png extension from shortcut icons, again in accordance with latest guidelines Additional notes: 1. The 'midi' USE flag is required for playing ripped CD audio tracks. 'cdaudio' is strictly for playing off the CD. This should probably be made more clear, and the midi and external-music patches probably shouldn't be applied if 'midi' is disabled. 2. If 'opengl' is enabled, I think it'd make more sense to install just the gl binary rather than both, or better: install the gl binary as hexen2 when 'opengl' is enabled so that the same binary name is always used regardless of opengl support. Is there any reason both binaries need to be installed simultaneously? 3. The frontend, h2launcher, completely failed to work for me. It always crashes with a buffer overflow as soon as I run it. I'm not sure if it's a problem with my system or my platform (amd64) or just a bug in the current version. Does this work for anyone else? Personally I'm not concerned as I use glhexen2 directly, but if others have problem with the frontend as well maybe we should force it disabled? 4. I have not messed with anything related to hexenworld or the hexen2 tools. There seems to be a lot going on with those parts, though, and especially some verbose postinst output. Personally it seems a bit overkill. Maybe this can be cleaned/trimmed up? That should cover it. The three ebuilds I submitted seem to work very well together for, at the very least, the main game and expansion pack. I can't comment on the extra stuff, though. Comments and suggestions are certainly welcome.
Created attachment 240127 [details] games-fps/uhexen2-1.4.4_pre9.ebuild More cleanup: * Updated midi behavior as previously commented and updated related documentation for pre9 * Updated opengl behavior as previously commented - now only one client binary gets built/installed, depending on opengl flag * Removed support for optimize-cflags and dynamic USE flags. I know, removing options isn't something we generally like to do, but in this case I don't see much benefit from providing the extra USE flags. Both options already have sensible defaults that work, and changing them doesn't add or change any features, and neither option should matter at all to gamers; they should typically only be useful for debugging. Removing them trims down the number of USE flags and cuts out a fair amount from the ebuild as well. * Fixed support for sdlaudio option
I've removed the offending ebuild from Sunrise (only the broken pre-release version, the stable's still there).
Version 1.4.4-pre10 is out.
Thanks for the heads up. The new version seems focused entirely on Windows fixes, though (with just one small SDL fix mentioned). I just revbumped the ebuild and the new version builds and plays fine.
(In reply to comment #49) > Thanks for the heads up. The new version seems focused entirely on Windows > fixes, though (with just one small SDL fix mentioned). I just revbumped the It has also an asm fix for the software renderer which affects all targets, and a fix for socket api usage affecting interoperability. > ebuild and the new version builds and plays fine. > 1.4.4-pre9 is removed from downloads so that no one uses it. Updating ebuilds to pre10 is recommended.
1.4.4_pre10 is out. simply rename ebuild and digest.
well, maybe not so simply... >>> Failed to emerge games-fps/uhexen2-1.4.4_pre10, Log file: >>> '/var/tmp/portage/games-fps/uhexen2-1.4.4_pre10/temp/build.log' * Messages for package games-fps/uhexen2-1.4.4_pre10: * ERROR: games-fps/uhexen2-1.4.4_pre10 failed: * emake launcher failed * * Call stack: * ebuild.sh, line 56: Called src_compile * environment, line 3278: Called die * The specific snippet of code: * emake AUTOTOOLS=1 ${opts} CPUFLAGS="${CFLAGS}" CC="$(tc-getCC) die "emake launcher failed"; * * If you need support, post the output of 'emerge --info =games-fps/uhexen .4_pre10', * the complete build log and the output of 'emerge -pqv =games-fps/uhexen2 4_pre10'. * This ebuild is from an overlay named 'zeroth': '/home/caibbor/src/ebuild * The complete build log is located at '/var/tmp/portage/games-fps/uhexen2 4_pre10/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-fps/uh -1.4.4_pre10/temp/environment'. * S: '/var/tmp/portage/games-fps/uhexen2-1.4.4_pre10/work/hexen2source-1.4 e10'
That's related to the frontend, h2launcher. As I noted in comment 45, it doesn't seem to work properly. It crashed immediately for me with pre9, so I just disabled it (via the gtk USE flag). I guess with pre10 it doesn't even compile anymore, at least on Linux. Yay. If you can live without it (CLI options are robust, so it hasn't been an issue at all for me), try building with -gtk and see if that works. I just rebuilt it on my system, with just a simple rename to pre10, and it worked fine here with -gtk.
FYI: Release v1.5.0 has been out since last month.
Created attachment 290585 [details] games-fps/uhexen2-1.5.0.ebuild Updated for 1.5.0. Thanks for the heads up. Please note: there quite a few changes upstream in this release, including a change in how the source files are laid out, which required a LOT of modifications to the ebuild. Everything should at least build and install, but I've not tested any of the hexenworld stuff or the optional tools/utilities. What I have tested, and works for me: * main game client w/ original game + expansion pack * midi music * ogg music Tested and a known problem: * GUI launcher - still dies immediately for me with a buffer overflow Would appreciate testing/feedback for the rest of the components. I don't use any of them myself, so I won't know if they work or not.
(In reply to comment #55) [...] > * GUI launcher - still dies immediately for me with a buffer overflow Can you please provide some details, e.g. some backtrace, so that I can fix it upstream?
Created attachment 290643 [details] h2launcher_output.txt Certainly, please see attached. This is just the raw output from the command, which includes a backtrace and memory map. I'll be happy to provide any other info you'd like, just let me know.
(In reply to comment #57) > Created attachment 290643 [details] > h2launcher_output.txt > > Certainly, please see attached. This is just the raw output from the command, > which includes a backtrace and memory map. I'll be happy to provide any other > info you'd like, just let me know. Thanks for the help. However the information refers specifically to your own binary. The only thing I can make out of it is that it happens only in main.c. It does get past ValidateByteorder() check at line 240, and then fails in either of Sys_GetUserdir() (caller from line 242) and more possibly Sys_FindBindir() (called from line 247) somehow. I am looking at the code and still can't find what is wrong. It will be very helpful if you can prepare a debug version of the binary (make DEBUG=1) and run it in gdb and give me the output from "bt" from within gdb. Thanks again.
(In reply to comment #58) > It will be very helpful if you can prepare a debug version of the binary (make > DEBUG=1) and run it in gdb and give me the output from "bt" from within gdb. OK, I've never used gdb before, so please let me know if I did this right. I reemerged uhexen2 with USE=debug, then then ran: 1. dgb uhexen2 2. run 3. bt Which yielded the following: #0 0x00007ffff6ce3835 in raise () from /lib64/libc.so.6 #1 0x00007ffff6ce4b35 in abort () from /lib64/libc.so.6 #2 0x00007ffff6d1e182 in ?? () from /lib64/libc.so.6 #3 0x00007ffff6d98557 in __fortify_fail () from /lib64/libc.so.6 #4 0x00007ffff6d963b0 in __chk_fail () from /lib64/libc.so.6 #5 0x00007ffff6d96a2b in __realpath_chk () from /lib64/libc.so.6 #6 0x000000000040674e in ?? () #7 0x00007ffff6ccfe9d in __libc_start_main () from /lib64/libc.so.6 #8 0x0000000000404249 in ?? () #9 0x00007fffffffdb88 in ?? () #10 0x000000000000001c in ?? () #11 0x0000000000000001 in ?? () #12 0x00007fffffffdf56 in ?? () #13 0x0000000000000000 in ?? () Is that what you're looking for?
(In reply to comment #59) > (In reply to comment #58) > > It will be very helpful if you can prepare a debug version of the binary (make > > DEBUG=1) and run it in gdb and give me the output from "bt" from within gdb. > > OK, I've never used gdb before, so please let me know if I did this right. I > reemerged uhexen2 with USE=debug, then then ran: > > 1. dgb uhexen2 > 2. run > 3. bt Thanks. Yes, we are getting closer, however ... > > Which yielded the following: > > #0 0x00007ffff6ce3835 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6ce4b35 in abort () from /lib64/libc.so.6 > #2 0x00007ffff6d1e182 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff6d98557 in __fortify_fail () from /lib64/libc.so.6 > #4 0x00007ffff6d963b0 in __chk_fail () from /lib64/libc.so.6 > #5 0x00007ffff6d96a2b in __realpath_chk () from /lib64/libc.so.6 > #6 0x000000000040674e in ?? () > #7 0x00007ffff6ccfe9d in __libc_start_main () from /lib64/libc.so.6 > #8 0x0000000000404249 in ?? () > #9 0x00007fffffffdb88 in ?? () > #10 0x000000000000001c in ?? () > #11 0x0000000000000001 in ?? () > #12 0x00007fffffffdf56 in ?? () > #13 0x0000000000000000 in ?? () > > Is that what you're looking for? It doesn't clearly say where it fails and looks like either the binary is stripped or it was somehow built with optimizations on. I am not familiar with gentoo ebuilds, so I don't know which is the case. Easiest way of pinpointing this segfault would be building the launcher by hand without the help of the ebuilds: cd hexen2source-1.5.0/launcher/ make DEBUG=1 gdb ./h2launcher [when in gdb: ] run [when it segfaults: ] bt If you need any more help, feel free to ask me. Thanks again.
Good suggestion on building it manually. Turns out, the launcher runs fine when I do that. So, I rebuilt it again manually, but this time using the same flags that the ebuild would throw at it, which in my case is: make -j9 DEBUG=1 'CPUFLAGS=-march=native -O2 -pipe -g2' This made it crash again. I tried toggling off those CPUFLAGS one at a time until I identified -O2 as the culprit. Without -O2, it seems to run just fine. -O2 is a very common optimization setting for Gentoo, though (in fact, I'm pretty sure it's included in the default build config), so it'd be really helpful if you could investigate a bit further to see why that causes it to fail. I also noticed that, with -O2 enabled, a few warnings are generated by gcc that don't show up otherwise. I have no doubt now that this must be related to the crash. I think you should be able to pretty easily replicate yourself, so I'll hold off on posting any additional attachments, but I'm still more than happy to help in any way I can. You can also feel free to e-mail me directly. Thanks again.
> #3 0x00007ffff6d98557 in __fortify_fail () from /lib64/libc.so.6 > #4 0x00007ffff6d963b0 in __chk_fail () from /lib64/libc.so.6 > #5 0x00007ffff6d96a2b in __realpath_chk () from /lib64/libc.so.6 OK, I fixed/worked around this in our svn: http://uhexen2.svn.sourceforge.net/viewvc/uhexen2?view=revision&revision=4283 Obviously we are doing doing just fine with 256 bytes for OS paths, but the new glibc is way too strict about PTH_MAX and realpath().
Created attachment 290741 [details, diff] uhexen2-1.5.0-h2launcher.patch Attaching patch to fix GUI launcher. Big, big thanks to O.Sezer for identifying and fixing the problem.
Created attachment 290743 [details] games-fps/uhexen2-1.5.0.ebuild updated build to support the patch
FYI: v1.5.1 is released today.
FYI: v1.5.2 is just released.
FYI: v1.5.3 is just released.
Created attachment 308485 [details] games-fps/uhexen2-1.5.3.ebuild very minor update to support v1.5.3
v1.5.4 is just released. (Your demodata ebuilds need updating too.)
v1.5.5 is just released. (Your demodata ebuilds need updating too.)
v1.5.6 is just released. (Your demodata ebuilds need updating too.)
It is possible only to rename the ebuild to got the newest version?
Any progress here? I was not able to update the package with changing the ebuild name. The way how the files are organized has changed on their sourceforge account. maybe someone can look into it?
bump
bump. seems that there is no progress anymore. would be nice if you jared could update the ebuild...
@Jared B. Would be nice if you could update your existing 1.5.3 ebuild to the newest existing version. The way how the files are organised has changed maybe.
Any progress here? Please update the ebuild to newest version which is out since a year?!? thanks.
Created attachment 396606 [details] 1.5.6 ebuild Small modifications for 1.5.6
for USE='hexenworld', the line newicon engine/resource/hw2_32x32x8.png hwcl.png || die needs fixing. If there are more similar ones, they also do. I only fixed one for classic hexen2
Created attachment 401802 [details] New ebuild for uhexen2-1.5.6 Fixed broken files, added more options to dependencies, enabled building with opus support and cleaned the code.
Created attachment 402094 [details] uhexen2-1.5.6-r1.ebuild Fixed build options detection and added USE="client" to allow user to choose whether to build the game client itself, or just stay with dedicated binary (or none at all, building tools only). Plus a couple of small fixes with dependencies and GTK launcher.
v1.5.7 has been released.
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/