[Debichem-devel] Bug#1108309: mdanalysis: 1

[Santiago Vila]

On Sun, Jul 06, 2025 at 01:08:57PM +0200, Drew Parsons wrote:
> Source: mdanalysis
> Followup-For: Bug #1108309
> 
> Upstream has no* special requirements for their bug reports, so please
> do file with them directly at
> https://github.com/MDAnalysis/mdanalysis/issues
> 
> It's actually a good idea to do that, because they'll be able to
> discuss directly what their intentions are for multiprocessor testing,
> compared to the conditions that you (and debci) are using in our testing.
> They are proud of their code and they want their tests to pass
> reliably, so it can be a constructive dialogue with them.

Ok, I'm going to try that route.

> * the only catch is that they release regularly, so our debian version
> is a little behind the latest upstream release.  There may be
> improvements they've already made they we haven't caught yet.
> But the problems with their tests are longstanding, so I think it's
> still worth filing the issue with them.

Ok, even if we are a little bit behind, we can always try to backport
whatever fixes they implement.

> In regards to the severity of this bug, the failing tests will no longer
> block migration to testing after marking them with Restriction: flakey.
> So in that regard this issue is Severity: important not Severity: serious,
> unless you prefer to mean severity "serious" in the sense that trixie
> shouldn't be providing the package even with tests marked flakey.

Well, I did not file this bug because of flaky tests in ci.debian.net,
but because the end user who wants to build the package from source
may easily find that the autobuilder hangs (because of timeout)
and the package does not build from source.

That's worse than having flaky tests and I think it should never happen
in a stable release. I see that Paul Gevers (from RT) is already filing
some bugs with trixie-ignore tag, and I think it is likely that he will
apply trixie-ignore to this bug as well, usually with the meaning
of "this bug will not delay the release nor will make the package
to be autoremoved, but please keep trying to fix it in trixie
if you can".

I think that's what we should do. If we can't fix it before
the release, I would be willing to prepare an upload
for proposed-updates once that we have a proper fix
in unstable.

Thanks.