Hi On 2025-01-09 08:05:56 +0000, ah wrote: > 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 don't mind if it is closed if the issues was temporary. In case the issue reappears on the buildds, I'd file a new bug. Cheers > > (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 -- Sebastian Ramacher
