soup-gnutls.c: In function `verify_certificate': soup-gnutls.c:64: error: `GNUTLS_CERT_NOT_TRUSTED' undeclared (first use in this function) soup-gnutls.c:64: error: (Each undeclared identifier is reported only once soup-gnutls.c:64: error: for each function it appears in.) make[3]: *** [soup-gnutls.lo] Error 1 gnutls-1.1.23 only mentions that name in the changelog: 2003-11-01 Nikos Mavrogiannopoulos <nmav@gnutls.org> * GNUTLS_CERT_NOT_TRUSTED was replaced by GNUTLS_CERT_INVALID, to avoid having two flags for the same thing. gnutls-1.0.23 did define it: ./includes/gnutls/compat8.h:#define GNUTLS_CERT_NOT_TRUSTED GNUTLS_CERT_INVALID I plan to nuke the GNUTLS_CERT_NOT_TRUSTED mention from libsoup, as its pretty much not needed, and breaks building with the new gnutls.
fixed in cvs. has_version ">=net-libs/gnutls-1.1.23" && sed -e's|GNUTLS_CERT_NOT_TRUSTED|0|g' -i ${S}/libsoup/soup-gnutls.c
swtaylor, you are aware that your fix is breaking in 2 ways ? 1. it sets the def to 0, while it just should be reset to GNUTLS_CERT_INVALID (dunno why you choose to not do the obvious thing?) 2. it might break ABI compatability, if someone compiled this with an old enough version of gnutls and only later on upgrades gnutls there's the chance of a symbol missing. You should just always apply the patch (given that GNUTLS_CERT_INVALID has been around long enough).
1. yes - doubly bad because GNUTLS_CERT_INVALID=2 - fixed now cause it was real bad(tm) 2. unlikely. There has been two API changes from 1.0.23 to 1.2.0. Users would of had to do a revdev-rebuild after the last upgrade. Also: In gnutls-1.0.23 and gnutls-1.0.17, GNUTLS_CERT_INVALID is a #defines of GNUTLS_CERT_INVALID. They are set at compile time shouldn't be a problem. fgrep -r GNUTLS_CERT_INVALID ./usr/include/gnutls/gnutls.h: GNUTLS_CERT_INVALID=2, /* will be set if the certificate ./usr/include/gnutls/compat8.h:#define GNUTLS_CERT_NOT_TRUSTED GNUTLS_CERT_INVALID Fixed sed to: sed -e's|GNUTLS_CERT_NOT_TRUSTED|GNUTLS_CERT_INVALID|g' This has been upstream for a while. Any other issues?
point 2 might be unlikely (i already phrased it conservative in my initial comment), but with the amount of users & resulting setups we have, why take the chance ? The dep at least (the only form of control) is not exclusive enough.
libsoup depend on >=app-crypt/gnutls-1.0.17?
hypothetical case (should be >=1.1.23 if you apply the patch conditionally, but that doesn't make sense). Just always apply the patch, the conditional is unneeded & a possible source of ABI problems later on.
changed to use patch from upstream unconditionally.
