[pkg-go] Bug#923656: golang-github-klauspost-cpuid: FTBFS (TestCPUInfo_TSX sometimes fails)

[Santiago Vila]

Package: src:golang-github-klauspost-cpuid
Version: 1.1+dfsg1-4
Severity: important
Tags: ftbfs

Dear maintainer:

Some time ago, I tried to build this package in buster but it failed:

--------------------------------------------------------------------------------
[...]
 debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
   dh_update_autotools_config -i -O--buildsystem=golang
   dh_auto_configure -i -O--buildsystem=golang
   dh_auto_build -i -O--buildsystem=golang
	cd obj-x86_64-linux-gnu && go install -gcflags=\"-trimpath=/<<BUILDDIR>>/golang-github-klauspost-cpuid-1.1\+dfsg1/obj-x86_64-linux-gnu/src\" -asmflags=\"-trimpath=/<<BUILDDIR>>/golang-github-klauspost-cpuid-1.1\+dfsg1/obj-x86_64-linux-gnu/src\" -v -p 1 github.com/klauspost/cpuid
github.com/klauspost/cpuid
   dh_auto_test -i -O--buildsystem=golang
	cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/klauspost/cpuid
=== RUN   TestCPUID
--- PASS: TestCPUID (0.00s)
	cpuid_test.go:14: Max Function:0xd
	cpuid_test.go:16: Max Extended Function:0x80000008
	cpuid_test.go:17: Name: Intel(R) Xeon(R) CPU E5-2697 v4 @ 2.30GHz

[... snipped ...]

	mockcpu_test.go:181: Max Extended Function:0x80000008
	mockcpu_test.go:182: PhysicalCores: 0
	mockcpu_test.go:183: ThreadsPerCore: 1
	mockcpu_test.go:184: LogicalCores: 0
	mockcpu_test.go:185: Family 15 Model: 2
	mockcpu_test.go:186: Features: CMOV,MMX,MMXEXT,SSE,SSE2,SSE2SLOW
	mockcpu_test.go:187: Cacheline bytes: 128
	mockcpu_test.go:188: L1 Instruction Cache: -1 bytes
	mockcpu_test.go:189: L1 Data Cache: -1 bytes
	mockcpu_test.go:190: L2 Cache: -1 bytes
	mockcpu_test.go:191: L3 Cache: -1 bytes
	mockcpu_test.go:174: Opening Vortex86_SoC0000522_Vortex86DX_CPUID.txt
	mockcpu_test.go:177: Name: unknown
	mockcpu_test.go:179: Max Function:0x1
	mockcpu_test.go:181: Max Extended Function:0x0
	mockcpu_test.go:182: PhysicalCores: 0
	mockcpu_test.go:183: ThreadsPerCore: 1
	mockcpu_test.go:184: LogicalCores: 0
	mockcpu_test.go:185: Family 5 Model: 2
	mockcpu_test.go:186: Features: 
	mockcpu_test.go:187: Cacheline bytes: 0
	mockcpu_test.go:188: L1 Instruction Cache: -1 bytes
	mockcpu_test.go:189: L1 Data Cache: -1 bytes
	mockcpu_test.go:190: L2 Cache: -1 bytes
	mockcpu_test.go:191: L3 Cache: -1 bytes
	mockcpu_test.go:174: Opening Vortex86_SoC0000586_Vortex86MX_CPUID.txt
	mockcpu_test.go:177: Name: unknown
	mockcpu_test.go:179: Max Function:0x1
	mockcpu_test.go:181: Max Extended Function:0x0
	mockcpu_test.go:182: PhysicalCores: 0
	mockcpu_test.go:183: ThreadsPerCore: 1
	mockcpu_test.go:184: LogicalCores: 0
	mockcpu_test.go:185: Family 5 Model: 8
	mockcpu_test.go:186: Features: 
	mockcpu_test.go:187: Cacheline bytes: 0
	mockcpu_test.go:188: L1 Instruction Cache: -1 bytes
	mockcpu_test.go:189: L1 Data Cache: -1 bytes
	mockcpu_test.go:190: L2 Cache: -1 bytes
	mockcpu_test.go:191: L3 Cache: -1 bytes
FAIL
FAIL	github.com/klauspost/cpuid	0.132s
dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 1 github.com/klauspost/cpuid returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit status 2
--------------------------------------------------------------------------------

Apparently dh_auto_test performs a series of tests to the CPU of the
building machine.

This seems weird to me, as the tests are supposed to test the recently
built program, not the underlying hardware. This makes the package not
to be reproducible in an extended sense, because as soon as the user
has a "non-conforming CPU" (whatever that means), the package will not
build.

This happened to me at least twice in the past. One of them using a
machine from Linode, and another time using a machine from Digital Ocean.
Here are the build logs:

https://people.debian.org/~sanvila/build-logs/golang-github-klauspost-cpuid/

In both cases the failing tests was the same:

--- FAIL: TestCPUInfo_TSX (0.00s)

So I wonder if a failure of this test really means that the package
has been misbuilt or it is misbehaving.

Thanks.