Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 424341 - games-puzzle/enigma doesn't compile with enet:1.3
Summary: games-puzzle/enigma doesn't compile with enet:1.3
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Games (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo Games
URL: http://www.openbsd.org/cgi-bin/cvsweb...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-01 08:08 UTC by Torsten Kaiser
Modified: 2015-02-08 18:53 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
egoboo with patch enet-1.3 (egoboo.tar.gz,10.14 KB, application/x-gzip)
2012-11-24 03:08 UTC, Mariano
Details
Enigma with patch enet-1.3 (enigma.tar.gz,10.15 KB, application/x-gzip)
2012-11-24 03:10 UTC, Mariano
Details
enigma-1.20-enet-1.3.patch (enigma-1.20-enet-1.3.patch,2.30 KB, patch)
2013-08-18 14:11 UTC, Andrew Savchenko
Details | Diff
patch for enigma 1.20 to build against enet 1.3.7 (enigma-1.20-enet-1.3.7.patch,2.23 KB, patch)
2014-11-15 14:33 UTC, Felix J. Ogris
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Torsten Kaiser 2012-07-01 08:08:21 UTC
enigma depends on net-libs/enet:0, but the 2010er version of sauerbraten wants enet:1.3.
Also the upgrade from mana-0.6.0 to -0.6.1 failed when enet-1.2.2 was installed.

The dependency of enigma is currently correct, because it will fail to compile with the newer enet versions, but as enet:0 and enet:1.3 can not be installed at the same time, this dependency becomes a hassle.

Please consider adding the two OpenBSD patches from above URL (patch-src_client_cc and patch-src_netgame_cc) to the ebuild, as with these patches enigma builds and works fine for me against enet-1.3.4

Thanks.
Comment 1 Julian Ospald 2012-07-03 14:40:08 UTC
Are those patches upstream approved?
Comment 2 Julian Ospald 2012-07-03 14:52:43 UTC
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
Comment 3 Torsten Kaiser 2012-07-03 18:23:29 UTC
> 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...
Comment 5 Michael Weber (RETIRED) gentoo-dev 2012-07-05 07:41:55 UTC
Should I keep enet-1.0:0 for now?

I was about to drop it after ppc stabilization of 1.2.2:0

Michael
Comment 6 Torsten Kaiser 2012-07-05 17:31:25 UTC
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.)
Comment 7 Michael Weber (RETIRED) gentoo-dev 2012-07-06 05:53:56 UTC
(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
Comment 8 Ben Longbons 2012-09-03 04:13:27 UTC
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
Comment 9 Julian Ospald 2012-09-03 13:30:11 UTC
maybe it would be rather possible to introduce "static" useflag for some of the games depending on enet? enet has static-libs...
Comment 10 Ben Longbons 2012-09-03 15:23:15 UTC
(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.
Comment 11 Mariano 2012-11-24 03:08:38 UTC
Created attachment 330382 [details]
egoboo with patch enet-1.3
Comment 12 Mariano 2012-11-24 03:10:20 UTC
Created attachment 330384 [details]
Enigma with patch enet-1.3
Comment 13 Chris 2013-05-08 14:25:34 UTC
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.
Comment 14 Chris 2013-05-08 14:39:44 UTC
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'
Comment 15 Andrew Savchenko gentoo-dev 2013-08-18 14:11:35 UTC
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.
Comment 16 juantxorena@gmail.com 2014-06-15 12:05:12 UTC
You can add games-strategy/0ad to the games blocked by this.
Comment 17 Felix J. Ogris 2014-11-15 14:33:36 UTC
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.
Comment 18 Andrew Savchenko gentoo-dev 2014-11-15 16:13:36 UTC
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.
Comment 19 Julian Ospald 2014-11-15 16:28:40 UTC
(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?
Comment 20 Andrew Savchenko gentoo-dev 2014-11-15 16:35:24 UTC
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.
Comment 21 Julian Ospald 2014-11-15 17:23:42 UTC
(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.
Comment 22 Andrew Savchenko gentoo-dev 2014-11-15 18:14:09 UTC
(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).
Comment 23 Julian Ospald 2014-11-15 19:33:29 UTC
(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.
Comment 25 Andrew Savchenko gentoo-dev 2014-11-16 02:10:49 UTC
Good work. Let's wait for upstream response then.

Meanwhile should "experimental" USE flag be implemented?
Comment 26 Torsten Kaiser 2015-02-08 17:44:59 UTC
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!
Comment 27 Mr. Bones. (RETIRED) gentoo-dev 2015-02-08 18:53:15 UTC
Nice.  I dropped the slot dep.