On Thu, Sep 18, 2025 at 02:50:31PM +0200, Simon Josefsson wrote: > 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.
No worries, I understand you were not aware what burden your package created for our infrastructure. > 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. buildds never build more than 1 package at a time, which makes build times usually quite predictable. armel (which is already for some time built on arm64 hw) is not slower than ppc64el here: https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=armel https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=ppc64el (Concurrency in Lisp might show performance patterns quite different from average packages.) 15 minutes is too tight on riscv64: https://buildd.debian.org/status/logs.php?pkg=guile-fibers&arch=riscv64 (Which is not a real problem when you are anyway ignoring failures.) All this is just a workaround for running tests with flaky hangs that should be fixed, really generous timeouts (or relying on buildd/debci timeouts) are OK when test hangs are a "never happens" event indicating some unexpected serious breakage.[1] > /Simon Thanks Adrian [1] a common problem timeouts is that they are often too low and then slow buildds hit them, which is why tight timeouts are usually not a good idea
