Package: src:tendermint-go-flowrate
Version: 0.0~git20161104.0.a20c98e-1
Severity: important
Dear maintainer:
I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:
--------------------------------------------------------------------------------
[...]
debian/rules build-indep
dh build-indep --buildsystem=golang --with=golang
dh_testdir -i -O--buildsystem=golang
dh_update_autotools_config -i -O--buildsystem=golang
dh_auto_configure -i -O--buildsystem=golang
dh_auto_build -i -O--buildsystem=golang
go install -v -p 1 github.com/tendermint/go-flowrate/flowrate
github.com/tendermint/go-flowrate/flowrate
dh_auto_test -i -O--buildsystem=golang
go test -v -p 1 github.com/tendermint/go-flowrate/flowrate
=== RUN TestReader
--- PASS: TestReader (0.45s)
=== RUN TestWriter
--- FAIL: TestWriter (0.51s)
io_test.go:140: w.Status(0) expected {true 2017-01-02 20:57:40.72 +0000
UTC 400ms 0s 80 4 200 200 200 200 20 100ms 80.000%}; got {true 2017-01-02
20:57:40.72 +0000 UTC 420ms 0s 80 4 200 197 190 200 20 100ms 80.000%}
io_test.go:140: w.Status(1) expected {true 2017-01-02 20:57:40.72 +0000
UTC 500ms 100ms 100 5 200 200 200 200 0 0s 100.000%}; got {true 2017-01-02
20:57:40.72 +0000 UTC 520ms 100ms 100 5 200 197 192 200 0 0s 100.000%}
FAIL
exit status 1
FAIL github.com/tendermint/go-flowrate/flowrate 0.962s
dh_auto_test: go test -v -p 1 github.com/tendermint/go-flowrate/flowrate
returned exit code 1
debian/rules:4: recipe for target 'build-indep' failed
make: *** [build-indep] Error 1
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2
--------------------------------------------------------------------------------
This is just how the build ends, not necessarily the relevant part.
I've put several build logs here:
https://people.debian.org/~sanvila/tendermint-go-flowrate/
If this is really a bug in one of the build-depends, please use reassign and
affects,
so that this is still visible in the page for this package.
The bug should be reproducible with sbuild on a single CPU virtual machine,
provided you try enough times (as the failure happens randomly).
After building 200 times, the failure rate observed here is about 10%.
Thanks.
