Update gnutls30 to build against nettle8 and support arm64

[dhomeier]

nettle7 fails to build on arm/arm64 with a ton of assembly errors like

gcc -I. -I/opt/sw2/include -DHAVE_CONFIG_H -g -O2 -ggdb3 -Wall -W   -Wmissing-prototypes -Wmissing-declarations -Wstrict-prototypes   -Wpointer-arith -Wbad-function-cast -Wnested-externs  -MT aes-encrypt-internal.o -MD -MP -MF aes-encrypt-internal.o.d -c aes-encrypt-internal.s
In file included from getopt1.c:26:
./getopt.h:169:19: warning: this function declaration is not a prototype [-Wstrict-prototypes]
extern int getopt ();
                  ^
                   void
In file included from getopt.c:98:
./getopt.h:169:19: warning: this function declaration is not a prototype [-Wstrict-prototypes]
extern int getopt ();
                  ^
                   void
getopt.c:146:21: warning: this function declaration is not a prototype [-Wstrict-prototypes]
extern char *getenv ();
                    ^
                     void
getopt.c:272:25: warning: unused parameter 'argc' [-Wunused-parameter]
_getopt_initialize (int argc, char *const *argv, const char *optstring,
                        ^
getopt.c:272:44: warning: unused parameter 'argv' [-Wunused-parameter]
_getopt_initialize (int argc, char *const *argv, const char *optstring,
                                           ^
1 warning generated.
aes-encrypt-internal.s:75:2: error: unrecognized instruction mnemonic
 teq r3, #0
 ^
aes-encrypt-internal.s:78:8: error: vector register expected
 push {r0,r1,r3, r4,r5,r6,r7,r8,r10,r11,lr}

so this seems unlikely to be easily fixed.

This PR provides updates to gnutls30 to

1. build against nettle8/libhogweed6
2. pull in upstream update 3.6.16 which includes a fix for the patched Xcode-11.4 bug and patched a test file
3. in the second commit update further to 3.7.8 (not sure about the consequences this should have for gsasl19

Both versions build and run tests on x86_64 and arm64, with two failures on the former, but ~100 often segfaulting on arm64, so this may need further discussion.
Among the BDeps further up guile22 in turn depends on libffi6, which has similar assembly failures, so will need to be switched to libffi8.

[nieder]

Changing the SOVERSION on libgnutlsxx.dylib will need a new package name as we go from 3.6 to 3.7.

[dhomeier]

libgnutls.30.dylib -> gnutls31 ?
Probably better to cherry-pick the first commit then rather than updating everything that depends on gnutls30 (or keep both, perhaps).

[nieder]

The new name gnutls31 will cause us problems if a future release has SOVERSION=31. The usual way to name things when only some libraries bump SOVERSION is to give it a package name that includes the version number that first required the workaround (see gpgme11-1.9-shlibs) and stash it into a private directory (like you did).
So in this case, the new package would be gnutls30-3.7-shlibs with things hidden in %p/lib/gnutls-3.7 (because this issue with libgnutls.30.dylib first arose in v3.7). IF gnutls v3.8 upstream continues to use this combination of SOVERSIONs, then we don't update the paths because the fundamentals haven't changed.
ffmpeg/libavcodec also uses this packaging scheme although they're now better at library versioning and it's technically no longer needed. But I've kept it to simplify my life.

[dhomeier]

So in this case, the new package would be gnutls30-3.7-shlibs with things hidden in %p/lib/gnutls-3.7 (because this issue with libgnutls.30.dylib first arose in v3.7). IF gnutls v3.8 upstream continues to use this combination of SOVERSIONs, then we don't update the paths because the fundamentals haven't changed.

I think I prefer to stick with 3.6.16 then and let someone else sort this out (or wait till they update to libgnutls.31.dylib)!

[nieder]

I can do that. Do I just need to cherry pick 7f0aaf2 and 69d3f86?

[dhomeier]

I can do that. Do I just need to cherry pick 7f0aaf2 and 69d3f86?

Yes, that should do – just tested on 12.6.1 with the new dpkg, thanks!

[nieder]

I can do that. Do I just need to cherry pick 7f0aaf2 and 69d3f86?

Yes, that should do – just tested on 12.6.1 with the new dpkg, thanks!

Do 3.6.16 tests pass? I'm getting failures:

FAIL: trustdb-tofu
doit:162: commitment verification: No certificate was found.
FAIL: keylog-env
run:136: keylog file was not created

[TheSin-]

nettle7 works fine just add

UpdateConfigGuess: true

[TheSin-]

gnutls3 builds with #952 tested on 13.x/x86_64 and 13.x/arm64

[nieder]

Completely forgot I had done work here. I have gnutls-3.7.8, which is a new libN building against nettle8/hogweed6. It should mostly be a drop in replacement for gnutls30 (v3.6.13). I haven't updated to 3.6.16 because some tests are failing.
This doesn't affect the work done in #952.

[nieder]

I've pushed gnutls30-3.7 (v3.7.8) in 2bc2e43. It uses nettle8.
I also pushed a couple packages to use it instead of the older gnutls30/nettle7 combo.

[dmacks]

As of d4377bb, everything that was using gnutls30 has migrated to gnutls30-3.7. So on the one hand, we can work on pushing the few stragglers using older nettle/hogweed to the newer versions of those. But on the other hand we can just ignore (or dist-restrict) gnutls30, which will become stubbed down to a -shlibs-only soon.

[nieder]

Nettle/hogweed was the other part of this pair.
Really ancient gnutls26-shlibs doesn't seem to use nettle (before its time?).
Only the really older gnutls (gnutls-2.12-shlibs and gnutls28-shlibs) are using nettle4a and libhogweed-shlibs.
Only gnutls30-shlibs uses nettle7 and libhogweed5-shlibs.

Ancient pygnutls-py is the sole user of ancient gnutls26-shlibs.
Nothing is using gnutls-2.12-shlibs (shlibs stub only already)
remmina is the sole user of gnutls28-shlibs (ancient upstream and really untouched by us in 10 years).
Nothing is now using gnutls30-shlibs.

[dmacks]

Those really-older gnutls (2.12, 28) have packaging notes that they are not compatible with the newer nettle/hogweek libversions.

[dmacks]

With an eye towards stubbing down gnutls30, and migrating it to the new nettle/hogweed...but it fails self-tests (even with the upstream patch that claims to fix). And it's completely unused. Gonna kill it altogether unless someone objects.