On 9/2/26 14:48, Jeremy Bícha wrote:
Control: reopen -1

I'm reopening this bug because the current package in Debian Unstable
still has || true at the end of the dh_auto_test lines which means
that test failures are ignored. It looks like a few of the tests pass
sometimes but not reliably.

That's fine (and known). I think the way to do this for now would be to fail if there's more than 1 test failure. Otherwise, assume there will likely be a race-related test failure somewhere. I've seen other packages do this (I'm thinking llvm or rust, I forget which one). That's assuming we can't narrow down the specific racy tests to disable, but I think we'll need more package uploads before we spot the pattern.

Long-term we'd obviously like to actually fix the races, but I'm still waiting for upstream to even look at my Qt6 and deprecated-warning-fixes merge requests.



I think dh_auto_test should fail the build when build tests fail so in
Salsa, I removed || true

I had also removed your -j1 change because from what I can see,
parallel running doesn't increase the failure rate. However, I
restored dh_auto_test --no-parallel because you complained and because
it makes it easier to read the failing test logs.

What I see on my end is that 2 tests in particular will conflict with each other and cause the entire test process to deadlock and hang until it finally times out*. Not a great thing to happen on a buildd, and also super annoying locally when kicking off a build, switching to another workspace, and coming back to it a few minutes later expecting packages but instead finding a hung process.

* as a side note, the test timeout limit should probably be shortened to make this less painful when it happens.


I did notice that s390x appears to have at least one additional test
failure compared to other release architectures. I updated
debian/rules to ignore s390x build test failures since it is an
irrelevant architecture for Debian Lomiri's needs.

One workaround is to skip individual tests that aren't reliable.

Thank you,
Jeremy Bícha

Reply via email to