Hello,
On Wed, Jan 08, 2025 at 02:33:38PM +0100, Diederik de Haas wrote:
> On Sun Aug 11, 2024 at 10:27 PM CEST, Sebastian Ramacher wrote:
> > Source: golang-google-grpc
> > Version: 1.64.0-6
> > Severity: serious
> > Tags: ftbfs
> > Justification: fails to build from source (but built successfully in the
> > past)
> > X-Debbugs-Cc: sramac...@debian.org
> >
> > https://buildd.debian.org/status/fetch.php?pkg=golang-google-grpc&arch=armhf&ver=1.64.0-6%2Bb1&stamp=1723387947&raw=0
>
> https://buildd.debian.org/status/logs.php?pkg=golang-google-grpc&ver=1.64.0-6%2Bb1
> lists the above mentioned build failure, but it also lists
> https://buildd.debian.org/status/fetch.php?pkg=golang-google-grpc&arch=armhf&ver=1.64.0-6%2Bb1&stamp=1723684906&raw=0
> which was run a couple of days later (2024-08-15) with
> Result: "Maybe-Successful", so is this a bug worth investigating or
> should it be attributed to 'phase-of-the-moon' type of cause?
>
> I haven't investigated what the difference between those logs is though.
In the failing build on armhf buildd, the same test is failing as is
this bug report - however there's no leakcheck output! (And I can't
really spot any output explaining why the test failed on the buildd)
> Same source on the same architecture (armhf), but only on a different
> buildd (arm-arm-01 vs arm-arm-03) may not warrant further investigation?
I've built the package repeatedly in an armhf chroot an
amdahl.debian.org and could not reproduce the problem.
Is anyone able to reproduce this issue?
If so, could you please check if poking at the previously mentioned
time.Sleep in leakcheck helps?
The "Leaked goroutine" message comes from internal/leakcheck/leakcheck.go
there's a
time.Sleep(50 * time.Millisecond)
If no, then I'd be happy to hear anyones but specially the bug
submitters opinion if we should close or downgrade the severity of this
bug?
(I'm not willing to upload /unconfirmed/ time.Sleep changes that might or
might not help make a test somewhat more robust. I am however willing to
completely disable testsuite for any package where people cling to RC
bugginess because sometimes testsuite fails unexpectedly and
unreproducibly. Please pick your poison.)
Regards,
Andreas Henriksson
