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
