I'd like to proposed a bump of ctorrent to use the most recent dnh patchset (-dnh2). It brings numerous improvements/fixes (see the ChangeLog in the patch itself). In addition to bumping the patch version, i've made the following changes to the ebuild: - inherit autotools and call eautoreconf (since autotools files are changed) - dodoc the -dnh's README and ChangeLog - added an hotfix from -dnh's upstream for a crash when using a vfat filesystem - made some changes to detection of the lib providing SHA1 functions, to allow compilation with LDFLAGS="-Wl,--as-needed". The point is that libssl is not seen as a provider of the SHA1 function in this setup, because they actually are from libcrypto. But it is still the libcrypto from OpenSSL (hence requiring an "#include <openssl/sha.h>"), and not a standalone one (which was triggering an "#include <sha.h>" with the current configure script).
Created attachment 85928 [details] ctorrent-1.3.4-r3.ebuild Bumped ebuild.
Created attachment 85929 [details, diff] files/ctorrent-1.3.4-dnh2-vfat.patch The vfat hotfix.
Created attachment 85930 [details, diff] files/ctorrent-1.3.4-dnh2-SHA.patch The changes required for good libcrypto detection and usage with --as-needed.
*** This bug has been marked as a duplicate of 112352 ***
Sigh... the other way round. /me stabs bugzilla for dying over and over again.
*** Bug 112352 has been marked as a duplicate of this bug. ***
Linking to bug #129413 since the -r2 ebuild doesn't compile here with --as-needed.
Now in portage, thanks for the patches :)
