Dear maintainer:

During a rebuild of all packages in unstable, your package failed to build:
--------------------------------------------------------------------------------
[...]
testsuite/MDAnalysisTests/analysis/test_diffusionmap.py::test_long_traj PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_diffusionmap.py::test_updating_atomgroup PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_diffusionmap.py::test_not_universe_atomgroup_error PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_diffusionmap.py::test_DistanceMatrix_attr_warning PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_dihedrals.py::TestDihedral::test_dihedral[client_Dihedral0] PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_dihedrals.py::TestDihedral::test_dihedral_single_frame[client_Dihedral0] PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_dihedrals.py::TestDihedral::test_atomgroup_list[client_Dihedral0] PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_dihedrals.py::TestDihedral::test_enough_atoms[client_Dihedral0] PASSED [  1%]
testsuite/MDAnalysisTests/analysis/test_dihedrals.py::TestDihedral::test_dihedral_attr_warning[client_Dihedral0]
E: Build killed with signal TERM after 30 minutes of inactivity
--------------------------------------------------------------------------------

Notes:

- The way it fails is not always the same. I've put a collection of different build logs here:

https://people.debian.org/~sanvila/build-logs/202506/

- The build does not always fail, but the failure rate here is around 90% (tested on systems
with 2 CPUs), which makes it not to be suitable for release. However, for some reason,
the failure rate is only 20% on single-cpu systems, maybe this difference means something.

- I believe, but I can't check anymore, that the failure rate raised a lot when I switched
my autobuilders to trixie (i.e. when I started to use the kernel of trixie).

- This failure where the autobuilder hangs also happens on the buildds. Please see:

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

all of which end with a message like this:

E: Build killed with signal TERM after 150 minutes of inactivity

(In my build logs, I lowered the value to 30 minutes because I know that in normal
circumstances the package should take a lot less than that).

- There are also similar failures (autobuilder hang) in the reproducible-builds site:

https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/mdanalysis_2.9.0-8.rbuild.log.gz
https://tests.reproducible-builds.org/debian/logs/unstable/armhf/mdanalysis_2.8.0-4.build2.log.gz

- I have no idea of what's going on here, but as always, I can offer a VM to reproduce
(contact me privately for details).

Thanks.

Yeah, mdanalysis is generally flakey.
Not a whole lot we can do about it except run the tests again till they pass,
or keep skipping tests until the probability of failure is sufficiently reduced.

We believe that the bug you reported is fixed in the latest version of
mdanalysis, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1108309@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Drew Parsons <dparsons@debian.org> (supplier of updated mdanalysis package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Fri, 04 Jul 2025 10:23:27 +0200
Source: mdanalysis
Architecture: source
Version: 2.9.0-9
Distribution: unstable
Urgency: medium
Maintainer: Debichem Team <debichem-devel@lists.alioth.debian.org>
Changed-By: Drew Parsons <dparsons@debian.org>
Closes: 1108309
Changes:
 mdanalysis (2.9.0-9) unstable; urgency=medium
 .
   * debian/tests/control: mark mdanalysis with Restrictions: flaky.
     mdanalysis tests are generally unreliable and fail often and
     randomly. Closes: #1108309
   * debian/tests: skip tests observed failing in debci
     migration-reference runs:
     test_dihedral_attr_warning test_AnalysisFromFunction
     test_villin_unfolded test_rmsd_frames test_file_guess_hydrogens
     test_gnm_run_step test_all_backends_give_correct_results
     test_startframe test_hbond_analysis
Checksums-Sha1:
 526f51e7d7445edb17593caf3928431f65ea0c92 2970 mdanalysis_2.9.0-9.dsc
 50a1f259c15fa6dcd490b709690d582c621c4d0b 13516 mdanalysis_2.9.0-9.debian.tar.xz
 8e3e8bd85e0e76b4acadd9b14c5a9b26b9e47c5e 15888 mdanalysis_2.9.0-9_source.buildinfo
Checksums-Sha256:
 b5918fca126b45935a410d26c9cac39bf260744e3d8370dde4895af9eb411333 2970 mdanalysis_2.9.0-9.dsc
 c0b576ca475ab44db5891ece72a8b568d9f5311cd5a9d9205f086d0c70292d8f 13516 mdanalysis_2.9.0-9.debian.tar.xz
 a850ae31e616839ab403a09bf9b2f07bdbf17b855e2d4404149c01dd2dbfb895 15888 mdanalysis_2.9.0-9_source.buildinfo
Files:
 6cddd819103ce391de2fa5d38dd545f9 2970 python optional mdanalysis_2.9.0-9.dsc
 ef11611b1ccd68d2b0fa6b9de87f6592 13516 python optional mdanalysis_2.9.0-9.debian.tar.xz
 4b1097b2cb30f60ad0675b999c7b8773 15888 python optional mdanalysis_2.9.0-9_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQJIBAEBCgAyFiEEI8mpPlhYGekSbQo2Vz7x5L1aAfoFAmhnj8gUHGRwYXJzb25z
QGRlYmlhbi5vcmcACgkQVz7x5L1aAfrm5w//ZpuiDnVEarEmo6y8PtTHe8C1U3DX
11AkG1k5D2Xhxpb8iS/gcFYVjCtPzZ2Db+SEFeqk14zZ/jT9Q275/bgx5Z9VZ75u
Oj5vCBXWUBaYHM/jycKJPDNB2Yhg5oXl04te/8iBZuARqoJHfEBLsdrsKPb6MbXv
PQfWASMDpaWjfyH8AVnwWRFWiKDfnMHxqvUTJZ+QpENw2OxMQ99JdgVO291hM0kt
arqqIPpZvBRNOetQfScJeNBfxt22mlldmhqUWgsmbHMkGJPbY5RD1GQQhti/oAi1
FZB9/pzzBQujC4FoqprQqQJgzi3QklFEiGIkJDFeieNVj9v6zzaqNYuluRwIrNic
R1q/zjvozhhb6kQI5L1V8TuqjI+tYyOFlUR00E9mhUbOqpfVMDs3MusKB19z6MQG
sJItnB3TEAfjeTVvQz70XkyZIszdgSYjwqdbMYlbwv0GNQ4oIjzgwgATaspxPyfG
5Y9SMgoZqi9EAtp4gN7L070/TDARnuWj3uCj96vJWn4BpOp5v6OQktzfSo+u+pIT
s6TAxwx0ZfmmyFsz8kPiAQQeXTpSj0s4zkM95BaoR/AsPr2nj5IdVhXGzB5mA2FR
MjeEwa2UOZ5gnbIT/EFWxz1GT7oIRtx4yrEfa0hOtUsXjHtUUHsM+tVN/eTw1BGd
cRk+x5bYpvzQ4Gg=
=O59d
-----END PGP SIGNATURE-----

found 1108309 2.9.0-9
tags 1108309 patch
thanks

Hi. My autobuilders still hang when trying to build this package.
All the time, as in "tried 50 times and failed 50 times".
I've put recent build logs here:

https://people.debian.org/~sanvila/build-logs/202507/

Those build logs were produced using machines with 2 CPUs.
When using machines with one CPU, the failure rate is only 10%.

Some of the existing PRs here:

https://github.com/MDAnalysis/mdanalysis/pulls

read like "enable parallelization on XXX" or "enable parallelization on YYY".

Also, in page 2 of Issues:

https://github.com/MDAnalysis/mdanalysis/issues?page=2

there is a number of them saying "Implement parallelization or mark as unparallelizable".


I think this is an upstream bug. Maybe the tests are buggy in
a way that they need a minimum number of CPUs to run (probably
in an unintended way), and such number is unfortunately strictly
greater than 2. If that's the case, we (Debian) should be honest
and skip those tests when we know for sure that they will fail
(as in the (untested) attached patch).

But maybe I'm over-diagnosing this, and many of the functions that have
been modified "so that they run in parallel" do not really work ok
in parallel.

Can you please forward this upstream? (Or give me some hint about
how I should word the issue myself, as I have a github account).

Thanks.

     if [ $(shell nproc) -gt 2 ]; then etc

Thanks.

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.

Ok, I'm going to try that route.

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

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.

Thanks Santiago,  I appreciate your help improving the package.
Certainly good for everyone if we can find how to stop these random timeouts.

Drew

forwarded 1108309 https://github.com/MDAnalysis/mdanalysis/issues/5078
thanks

Hi. I've forwarded this to the above URL.
Thanks.

Hello Drew.

I'd like to comment on this:

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.

Santiago Vila wrote:


Ok, thanks for clarifying, Santiago.

In that case it's better for trixie to just skip all tests. That's
gotten done now with a debci ban, but that doesn't let us test any
movement from upstream (the ban prevents testing new code in
experimental).

So I'll upload -12 switching off tests for trixie.

Drew

We believe that the bug you reported is fixed in the latest version of
mdanalysis, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1108309@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Santiago Vila <sanvila@debian.org> (supplier of updated mdanalysis package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 24 May 2026 13:45:00 +0200
Source: mdanalysis
Architecture: source
Version: 2.10.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debichem Team <debichem-devel@lists.alioth.debian.org>
Changed-By: Santiago Vila <sanvila@debian.org>
Closes: 1108309
Changes:
 mdanalysis (2.10.0-2) unstable; urgency=medium
 .
   * Team upload.
   * Enable all tests again. The current version does not hang anymore.
     Thanks to Paul Gevers. Closes: #1108309.
   * Mark test_offset_lock_created as XFAIL.
   * Drop "Rules-Requires-Root: no" (default).
   * Drop "Priority: optional" (default).
   * Update standards-version.
Checksums-Sha1:
 cf770caf364e36946994eaf081ad9c69957c48e0 2920 mdanalysis_2.10.0-2.dsc
 f57d82cb331b961963dfec805753ad39ea36bca8 14848 mdanalysis_2.10.0-2.debian.tar.xz
 bcf6df7a484ff8ddc4ee1e4b1cc38a57bfd3f86d 8159 mdanalysis_2.10.0-2_source.buildinfo
Checksums-Sha256:
 ef6e3288b4bd6a95b15b59c81f3812929042b7d31b3d14e23684f9d2e6e52de3 2920 mdanalysis_2.10.0-2.dsc
 9b0d44e7eac852d1f5a2001254b62a76dc98aca1f97e294d0e644a869fc7ddee 14848 mdanalysis_2.10.0-2.debian.tar.xz
 19d3397bc7affbd4c071b9df55ed2b484d333c7a0c6cc15d329a3e43f6fe726f 8159 mdanalysis_2.10.0-2_source.buildinfo
Files:
 38e18e3e6a08bf03808d41c849814d4a 2920 python optional mdanalysis_2.10.0-2.dsc
 8b3d4788718343235463c8b17efbb1ba 14848 python optional mdanalysis_2.10.0-2.debian.tar.xz
 ea1a996df21a2c45ad7602ad17e1de61 8159 python optional mdanalysis_2.10.0-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE1Uw7+v+wQt44LaXXQc5/C58bizIFAmoS50IACgkQQc5/C58b
izJKAggAlX/pyeQmS5UKlWTAhP3TmYGQqodthoAFxsG/KQYXLHijSetYnxY1Ukb3
rR/QjUwhRpBwiHYoGnf9bbbStb5gLtATGEaNzWzpOncs/mIUVetTHxwlPb4JUwEw
wlReiRr7huZcVM+G6p4L/yV6KXiOPNnP3oTWghsHXmdr/CTqIajHqWCNB0/Xx9Oe
r0mwyZyuRd9qx068k6c/Ii4VtKEbb5h3E1oLRXx73Psg7z/8tBuFb+ts5/oVEqAp
rfRZ0ovGYew7n2H+Due2BRHcgso/AVCNaIjAMv/fbRBInqruMkNDFKTOgL1lEzie
3o1muFjEJw6e+8rf/nyI0K26Un00iA==
=e3jJ
-----END PGP SIGNATURE-----

reopen 1108309
thanks

I tested the package by doing this:

sbuild -d sid-unshare --chroot-mode=unshare mdanalysis_2.10.0-2.dsc

and the build ended successfuly, so I believed the hang issue was fixed.

But it still does not work in my autobuilding setup, which is essentially
the same as above, but sbuild is triggered by a script which
is just a child process of cron.

This is really weird.

Does the following error ring a bell for anybody reading this?

testsuite/MDAnalysisTests/analysis/test_rms.py::TestRMSD::test_custom_weighted[client_RMSD0] Fatal Python error: Segmentation fault

Current thread 0x00007f217c24e200 (most recent call first):
  Garbage-collecting
  File "/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_mdanalysis/build/MDAnalysis/coordinates/XDR.py", line 204 in close
  File "/<<PKGBUILDDIR>>/.pybuild/cpython3_3.13_mdanalysis/build/MDAnalysis/coordinates/base.py", line 1533 in __del__
  File "/usr/lib/python3.13/logging/__init__.py", line 1498 in debug
  File "/usr/lib/python3/dist-packages/duecredit/injections/injector.py", line 310 in __import
  File "/usr/lib/python3.13/multiprocessing/reduction.py", line 51 in dumps
  File "/usr/lib/python3.13/multiprocessing/queues.py", line 391 in put
  File "/usr/lib/python3.13/multiprocessing/pool.py", line 131 in worker
  File "/usr/lib/python3.13/multiprocessing/process.py", line 108 in run
  File "/usr/lib/python3.13/multiprocessing/process.py", line 313 in _bootstrap
  File "/usr/lib/python3.13/multiprocessing/popen_fork.py", line 74 in _launch
  File "/usr/lib/python3.13/multiprocessing/popen_fork.py", line 20 in __init__
  File "__init__", line ??? in __init__
  <invalid frame>

I guess I should forward this upstream again.

Thanks.

forwarded 1108309 https://github.com/MDAnalysis/mdanalysis/issues/5385
thanks

I closed the old github issue because I wrongly believed it was fixed,
but I'm still getting the hangs.

The above commands is so that the current Debian bug (which I'm
keeping the same for now) points to the new github issue.

Thanks.

This package used to fail 100% of the time in a reproducible way, but
at some point between 2026-05-24 and 2026-05-30, it started to work
again, and I have at least 30 successful builds after such date
without a single failure.

When I compare build logs, I see this difference:

reenable them again.

Thanks.

This package used to fail 100% of the time in a reproducible way, but
at some point between 2026-05-24 and 2026-05-30, it started to work
again, and I have at least 30 successful builds after such date
without a single failure.

When I compare build logs, I see this difference:

reenable them again.

Thanks.

Hi,


I ran the test 10 times, and it is neutral all times and takes about 15
minutes on amd64. The log worries me a bit though:
line 63: 11660 Segmentation fault         MPLBACKEND=agg $py -mpytest

But I guess that's why people want to run the test.

Paul

Hi Santiago,

* Santiago Vila <sanvila@debian.org> [2026-06-08 01:01]:

Thanks for working on this. The bug still affects
https://reproduce.debian.net/ as the buildinfo file references the old
version of python3-scipy:

https://reproduce.debian.net/all/forky.html#python-mdanalysis-doc

Could you upload a new revision?

Thanks!

Jochen

Done.