Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
Control: forwarded -1 https://github.com/shirou/gopsutil/issues/881
I'm having a hard time seeing bugs like this as RC-critical. Looking at
the testsuite more specifically, I strongly believe this is upstream bug
https://github.com/shirou/gopsutil/issues/881
Lucas, can you please post /proc/cpuinfo from the amd64 machine you
tested on so that we confirm that it doesn't report a modelname?
I'd concur with Andreas to disable running tests on !amd64, maybe with
something like this patch:
modified debian/rules
@@ -10,3 +10,9 @@ export CIRCLECI := true
%:
dh $@ --buildsystem=golang --with=golang
+
+
+override_dh_auto_test:
+ifneq (,$(filter $(DEB_HOST_ARCH), amd64))
+ dh_auto_test --buildsystem=golang
+endif
Alternativly, we could also disable the "problematic part" of the test until
the upstream bug is fixed properly:
diff --git a/cpu/cpu_test.go b/cpu/cpu_test.go
index e8e0e8d..dbcaaae 100644
--- a/cpu/cpu_test.go
+++ b/cpu/cpu_test.go
@@ -85,11 +85,6 @@ func TestCpuInfo(t *testing.T) {
if len(v) == 0 {
t.Errorf("could not get CPU Info")
}
- for _, vv := range v {
- if vv.ModelName == "" {
- t.Errorf("could not get CPU Info: %v", vv)
- }
- }
}
In any case, I'm unconvinced that this bug is severe enough to claim it
as 'release critical' would warrant removing the package from unstable.
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
On Sat, Dec 12, 2020 at 10:32:15AM +0100, Lucas Nussbaum wrote: > Hi Andreas, > > Is the above problem going to be a problem at runtime as well? It depends on which part of /proc you use and how it deviates on your architecture, but yes... eventually you'll hit something that errors out in parsing or worse returns an answer that's just wildly wrong/unexpected. > If so, I wonder if you should make this package "Architecture: amd64" > instead of "Architecture: all". [...] In theory, the right question is probably what anyone is willing to support. Debian usually takes the naive approach of assuming porters will fix up any issues once they're found, but that's not really how things turn out in practise. (Also if we limit the archs, what is the correct subset? The ones where the testsuite succeeds? The ones where it actually works? The ones which someone is actually promising to support?) The practical problem is that if the arch field is changed what happens to the entire reverse dependency tree that has accumulated? Getting one thing removed from the archive is hard and painful enough Regards, Andreas Henriksson
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
On 11/12/20 at 22:43 +0100, Andreas Henriksson wrote:
> Hello Lucas Nussbaum,
>
> On Sat, Dec 05, 2020 at 02:23:54PM +0100, Lucas Nussbaum wrote:
> > Source: golang-github-shirou-gopsutil
> > Version: 2.19.11-3
> > Severity: serious
> > Justification: FTBFS on arm64
> > Tags: bullseye sid ftbfs
> > Usertags: ftbfs-20201205 ftbfs-bullseye
> >
> > Hi,
> >
> > During a rebuild of all packages in sid, your package failed to build
> > on arm64 (I don't know if it also fails on amd64).
> [...]
> > > === RUN TestCpuInfo
> > > cpu_test.go:90: could not get CPU Info:
> > > {"cpu":0,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"0","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info:
> > > {"cpu":1,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"1","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info:
> > > {"cpu":2,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"2","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > cpu_test.go:90: could not get CPU Info:
> > > {"cpu":3,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"3","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > > --- FAIL: TestCpuInfo (0.00s)
> [...]
> > > FAIL
> > > FAIL github.com/shirou/gopsutil/cpu 0.047s
> [...]
> > > FAIL
> > > dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4
> > > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu
> > > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker
> > > github.com/shirou/gopsutil/host
> > > github.com/shirou/gopsutil/internal/common
> > > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem
> > > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process
> > > returned exit code 1
> >
> > The full build log is available from:
> >
> > http://qa-logs.debian.net/2020/12/05/golang-github-shirou-gopsutil_2.19.11-3_unstable.log
> [...]
>
> With the above log I will, without ever looking deeper at the problem,
> claim that gopsutil parsing of /proc/cpuinfo does not work on your
> architecture of choice.
>
> I've briefly dug into this package in the past[1] and unless my memory
> serves me wrong my conclusion was that gopsutil's assumptions about
> /proc is not intended to be portable between architectures at all.
> On the other hand /proc looking wildly different between architectures
> on linux is kind of a problem that each architecture that is not the
> most popular one is setting themselves up for problems with. Not even
> using the same syntax in /proc/cpuinfo (or even using same keywords
> as used on mainstream archs, but give them a different meaning!).
>
> I would personally expect that porters steps up if they want a
> particular piece of software ported to their arch, but I doubt that will
> happen. I also very much doubt anyone else will port to a wide range of
> architectures, or even a single one - plus maintain it.
>
> I can thus suggest one "solution":
> Disable the testsuite on !amd64 and just let it build without actually
> ever having a chance of working except possibly by chance.
> (We all did this for so many years while kfreebsd was still a testing
> migration blocker, so it's not like my suggestion is a new idea.)
Hi Andreas,
Is the above problem going to be a problem at runtime as well?
If so, I wonder if you should make this package "Architecture: amd64"
instead of "Architecture: all".
If the problem is only at build time (but the package works fine, when
installed, on all architectures), it might be better to leave it as is,
and just document in a bug that it can only be build on amd64. For
example:
retitle 976509 golang-github-shirou-gopsutil: FTBFS when building
arch:all on arch != amd64
severity 976509 minor
Lucas
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
Hello Lucas Nussbaum,
On Sat, Dec 05, 2020 at 02:23:54PM +0100, Lucas Nussbaum wrote:
> Source: golang-github-shirou-gopsutil
> Version: 2.19.11-3
> Severity: serious
> Justification: FTBFS on arm64
> Tags: bullseye sid ftbfs
> Usertags: ftbfs-20201205 ftbfs-bullseye
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on arm64 (I don't know if it also fails on amd64).
[...]
> > === RUN TestCpuInfo
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":0,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"0","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":1,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"1","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":2,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"2","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > cpu_test.go:90: could not get CPU Info:
> > {"cpu":3,"vendorId":"","family":"","model":"","stepping":0,"physicalId":"","coreId":"3","cores":1,"modelName":"","mhz":0,"cacheSize":0,"flags":["fp","asimd","evtstrm","aes","pmull","sha1","sha2","crc32","atomics","fphp","asimdhp","cpuid","asimdrdm","lrcpc","dcpop","asimddp","ssbs"],"microcode":""}
> > --- FAIL: TestCpuInfo (0.00s)
[...]
> > FAIL
> > FAILgithub.com/shirou/gopsutil/cpu 0.047s
[...]
> > FAIL
> > dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4
> > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu
> > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker
> > github.com/shirou/gopsutil/host github.com/shirou/gopsutil/internal/common
> > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem
> > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process returned
> > exit code 1
>
> The full build log is available from:
>
> http://qa-logs.debian.net/2020/12/05/golang-github-shirou-gopsutil_2.19.11-3_unstable.log
[...]
With the above log I will, without ever looking deeper at the problem,
claim that gopsutil parsing of /proc/cpuinfo does not work on your
architecture of choice.
I've briefly dug into this package in the past[1] and unless my memory
serves me wrong my conclusion was that gopsutil's assumptions about
/proc is not intended to be portable between architectures at all.
On the other hand /proc looking wildly different between architectures
on linux is kind of a problem that each architecture that is not the
most popular one is setting themselves up for problems with. Not even
using the same syntax in /proc/cpuinfo (or even using same keywords
as used on mainstream archs, but give them a different meaning!).
I would personally expect that porters steps up if they want a
particular piece of software ported to their arch, but I doubt that will
happen. I also very much doubt anyone else will port to a wide range of
architectures, or even a single one - plus maintain it.
I can thus suggest one "solution":
Disable the testsuite on !amd64 and just let it build without actually
ever having a chance of working except possibly by chance.
(We all did this for so many years while kfreebsd was still a testing
migration blocker, so it's not like my suggestion is a new idea.)
HTH.
Regards,
Andreas Henriksson
[1]: https://github.com/shirou/gopsutil/pull/269
Bug#976509: golang-github-shirou-gopsutil: FTBFS: dh_auto_test: error: cd obj-aarch64-linux-gnu && go test -vet=off -v -p 4 github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu github.com/shirou/
Source: golang-github-shirou-gopsutil Version: 2.19.11-3 Severity: serious Justification: FTBFS on arm64 Tags: bullseye sid ftbfs Usertags: ftbfs-20201205 ftbfs-bullseye Hi, During a rebuild of all packages in sid, your package failed to build on arm64 (I don't know if it also fails on amd64). Relevant part (hopefully): > dpkg-buildpackage > - > > Command: dpkg-buildpackage -us -uc -sa -rfakeroot > dpkg-buildpackage: info: source package golang-github-shirou-gopsutil > dpkg-buildpackage: info: source version 2.19.11-3 > dpkg-buildpackage: info: source distribution unstable > dpkg-buildpackage: info: source changed by Shengjing Zhu > dpkg-source --before-build . > dpkg-buildpackage: info: host architecture arm64 > debian/rules clean > dh clean --buildsystem=golang --with=golang >dh_auto_clean -O--buildsystem=golang >dh_autoreconf_clean -O--buildsystem=golang >dh_clean -O--buildsystem=golang > dpkg-source -b . > dpkg-source: info: using source format '3.0 (quilt)' > dpkg-source: info: building golang-github-shirou-gopsutil using existing > ./golang-github-shirou-gopsutil_2.19.11.orig.tar.xz > dpkg-source: info: using patch list from debian/patches/series > dpkg-source: info: building golang-github-shirou-gopsutil in > golang-github-shirou-gopsutil_2.19.11-3.debian.tar.xz > dpkg-source: info: building golang-github-shirou-gopsutil in > golang-github-shirou-gopsutil_2.19.11-3.dsc > debian/rules binary > dh binary --buildsystem=golang --with=golang >dh_update_autotools_config -O--buildsystem=golang >dh_autoreconf -O--buildsystem=golang >dh_auto_configure -O--buildsystem=golang >dh_auto_build -O--buildsystem=golang > cd obj-aarch64-linux-gnu && go generate -v github.com/shirou/gopsutil > github.com/shirou/gopsutil/cpu github.com/shirou/gopsutil/disk > github.com/shirou/gopsutil/docker github.com/shirou/gopsutil/host > github.com/shirou/gopsutil/internal/common github.com/shirou/gopsutil/load > github.com/shirou/gopsutil/mem github.com/shirou/gopsutil/net > github.com/shirou/gopsutil/process > src/github.com/shirou/gopsutil/doc.go > src/github.com/shirou/gopsutil/cpu/cpu.go > src/github.com/shirou/gopsutil/cpu/cpu_linux.go > src/github.com/shirou/gopsutil/cpu/cpu_linux_test.go > src/github.com/shirou/gopsutil/cpu/cpu_test.go > src/github.com/shirou/gopsutil/disk/disk.go > src/github.com/shirou/gopsutil/disk/disk_linux.go > src/github.com/shirou/gopsutil/disk/disk_test.go > src/github.com/shirou/gopsutil/disk/disk_unix.go > src/github.com/shirou/gopsutil/docker/docker.go > src/github.com/shirou/gopsutil/docker/docker_linux.go > src/github.com/shirou/gopsutil/docker/docker_linux_test.go > src/github.com/shirou/gopsutil/host/host.go > src/github.com/shirou/gopsutil/host/host_linux.go > src/github.com/shirou/gopsutil/host/host_linux_arm64.go > src/github.com/shirou/gopsutil/host/host_linux_test.go > src/github.com/shirou/gopsutil/host/host_posix.go > src/github.com/shirou/gopsutil/host/host_test.go > src/github.com/shirou/gopsutil/host/types.go > src/github.com/shirou/gopsutil/internal/common/binary.go > src/github.com/shirou/gopsutil/internal/common/common.go > src/github.com/shirou/gopsutil/internal/common/common_linux.go > src/github.com/shirou/gopsutil/internal/common/common_test.go > src/github.com/shirou/gopsutil/internal/common/common_unix.go > src/github.com/shirou/gopsutil/load/load.go > src/github.com/shirou/gopsutil/load/load_linux.go > src/github.com/shirou/gopsutil/load/load_test.go > src/github.com/shirou/gopsutil/mem/mem.go > src/github.com/shirou/gopsutil/mem/mem_linux.go > src/github.com/shirou/gopsutil/mem/mem_test.go > src/github.com/shirou/gopsutil/net/net.go > src/github.com/shirou/gopsutil/net/net_linux.go > src/github.com/shirou/gopsutil/net/net_linux_test.go > src/github.com/shirou/gopsutil/net/net_test.go > src/github.com/shirou/gopsutil/process/process.go > src/github.com/shirou/gopsutil/process/process_linux.go > src/github.com/shirou/gopsutil/process/process_posix.go > src/github.com/shirou/gopsutil/process/process_posix_test.go > src/github.com/shirou/gopsutil/process/process_test.go > cd obj-aarch64-linux-gnu && go install -trimpath -v -p 4 > github.com/shirou/gopsutil github.com/shirou/gopsutil/cpu > github.com/shirou/gopsutil/disk github.com/shirou/gopsutil/docker > github.com/shirou/gopsutil/host github.com/shirou/gopsutil/internal/common > github.com/shirou/gopsutil/load github.com/shirou/gopsutil/mem > github.com/shirou/gopsutil/net github.com/shirou/gopsutil/process > internal/unsafeheader > github.com/shirou/gopsutil > internal/cpu > runtime/internal/atomic > runtime/internal/sys > internal/race > runtime/internal/math > internal/bytealg > sync/atomic > unicode > unicode/utf8 > encoding > math/bits > runtime > internal/testlog > math > unicode/utf16 > golang.org/x/sys/internal/unsafeheader > internal/nettrace > runtime/cgo > internal/reflectlite > sync > internal/singleflight > math/rand > errors > sort
