Bug#818341: gnutls28: FTBFS on amd64: assumes build machine has all CPU extensions

[Simon McVittie]

Source: gnutls28
Version: 3.4.9-2
Severity: serious
Tags: upstream
Justification: fails to build from source (but built successfully in the past)

gnutls28 is failing to build from source on amd64 again, with an error that
is not the same as the ones described in #805863:

> FAIL: test-hash-large
> =====================
>
> Illegal instruction
> SSSE3 cipher tests failed
> FAIL test-hash-large (exit status: 132)

The test in question runs a test repeatedly with GNUTLS_CPUID_OVERRIDE
set to various values:

https://sources.debian.net/src/gnutls28/3.4.10-3/tests/slow/test-hash-large/

I'm not sure how this can be expected to work on anything except the
latest CPUs, and we can't assume that Debian buildds have the latest
CPUs. A baseline x86 or x86_64 CPU does not have SSSE3, and if the CPU
doesn't have the extension, forcing it via GNUTLS_CPUID_OVERRIDE is just
going to result in running code that can't work on the current CPU?

It seems to me as though it would be more useful for test coverage if
the meaning of GNUTLS_CPUID_OVERRIDE was changed from "assume the CPU
has exactly these extensions" to "use only these extensions, even if
the CPU has others". Pseudocode now:

    if (GNUTLS_CPUID_OVERRIDE)
        extensions = parse (GNUTLS_CPUID_OVERRIDE);
    else
        extensions = cpuid ();

Pseudocode that I think would be more useful:

    extensions = cpuid ();

    if (GNUTLS_CPUID_OVERRIDE)
        extensions &= parse (GNUTLS_CPUID_OVERRIDE);

Longer-term, it would also be great if the tests (at least those that do not
require much environment setup) could be packaged as "installed tests"
similar to those in glib2.0, so that they can be re-run on systems that
differ from the buildd.

    S