reopen 1088010 thanks Hi. I don't think this is a "third party issue".
This build failure happens randomly, with different probability depending on the build machine. For example, on AWS instances of type m7a.large or r7a.large, I get a failure rate around 25%. I think this is bad enough to consider the failing tests as flaky and disable them, as they can't be trusted. When a failure happens randomly but we still think it's all or nothing, we can end up considering the issue as fixed just because we saw a single successful build. But that's a problem, because we can't really tell that a dice is tainted just by throwing it once or twice. I would hope that we still don't want packages which FTBFS randomly in the buildds. A single successful build does not mean that the randomness has disappeared. If you need a VM to reproduce, please contact me privately and I will gladly provide one. Alternatively, you can take a look at the build logs I've collected in the last weeks: https://people.debian.org/~sanvila/build-logs/nng/ A simple statistic: 98 34 - nng.sp.transport.socket.sockfd_test (Failed) 47 73 - nng.wss (Subprocess aborted) 20 61 - nng.multistress (SEGFAULT) 10 64 - nng.pipe (Failed) 10 61 - nng.multistress (Subprocess aborted) 4 75 - nng.reqstress (Subprocess aborted) 1 73 - nng.wss (Timeout) (First column is the number of occurrences I found after building the package many times) I suggest that the tests which are more likely to fail are disabled, as they can't be trusted. Note: I'm just reopening the bug because I believe it's not fixed. The Release Managers have always the final say about the RC status. Thanks.
