Hello Drew. I'd like to comment on this:
> * apply suggestion from Bug#1108309 to skip tests (build and > runtime) if less than 2 CPUs are available That was really a suggestion for the case where we could say with certainty that the tests need more than 2 CPUs to run successfully. Note that I said "Maybe the tests are buggy in a way [...]", this was really an hypothetical scenario, pending confirmation from upstream. But the build logs from buildd.debian.org which I quoted in my initial report, where the build fails with timeout: https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=all&ver=2.9.0-3&stamp=1744942413&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=amd64&ver=2.9.0-7&stamp=1745409028&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=arm64&ver=2.9.0-6&stamp=1745371276&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=armel&ver=2.9.0-8&stamp=1747011477&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=i386&ver=2.9.0-2&stamp=1744893854&raw=0 https://buildd.debian.org/status/fetch.php?pkg=mdanalysis&arch=mips64el&ver=2.9.0-4&stamp=1745023633&raw=0 happened on machines with more than 2 CPUs, so by skipping the tests if the number of CPUs is <= 2, we are certainly avoiding the problem in some scenarios where we know the tests are quite useless, but not in the buildds. So, to summarize, I don't think it was a good suggestion, and I'm sorry that I realized now. My preferred course of action at this point, in my humble opinion, would be to ask the RT for a trixie-ignore exception, wait for upstream to answer to the github issue, and implement the right fix only when we have it (if they reply soon, before the release of trixie, if they do not reply soon, using proposed-updates, to be included in a point release of trixie). Thanks.
