• Bug#1108309: mdanalysis: 1

    From Drew Parsons@21:1/5 to All on Sun Jul 6 13:20:01 2025
    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.

    * 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.


    In regards to the severity of this bug, the faiing 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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Santiago Vila@21:1/5 to Drew Parsons on Sun Jul 6 15:40:02 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)