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.)
HTH.
Regards,
Andreas Henriksson
[1]: https://github.com/shirou/gopsutil/pull/269
