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.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)