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