Sorry about this - I was hoping upstream's patches in latest release would have fixed this (the forwarded bug report is closed as such), but it seems these self-checks have some more work before they are ready.
I made it so that self-checks doesn't trigger FTBFS and all checks are wrapped in a "timeout" of max 15m runtime, see: https://salsa.debian.org/debian/guile-fibers/-/commit/225287f55d690f9a1fe04618a813d05e69ca969c I'm hoping this will move back the build/test time within reason. Maybe it can be tightened further, a build finishes within a minute or so on my laptop, but I suspect a busy armel server could be 10-15x as slow. /Simon Adrian Bunk <[email protected]> writes: > Control: severity -1 grave > Control: tags -1 ftbfs > Control: found -1 1.3.1-5 > > On Wed, Sep 10, 2025 at 08:11:07PM +0200, Simon Josefsson wrote: >> severity 1111954 normal >> forwarded 1111954 https://codeberg.org/fibers/fibers/issues/127 >> thanks >> >> As far as I can tell, all flaky debci checks have now been marked as >> flaky and does not trigger debci FAIL any more after 1.4.0-1, so I'm >> hoping we can lower the severity of this now. >> >> Fixing the flaky tests have been reported upstream: >> >> https://codeberg.org/fibers/fibers/issues/127 >> >> I suspect this may take time to fix, as it could be several different >> underlying bugs, and could be kernel/arch/libc-related. >> >> Builds are still flaky due to this problem, but the buildd's appear to >> re-schedule builds and eventually succeeds. > > These are manual give-backs. > > Please fix your package to build reliably. > >> We could silence 'make >> check' failure during builds too if necessary. I'm not sure what the >> best recommended way to deal with flaky build failures. Having them >> FAIL but eventually succeeds allows us to more easily catch which self >> checks and which platforms fail, which may result in some pattern >> developing, and help with upstream bug reporting. But if this is an >> annoyance we can do something like: >> >> override_dh_auto_test: >> -dh_auto_test >>... > > This won't work, since the build is killed. > > And what you have done in debci is also a huge waste of resources. > > "flaky" means a debci builder is blocked for 3 or 6 hours: > https://ci.debian.net/packages/g/guile-fibers/testing/ppc64el/ > https://ci.debian.net/packages/g/guile-fibers/testing/s390x/ > https://ci.debian.net/packages/g/guile-fibers/testing/riscv64/ > > Your test hangs are also blocking a buildd for 2.5 or 10 hours, > or a builder in the reproducible infrastructure for 18 hours: > https://tests.reproducible-builds.org/debian/history/guile-fibers.html > https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=riscv64 > https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=arm64 > https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=s390x > > When a release architecture has 2 buildds and you test hang blocks one > of them for 2.5 hours, then this architecture has lost half its buildds > for 2.5 hours. > > Implementing a per-test timeout with a small timeout per test inside > your package and then ignoring test failures might be OK, but please > stop blocking various kinds of builders for hours with hangs. > >> /Simon > > cu > Adrian
signature.asc
Description: PGP signature
