| Summary: | games-puzzle/enigma doesn't compile with enet:1.3 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Torsten Kaiser <Storklerk> |
| Component: | [OLD] Games | Assignee: | Gentoo Games <games> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | b.r.longbons, bircoph, xmw |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://www.openbsd.org/cgi-bin/cvsweb/ports/games/enigma/patches/ | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
egoboo with patch enet-1.3
Enigma with patch enet-1.3 enigma-1.20-enet-1.3.patch patch for enigma 1.20 to build against enet 1.3.7 |
||
|
Description
Torsten Kaiser
2012-07-01 08:08:21 UTC
Are those patches upstream approved? manas dependency on enet is fixed: + 03 Jul 2012; Julian Ospald <hasufell@gentoo.org> mana-0.6.1.ebuild: + slot net-libs/enet to 1.3 wrt bug #424341 > Are those patches upstream approved? I guess upstream doesn't know about them or the bug. As enigma-1.01 is from 2007 and the last news on there homepage was from 2010, I just googled for a solution and these OpenBSD patches looked good. As the have been part of the OpenBSD ports tree for nearly a year, I assume that at least OpenBSD is shipping enigma with them. Looking further the engima devel-ml seems dead (at least the link the its archive), but the source tree still shows activity: http://sourceforge.net/p/enigma-game/source/2254/log/ There is also a forum that still looks active: http://www.mag-heut.net/blackball/index.php But upstream probably did not notice this breakage as they seem to bundle an 1.0 version of enet: http://sourceforge.net/p/enigma-game/source/2254/tree/trunk/lib-src/enet/ Not sure on how to get upstream approval... Should I keep enet-1.0:0 for now? I was about to drop it after ppc stabilization of 1.2.2:0 Michael Without these patches enigma compiled fine for me with enet-1.2.2. It just needs any SLOT 0 enet. (enet-1.0 didn't even had a amd64 KEYWORD for nearly two years) So with regard to enigma it should be fine to drop enet-1.0 after enet-1.2.2 is marked stable for ppc. (I did not test this, as I do not have a ppc machine.) (In reply to comment #6) > So with regard to enigma it should be fine to drop enet-1.0 after enet-1.2.2 > is marked stable for ppc. (I did not test this, as I do not have a ppc > machine.) ppc stabled enet-1.2.2 I'm assuming this bug should retitled as "net-libs/enet is not self-coinstallable"
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(net-libs/enet-1.2.2::gentoo, installed) pulled in by
net-libs/enet:0 required by (games-puzzle/enigma-1.01::gentoo, installed)
net-libs/enet:0 required by (games-rpg/egoboo-2.8.1::gentoo, installed)
(net-libs/enet-1.3.4::gentoo, ebuild scheduled for merge) pulled in by
>=net-libs/enet-1.3.0 required by (games-rpg/sumwars-0.5.6-r2::gentoo, ebuild scheduled for merge)
Could an eselect be added for enet, à la boost?
There are 3 conflicts, which are only at compile-time:
/usr/include/enet/ directory
/usr/lib64/libenet.so symlink
/usr/lib64/pkgconfig/libenet.pc
maybe it would be rather possible to introduce "static" useflag for some of the games depending on enet? enet has static-libs... (In reply to comment #9) > maybe it would be rather possible to introduce "static" useflag for some of > the games depending on enet? enet has static-libs... There's no conflict in the .so files ... for building the rdepends you'd still have to either unmerge/remerge (with the current enet packages) or do an eselect or something. Created attachment 330382 [details]
egoboo with patch enet-1.3
Created attachment 330384 [details]
Enigma with patch enet-1.3
As enigma 1.20 is now in portage tree it should support newer enet versions and the patch should not be needed, right?
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild NS ] net-libs/enet-1.2.2:0 [1.3.7:1.3/2.2] USE="-static-libs" 404 kB
[ebuild N ] dev-libs/xerces-c-3.1.1-r1 USE="curl iconv icu sse2 -doc -static-libs -threads" 4,933 kB
[ebuild N ~] games-puzzle/enigma-1.20 USE="nls" 35,655 kB
[blocks B ] net-libs/enet:0 ("net-libs/enet:0" is blocking net-libs/enet-1.3.7)
Total: 3 packages (2 new, 1 in new slot), Size of downloads: 40,992 kB
Conflict: 1 block (1 unsatisfied)
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(net-libs/enet-1.2.2::gentoo, ebuild scheduled for merge) pulled in by
net-libs/enet:0 required by (games-puzzle/enigma-1.20::gentoo, ebuild scheduled for merge)
(net-libs/enet-1.3.7::gentoo, installed) pulled in by
>=net-libs/enet-1.3.6:1.3 required by (games-fps/sauerbraten-2013.01.04::gentoo, installed)
net-libs/enet:1.3 required by (games-fps/redeclipse-1.4::gamerlay, installed)
>=net-libs/enet-1.3.0 required by (games-rpg/sumwars-0.5.6-r2::gentoo, installed)
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
If it is wrong to post it please attach it to the bugreport for the new 1.20 ebuild of enigma please.
Maybe it is possible to add the patch to the 1.20 ebuild so that it support enet 1.3x or remove depency on enet 1.2x.
The try to compile the new 1.20 of enigma with enet 1.3x failed. Therefore it need this patch also. >>> Emerging (3 of 3) games-puzzle/enigma-1.20 * enigma-1.20.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking enigma-1.20.tar.gz to /var/tmp/portage/games-puzzle/enigma-1.20/work .... i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../src -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -c -o ecl_video.o ecl_video.cc rm -f libecl.a ar cru libecl.a IMG_SavePNG.o SDL_gfxPrimitives.o SDL_rotozoom.o ecl_argp.o ecl_buffer.o ecl_dict.o ecl_font.o ecl_geom.o ecl_math.o ecl_sdl.o ecl_system.o ecl_sys_localename.o ecl_utf.o ecl_util.o ecl_video.o i686-pc-linux-gnu-ranlib libecl.a make[2]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/lib-src/enigma-core' make[2]: Entering directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/lib-src' make[2]: Für das Ziel »all-am« ist nichts zu tun. make[2]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/lib-src' make[1]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/lib-src' Making all in tools make[1]: Entering directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/tools' i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../src -I../lib-src/lua -x c++ -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -c -o tolua-tolua.o `test -f 'tolua.c' || echo './'`tolua.c i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../src -I../lib-src/lua -x c++ -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -c -o tolua-toluabind.o `test -f 'toluabind.c' || echo './'`toluabind.c i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../src -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -c -o dummy.o dummy.cc i686-pc-linux-gnu-g++ -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -Wl,-O1 -Wl,--as-needed -o tolua tolua-tolua.o tolua-toluabind.o dummy.o ../lib-src/lua/liblua.a -lcurl -lxerces-c -lpng -ldl make[1]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/tools' Making all in intl make[1]: Entering directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/intl' make[1]: Für das Ziel »all« ist nichts zu tun. make[1]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/intl' Making all in src make[1]: Entering directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/src' (CDPATH="${ZSH_VERSION+.}:" && cd .. && /bin/sh /var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/missing --run autoheader) rm -f stamp-h1 touch config.h.in cd .. && /bin/sh ./config.status src/config.h config.status: creating src/config.h config.status: src/config.h is unchanged make all-am make[2]: Entering directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/src' i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -DSYSTEM_DATA_DIR=\"/usr/share/games/enigma\" -DDOCDIR=\"/usr/games/share/doc/enigma\" -DLOCALEDIR=\"/usr/share/locale\" -I../lib-src/zipios++ -I../lib-src/zipios++ -I../lib-src/lua -I../lib-src/enigma-core -I../lib-src -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o actors.o actors.cc i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -DSYSTEM_DATA_DIR=\"/usr/share/games/enigma\" -DDOCDIR=\"/usr/games/share/doc/enigma\" -DLOCALEDIR=\"/usr/share/locale\" -I../lib-src/zipios++ -I../lib-src/zipios++ -I../lib-src/lua -I../lib-src/enigma-core -I../lib-src -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o AttributeDescriptor.o AttributeDescriptor.cc i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -DSYSTEM_DATA_DIR=\"/usr/share/games/enigma\" -DDOCDIR=\"/usr/games/share/doc/enigma\" -DLOCALEDIR=\"/usr/share/locale\" -I../lib-src/zipios++ -I../lib-src/zipios++ -I../lib-src/lua -I../lib-src/enigma-core -I../lib-src -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o client.o client.cc i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -DSYSTEM_DATA_DIR=\"/usr/share/games/enigma\" -DDOCDIR=\"/usr/games/share/doc/enigma\" -DLOCALEDIR=\"/usr/share/locale\" -I../lib-src/zipios++ -I../lib-src/zipios++ -I../lib-src/lua -I../lib-src/enigma-core -I../lib-src -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o DOMErrorReporter.o DOMErrorReporter.cc client.cc: In Elementfunktion »bool {anonym}::Client::network_start()«: client.cc:148:97: Fehler: zu wenige Argumente für Funktion »ENetHost* enet_host_create(const ENetAddress*, size_t, size_t, enet_uint32, enet_uint32)« /usr/include/enet/enet.h:527:21: Anmerkung: hier deklariert client.cc:167:65: Fehler: zu wenige Argumente für Funktion »ENetPeer* enet_host_connect(ENetHost*, const ENetAddress*, size_t, enet_uint32)« /usr/include/enet/enet.h:529:21: Anmerkung: hier deklariert i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -O2 -march=opteron -msse3 -pipe -fomit-frame-pointer -DENABLE_ASSERT -DCXXLUA -DSYSTEM_DATA_DIR=\"/usr/share/games/enigma\" -DDOCDIR=\"/usr/games/share/doc/enigma\" -DLOCALEDIR=\"/usr/share/locale\" -I../lib-src/zipios++ -I../lib-src/zipios++ -I../lib-src/lua -I../lib-src/enigma-core -I../lib-src -I../intl -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -c -o DOMSchemaResolver.o DOMSchemaResolver.cc make[2]: *** [client.o] Fehler 1 make[2]: *** Warte auf noch nicht beendete Prozesse... make[2]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/src' make[1]: *** [all] Fehler 2 make[1]: Leaving directory `/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20/src' make: *** [all-recursive] Fehler 1 * ERROR: games-puzzle/enigma-1.20 failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=games-puzzle/enigma-1.20'`, * the complete build log and the output of `emerge -pqv '=games-puzzle/enigma-1.20'`. * The complete build log is located at '/var/tmp/portage/games-puzzle/enigma-1.20/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/games-puzzle/enigma-1.20/temp/environment'. * Working directory: '/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20' * S: '/var/tmp/portage/games-puzzle/enigma-1.20/work/enigma-1.20' Created attachment 356376 [details, diff]
enigma-1.20-enet-1.3.patch
enet-1.3 patch updated for enigma-1.20.
channelCount arg for enet_host_connect() is set to 2 because enigma uses two channels.
You can add games-strategy/0ad to the games blocked by this. Created attachment 389402 [details, diff]
patch for enigma 1.20 to build against enet 1.3.7
Patch is almost identical to the one Andrew provided, except that the 4th parameter to enet_host_connect() is "user data supplied to the receiving host" which is available as event->data on the receiving node (2nd argument to enet_host_check_events()). This is not used by enigma and should be zero.
Since Enigma ships with a copy of enet, upstream is assumably not aware of this issue.
Games team, ping here. Are you OK with the latest patch? I'm going to apply it in three weeks if no reply or ojections. This bug is hanging around for too long. (In reply to Andrew Savchenko from comment #18) > Games team, ping here. > > Are you OK with the latest patch? I'm going to apply it in three weeks if no > reply or ojections. This bug is hanging around for too long. Has this been reported upstream? What to report to upstream? They have nothing to do with this issue. Upstream does _not_ support system enet. They ship internal bundled version. The change made in Gentoo is Gentoo specific and upstream unsupported: enet was unbundled. Now we have the issue with unbundled enet and we are on our own. (In reply to Andrew Savchenko from comment #20) > What to report to upstream? They have nothing to do with this issue. > > Upstream does _not_ support system enet. They ship internal bundled version. > The change made in Gentoo is Gentoo specific and upstream unsupported: enet > was unbundled. Now we have the issue with unbundled enet and we are on our > own. Although it doesn't seem to do a lot of stuff here (not even multiplayer games implemented afais), messing with net code is not a trivial thing to do. All game developers I know are VERY picky when it comes to net code (desyncs, different compilers, clients incompatible with different versions of net-libraries and whatnot). It compiles != it's correct. Steps to take: * open an issue upstream with an upstreamable patch to _optionally_ unbundle enet * open an issue to support enet-1.3 _optionally_ (as in: it should still be able to compile against 1.2) That said, I'm not even sure if unbundling without upstream support was a good idea in the first place. (In reply to Julian Ospald (hasufell) from comment #21) > Although it doesn't seem to do a lot of stuff here (not even multiplayer > games implemented afais), messing with net code is not a trivial thing to do. This is a quite straightforward API update. So I can't agree that this is a messing. > All game developers I know are VERY picky when it comes to net code > (desyncs, different compilers, clients incompatible with different versions > of net-libraries and whatnot). > > It compiles != it's correct. It can't be correct or not. It is dead, UNUSED code. As one can see from the source code, network functionality is available only if --enable-experimental is passed to configure — grep -i netgame -R . and see how it is used in ./src/gui/MainMenu.cc, the only place where it is used). In Gentoo we do not supply this option, so either experimental USE flag should be added (does anyone needs it anyway?) or code may be just patched out together with enet dependency at all. > Steps to take: > * open an issue upstream with an upstreamable patch to _optionally_ unbundle > enet > * open an issue to support enet-1.3 _optionally_ And what if upstream will ignore bug or send me straight to hell (the most probable scenario)? > (as in: it should still be able to compile against 1.2) Why? It is up to upstream. If they'll decide to drop 1.2 support, they'll do this. > That said, I'm not even sure if unbundling without upstream support was a > good idea in the first place. Rejecting Gentoo unbundling policy will be a better one? Bundled enet is not patched afaik, so there is no practical reason to use it. Anyway if I'll bundle some lib, people will file bugs and complains. Also bunbled version may be vulnerable (and will likely be one day or another). (In reply to Andrew Savchenko from comment #22) > (In reply to Julian Ospald (hasufell) from comment #21) > > Although it doesn't seem to do a lot of stuff here (not even multiplayer > > games implemented afais), messing with net code is not a trivial thing to do. > > This is a quite straightforward API update. So I can't agree that this is a > messing. > That doesn't tell you anything. Game development doesn't take place downstream. I have no problem with heavily patching build systems, but net code is a different thing. > > All game developers I know are VERY picky when it comes to net code > > (desyncs, different compilers, clients incompatible with different versions > > of net-libraries and whatnot). > > > > It compiles != it's correct. > > It can't be correct or not. It is dead, UNUSED code. As one can see from the > source code, network functionality is available only if > --enable-experimental is passed to configure — grep -i netgame -R . and see > how it is used in ./src/gui/MainMenu.cc, the only place where it is used). > > In Gentoo we do not supply this option, so either experimental USE flag > should be added (does anyone needs it anyway?) or code may be just patched > out together with enet dependency at all. > Reverting the bundling + disabling experimental switch explicitly seems reasonable then (in case upstream doesn't respond), since that effectively means we wouldn't even run vulnerable code. > > Steps to take: > > * open an issue upstream with an upstreamable patch to _optionally_ unbundle > > enet > > * open an issue to support enet-1.3 _optionally_ > > And what if upstream will ignore bug or send me straight to hell (the most > probable scenario)? > That's not an excuse to not try. I'v already sent two patches to the upstream ML. It's not good practice to FIRST patch _code_ (build system is a different story) downstream and don't care what upstream has to say about it. > > (as in: it should still be able to compile against 1.2) > > Why? It is up to upstream. If they'll decide to drop 1.2 support, they'll do > this. > That was an assumption based on experience. > > That said, I'm not even sure if unbundling without upstream support was a > > good idea in the first place. > > Rejecting Gentoo unbundling policy will be a better one? That's not what I said. A few distros broke games-action/supertuxkart some time ago by carelessly unbundling Irrlicht. It compiled and broke runtime. I'm saying that these things are best communicated upstream. However, this one doesn't look too severe, so as said before: if they don't respond we should probably revert unbundling and disable experimental if that code isn't used then. https://github.com/hasufell/hasufell-overlay/commit/051eb9a6fbf291e975944e624705d084a292fa2a https://lists.nongnu.org/archive/html/enigma-devel/2014-11/index.html Good work. Let's wait for upstream response then. Meanwhile should "experimental" USE flag be implemented? The new release 1.21 contains these patches. After removing the :0 from the net-libs/enet dependency in the ebuild, it build and worked from me with my installed enet-1.3.7. As the patches support both enet versions, it seems correct to just drop the slot operator instead of changing it to :1.3. Thanks for sending this upstream! Nice. I dropped the slot dep. |
