Hi,

During a rebuild of all packages in sid, your package failed to build
on ppc64el. At the same time, it did not fail on amd64.

I'm marking this bug as severity:serious since your package has only
Architecture:all binary packages, and should thus, in theory, build
everywhere. Failure to build on ppc64el might indicate a serious issue
in this package or in another package.

But feel free to downgrade or close if you believe that this is only a
build-time issue. (I would personnally prefer a severity:minor bug just to
track that the package can only be built on specific architectures.)

Relevant part (hopefully):
http://qa-logs.debian.net/2020/12/09/golang-github-coreos-bbolt_1.3.5-1_unstable.log

A list of current common problems and possible solutions is available at
http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!

If you reassign this bug to another package, please marking it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with me
so that we can identify if something relevant changed in the meantime.

About the archive rebuild: The rebuild was done on a Power8 cluster part of the
Grid'5000 testbed. Hardware specs: https://www.grid5000.fr/w/Grenoble:Hardware#drac

Hello!
[...]
[...]

Apparently bbolt is a fork of boltdb, so please see my comments
on the equivalent bug report againt boltdb:
https://bugs.debian.org/976907


Relevant part:
 It seems the test-suite makes assumptions related to calculations that
 involve os.Getpagesize() (which gives 4096 on amd64 and 65536 on
 ppc64el, which is 16 times larger).
 Changing the 500 number to 8000 (16 times larger) in
 TestBucket_Stats(...) (in bucket_test.go:1143) gives the expected
 BranchPageN == 1 .... (however after that it then says
 "unexpected LeafPageN: 6" with this modification).

 In my opinion it's pretty clear that these are test-suite only
 issues and not issues in the actual product.


I would thus personally just disable the test-suite on !amd64 if no
porter is interested in fixing the testsuite (unless we agree this
issue simply can be downgraded to non-RC).

Regards,
Andreas Henriksson

Control: severity -1 import

I prefer to downgrade the severity. Just the test, not the library
itself is broken.