Bug#1071722: adios4dolfinx: FTBFS: failing tests
Source: adios4dolfinx Followup-For: Bug #1071722 Control: tags -1 ftbfs adios4dolfinx is building cleanly in reproducibility builds. Perhaps the problem was a temporary glitch on your test system?
Bug#1070894: slepc: FTBFS: Fatal Error: Cannot open module file ‘slepcmfn.mod’ for reading at (1): No such file or directory
Source: slepc Followup-For: Bug #1070894 Control: tags -1 ftbfs fixed-upstream Control: forwarded -1 https://gitlab.com/slepc/slepc/-/issues/83 Fixed upstream in 3.20.2, https://gitlab.com/slepc/slepc/-/merge_requests/639
Bug#1069321: FTBFS: [Makefile:163: check] Error 1
Source: hypre Followup-For: Bug #1069321 It's passing in reproducibility rebuilds. Perhaps it was a transitory glitch.
Bug#1069321: FTBFS: [Makefile:163: check] Error 1
Source: hypre Followup-For: Bug #1069321 Control: tags -1 ftbfs hypre is passing debci and reproducibility tests on armhf. Looks like the error reported here was a transitory issue, possibly related to openmpi upgrades.
Bug#1063409: marked as pending in mpi4py
Control: tag -1 pending Hello, Bug #1063409 in mpi4py reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/science-team/mpi4py/-/commit/db1d69cffc738b23899e8dafbf4c0cd4b2f8d373 add debian patch intersphinx_use_local_inventory.patch uses python3 docs when building docs. Thanks Zixing Liu from Canonical. Closes: #1066837, #1063409 (this message was generated automatically) -- Greetings https://bugs.debian.org/1063409
Bug#1066837: marked as pending in mpi4py
Control: tag -1 pending Hello, Bug #1066837 in mpi4py reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/science-team/mpi4py/-/commit/db1d69cffc738b23899e8dafbf4c0cd4b2f8d373 add debian patch intersphinx_use_local_inventory.patch uses python3 docs when building docs. Thanks Zixing Liu from Canonical. Closes: #1066837, #1063409 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066837
Bug#1066449: mpi4py: FTBFS: Segmentation fault in tests
Source: mpi4py Followup-For: Bug #1066449 Control: tags -1 ftbfs The bug report stopped scanning at the first "error", which is not an error (it's a check). The last error is the relevant one testIReadIWrite (test_io.TestIOSelf.testIReadIWrite) ... ok testIReadIWriteAll (test_io.TestIOSelf.testIReadIWriteAll) ... [ip-10-84-234-105:152676] *** Process received signal *** [ip-10-84-234-105:152676] Signal: Segmentation fault (11) [ip-10-84-234-105:152676] Signal code: Address not mapped (1) [ip-10-84-234-105:152676] Failing at address: (nil) [ip-10-84-234-105:152676] [ 0] /lib/x86_64-linux-gnu/libc.so.6(+0x3c510)[0x7f7a3a86f510] [ip-10-84-234-105:152676] *** End of error message *** Segmentation fault Possibly a transitory inconsistency caught in the middle of an openmpi update.
Bug#1069432: mpi4py: FTBFS on armhf: ld: cannot find -llmpe: No such file or directory
Source: mpi4py Followup-For: Bug #1069432 There have been ongoing issues with OpenMPI on 32-bit architectures, partly related to drop of 32-bit support by pmix. This bug is likely related to that i.e. not a bug in mpi4py itself.
Bug#1069377: scipy: FTBFS on arm64: make[1]: *** [debian/rules:161: execute_after_dh_auto_install] Error 1
Source: scipy Followup-For: Bug #1069377 Control: tags -1 ftbfs This is an odd error. Looks as if the behaviour changed in respect to which exception gets emitted. There's a new release needing to get packaged. Likely it resolves the issue.
Bug#1069106: openmpi: 32 bit pmix_init:startup:internal-failure: help-pmix-runtime.txt: No such file
Source: openmpi Version: 4.1.6-12 Followup-For: Bug #1069106 Control: reopen 1069106 4.1.6-12 was intended to fix this bug, but it's still occuring e.g. https://ci.debian.net/packages/o/openmpi/unstable/i386/45630865/ https://ci.debian.net/packages/o/openmpi/unstable/armhf/45630866/
Bug#1062405: dolfin: NMU diff for 64-bit time_t transition
Source: dolfin Followup-For: Bug #1062405 Control: severity 1062405 testing Control: tags 1062405 moreinfo This time_t patch was never applied. Is it not needed after all? Can we close this bug now?
Bug#1069106: openmpi: 32 bit pmix_init:startup:internal-failure: help-pmix-runtime.txt: No such file
Source: openmpi Version: 4.1.6-9 Severity: serious Justification: ftbfs Control: affects -1 src:fenics-dolfinx src:petsc openmpi 4.1.6-9 is failing its own tests on 32-bit systems, presumeably after they were configuring to use a local copy of pmix instead of libpmix-dev. For instance on i386 https://ci.debian.net/data/autopkgtest/unstable/i386/o/openmpi/45463906/log.gz the error message is 69s autopkgtest [12:19:13]: test compile_run_mpicc: [--- 69s -- 69s Sorry! You were supposed to get help about: 69s pmix_init:startup:internal-failure 69s But I couldn't open the help file: 69s /usr/share/pmix/help-pmix-runtime.txt: No such file or directory. Sorry! 69s -- 69s [ci-107-5e0ffbcf:02362] PMIX ERROR: NOT-FOUND in file ../../../../../../../../opal/mca/pmix/pmix3x/pmix/src/server/pmix_server.c at line 237 The same error affects builds and debci testing of client packages on the 32 bit architectures, e.g. petsc, dolfinx
Bug#1062383: dolfinx-mpc: NMU diff for 64-bit time_t transition
Source: dolfinx-mpc Followup-For: Bug #1062383 Control: severity 1062383 important Control: tags 1062383 moreinfo This patch was never applied. Do we not need it after all? Can we close this bug now?
Bug#1062587: fenics-dolfinx: NMU diff for 64-bit time_t transition
Source: fenics-dolfinx Followup-For: Bug #1062587 Control: severity 1062587 important Control: tags 1062587 moreinfo This time_t patch was never applied. I presume it's not needed after all and we can close this bug now?
Bug#1067784: Doesn't contain libpmix.so.2
Package: libpmix2t64 Version: 5.0.2-2 Followup-For: Bug #1067784 Control: affects 1067784 nwchem nwchem-openmpi Control: reopen 1067784 Looks like 5.0.2-2 annihilated the symlink fix made in 5.0.2-1.1 See nwchem tests, https://ci.debian.net/packages/n/nwchem/unstable/amd64/44696719/ 90s Running tests/cosmo_h3co/cosmo_h3co 90s 90s cleaning scratch 90s copying input and verified output files 90s running nwchem (/usr/bin/nwchem) with 1 processors 90s 90s NWChem execution failed 90s [ci-096-a6a59e1f:01975] mca_base_component_repository_open: unable to open mca_pmix_ext3x: libpmix.so.2: cannot open shared object file: No such file or directory (ignored) 90s [ci-096-a6a59e1f:01975] [[33167,0],0] ORTE_ERROR_LOG: Not found in file ../../../../../../orte/mca/ess/hnp/ess_hnp_module.c at line 320 90s -- 90s It looks like orte_init failed for some reason; your parallel process is 90s likely to abort. There are many reasons that a parallel process can 90s fail during orte_init; some of which are due to configuration or 90s environment problems. This failure appears to be an internal failure; 90s here's some additional information (which may only be relevant to an 90s Open MPI developer): 90s 90s opal_pmix_base_select failed 90s --> Returned value Not found (-13) instead of ORTE_SUCCESS -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpmix2t64 depends on: ii libc6 2.37-15.1 ii libevent-core-2.1-7t64 2.1.12-stable-8.1+b1 ii libevent-pthreads-2.1-7t64 2.1.12-stable-8.1+b1 ii libhwloc-plugins2.10.0-1+b1 ii libhwloc15 2.10.0-1+b1 ii libmunge2 0.5.15-4 ii zlib1g 1:1.3.dfsg-3.1 libpmix2t64 recommends no packages. libpmix2t64 suggests no packages. -- no debconf information
Bug#1067308: python-meshplex: FTBFS: dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p "3.12 3.11" --test-args=--ignore-glob=\*test_io\* returned exit code 13
Source: python-meshplex Followup-For: Bug #1067308 Control: tags -1 ftbfs I can't reproduce this error now. It must have been resolved by a separate library transition, or possibly a numpy update. If 0.17.1-3 passes tests successfully then we can close this bug.
Bug#1064749: pymatgen: FTBFS: make[1]: *** [debian/rules:104: override_dh_auto_test] Error 1
Source: pymatgen Followup-For: Bug #1064749 Control: tags -1 ftbfs I can't reproduce this error. See also https://buildd.debian.org/status/fetch.php?pkg=pymatgen=amd64=2024.1.27%2Bdfsg1-7=1708967242=0 https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/pymatgen_2024.1.27+dfsg1-7.rbuild.log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/p/pymatgen/43357166/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/p/pymatgen/43355416/log.gz test_quasiharmonic_debye_approx is passing on all systems. I think we can close this bug.
Bug#1066972: rust-python-pkginfo: FTBFS on mips64el: missing librust-rfc2047-decoder-0.2+default-dev
Source: rust-python-pkginfo Version: 0.5.5-1 Severity: serious Tags: ftbfs Justification: FTBFS rust-python-pkginfo is failing to build on mips64el due to a missing librust-rfc2047-decoder-0.2+default-dev Indeed, there is no librust-rfc2047-decoder-0.2+default-dev package. Should the Build dependency be removed? The bug prevents python-maturin from building on mips64el, which in turn prevents a long chain of packages from building and migrating to testing. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1065323: petsc: bad Provides in libpetsc64-real3.19t64, libpetsc64-complex3.19t64 and libpetsc-real3.19t64
Source: petsc Followup-For: Bug #1065323 petsc has a complex set of symlink farms since it needs to enable multiple alternative build profiles. I'll implement the patch in a way that doesn't let t64 get in the way of updating subsequently (to 3.20 in the near future). Drew
Bug#1064224: python-hmmlearn: fails variational gaussian tests with sklearn 1.4
Source: python-hmmlearn Version: 0.3.0-3 Severity: serious Justification: debci python-hmmlearn is failing variational_gaussian tests (test_fit_mcgrory_titterington1d) with sklearn 1.4. This comment upstream is relevant: https://github.com/hmmlearn/hmmlearn/issues/539#issuecomment-1871436258 It's likely fixed in upstream PR#531 https://github.com/hmmlearn/hmmlearn/pull/531 If not, then I'd suggest skipping test_fit_mcgrory_titterington1d until there's a better fix upstream. PR#545 might also be generally helpful.
Bug#1064223: imbalanced-learn: fails tests with sklearn 1.4: needs new versions
Source: imbalanced-learn Version: 0.10.0-2 Severity: serious Justification: debci imbalanced-learn 0.10 fails tests with sklearn 1.4. The problem is fixed upstrema with v0.12.
Bug#1064038: masakari: fails TestObjectVersions.test_versions
Source: masakari
Version: 16.0.0-2
Severity: serious
Justification: debci
Control: affects -1 src:sphinx src:python-skbio src:scipy
masakari has started failing tests:
229s FAIL:
masakari.tests.unit.objects.test_objects.TestObjectVersions.test_versions
229s masakari.tests.unit.objects.test_objects.TestObjectVersions.test_versions
229s --
229s testtools.testresult.real._StringException: Traceback (most recent call
last):
229s File
"/tmp/autopkgtest-lxc.qzstlq9s/downtmp/build.m9a/src/masakari/tests/unit/objects/test_objects.py",
line 721, in test_versions
229s self.assertEqual(expected, actual,
229s File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 394,
in assertEqual
229s self.assertThat(observed, matcher, message)
229s File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 481,
in assertThat
229s raise mismatch_error
229s testtools.matchers._impl.MismatchError: !=:
229s reference = {'FailoverSegmentList': '1.0-dfc5c6f5704d24dcaa37b0bbb03cbe60',
229s 'HostList': '1.0-25ebe1b17fbd9f114fae8b6a10d198c0',
229s 'NotificationList': '1.0-25ebe1b17fbd9f114fae8b6a10d198c0',
229s 'VMoveList': '1.0-63fff36dee683c7a1555798cb233ad3f'}
229s actual= {'FailoverSegmentList': '1.0-d4308727e4695fb16ecb451c81ab46e8',
229s 'HostList': '1.0-347911fa6ac5ae880a64e7bb4d89a71f',
229s 'NotificationList': '1.0-347911fa6ac5ae880a64e7bb4d89a71f',
229s 'VMoveList': '1.0-25a6ab4249e4a10cb33929542ff3c745'}
229s : Some objects have changed; please make sure the versions have been
bumped, and then update their hashes here.
The test failure is preventing sphinx migration to testing,
which in turn is blocking other packages from migrating
(python-skbio, which blocks scipy)
Bug#1063752: custodian: Inappriate maintainer address
Source: custodian Followup-For: Bug #1063752 X-Debbugs-Cc: Debichem Team Control: reassign 1063752 lists.debian.org Control: affects 1063752 src:custodian Scott Kitterman reported that lists.alioth.debian.org is bouncing emails from debian official addresses (ftpmas...@ftp-master.debian.org in this case, processing packages for the Debichem team with Maintainer address debichem-de...@lists.alioth.debian.org) Scott filed the bug against src:custodian, but the bug must be in the mailing list daemon, so I'm reassigning the bug to lists.debian.org
Bug#1063752: custodian: Inappriate maintainer address
Source: custodian Followup-For: Bug #1063752 I am confused by this bug report. The debichem Maintainer address used for custodian is the same as that used for any other debichem package. No problems were reported for the other packages.
Bug#1060971: mdtraj: FTBFS: dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 2
Source: mdtraj Followup-For: Bug #1060971 X-Debbugs-Cc: 1060971-d...@bugs.debian.org Control: fixed 1060971 1.9.9-1 Fixed with cython3-legacy at the same time the bug was filed.
Bug#1061385: Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates
Hi Maytham, golang-github-googleapis-enterprise-certificate-proxy is now built on the main architectures. https://buildd.debian.org/status/package.php?p=golang-github-googleapis-enterprise-certificate-proxy It's still not building on the auxiliary architectures. Can you see a way of extending or altering the patch for them as well? Drew
Bug#1062356: adios2: flaky autopkgtest (host dependent): times out on big host
Source: adios2 Followup-For: Bug #1062356 The flakey test is adios2-mpi-examples. debian/tests is building and running them manually, and running on only 3 processors (mpirun -n 3) So the problem can't be overload of the machine. I'll just skip insituGlobalArraysReaderNxN_mpi. For reference, upstream is making some changes to make it more reliable to run tests against the installed library, https://github.com/ornladios/ADIOS2/pull/3906 also https://github.com/ornladios/ADIOS2/pull/3820 Not certain that that directly makes insituGlobalArraysReaderNxN_mpi more reliable though.
Bug#1062356: adios2: flaky autopkgtest (host dependent): times out on big host
Source: adios2 Followup-For: Bug #1062356 Can't be quite as simple as just the host machine. https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41403641/log.gz completed in 9 minutes, while https://ci.debian.net/data/autopkgtest/unstable/amd64/a/adios2/41496866/log.gz failed with timeout. But that was ci-worker13 in both cases. Maybe it's a race condition. Might be simplest to just skip insituGlobalArraysReaderNxN_mpi though I can also review how many CPUs are invoked by the test. Usually safer not to run tests on all 64 available cpus, for instance, if there are that many on the machine.
Bug#1061605: scipy: tests skipped during build and autopkgtest not in sync
Source: scipy Followup-For: Bug #1061605 Note that debci tests are passing on all arches (where built) for scipy 11. I'm inclined to accept this as a solution. i.e. update the list of builds tests to skip for scipy 11 rather than reorganise debian/tests skips for scipy 10.
Bug#1053939: pymatgen: test failure with pandas 2.1
Source: pymatgen Followup-For: Bug #1053939 [apologies for the spam. testing mail server configuration now]
Bug#1053939: pymatgen: test failure with pandas 2.1
Source: pymatgen Followup-For: Bug #1053939 Looks like the latest release should be fine with pandas 2. Currently building in experimental.
Bug#1061605: scipy: tests skipped during build and autopkgtest not in sync
Source: scipy Followup-For: Bug #1061605 Easy enough to relax tolerances or skip tests if we needed to. test_maxiter_worsening was giving problems on other arches. But strange the test only started failing when pythran was deactivated. I've reactivated it in 1.10.1-8, we'll see if it restores success.
Bug#1061385: marked as pending in golang-github-google-go-pkcs11
Control: tag -1 pending Hello, Bug #1061385 in golang-github-google-go-pkcs11 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/commit/ad679e8937a483782280e17711c2b1c85feaa9a0 add debian patch use-uint-for-32-bit-builds.patch adapts build for 32-bit architectures Closes: #1061385 (this message was generated automatically) -- Greetings https://bugs.debian.org/1061385
Bug#1061385: Bug#1024276: ITP: golang-github-googleapis-enterprise-certificate-proxy -- Google Proxies for Enterprise Certificates
On 2024-01-23 14:39, Maytham Alsudany wrote: Hi Drew, On Tue, 2024-01-23 at 11:24 +0100, Drew Parsons wrote: > > Hi Maytham, I can upload it. But note how pkcs11 is failing on 32 bit > > arches. That needs to be sorted out. I had been waiting for that > > before uploading enterprise-certificate-proxy. > > https://salsa.debian.org/go-team/packages/golang-github-google-go-pkcs11/-/merge_requests/2 > > go-pkcs11 builds successfully and passes autopkgtest, lintian, and > piuparts on > both amd64 and i386. The problem is on debci. See the failing tests at https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/ summarised also at https://tracker.debian.org/pkg/golang-github-google-go-pkcs11 I'm aware, and the PR I've linked is a fix, please have a look. You can look at the patch file itself at [1] (have a look at the description to understand what the PR/patch does). Thanks Maytham. The patch handling it via malloc_arg makes sense. I left a review commenting about supporting other 32 bit architectures, not just 386 and arm. I can see how to adapt your patch to control it at build time. Let me know if you're happy with that idea or if you can see another way to do it. (an alternative could be checking bits, along the lines of "const PtrSize = 32 << uintptr(^uintptr(0)>>63)" But I wouldn't necessarily trust that to always give the right indication. Your idea of handling two separate definitions should work fine) Drew
Bug#1061385: golang-github-google-go-pkcs11: tests fail on 32 bit architectures
Source: golang-github-google-go-pkcs11 Version: 0.3.0+dfsg-1 Severity: serious Justification: debci Control: block 1024276 by -1 go-pkcs11 tests are failing on 32-bit architectures (armel, armhf, i386), see https://ci.debian.net/packages/g/golang-github-google-go-pkcs11/ This is preventing migration to testing, see https://tracker.debian.org/pkg/golang-github-google-go-pkcs11 and therefore blocking processing of golang-github-googleapis-enterprise-certificate-proxy Excerpt from the test log for i386 reports ... 79s crypto/x509 79s github.com/google/go-pkcs11/pkcs11 82s # github.com/google/go-pkcs11/pkcs11 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:300:33: cannot use (_Ciconst_sizeof_CK_UTF8CHAR) * _Ctype_ulong(len(s)) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1019:38: cannot use _Ctype_ulong(n) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1100:33: cannot use attrs[0].ulValueLen * (_Ciconst_sizeof_CK_BYTE) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1104:33: cannot use attrs[1].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1137:37: cannot use attrs[0].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1141:37: cannot use attrs[1].ulValueLen (variable of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s src/github.com/google/go-pkcs11/pkcs11/pkcs11.go:1440:35: cannot use _Ctype_ulong(n) (value of type _Ctype_ulong) as _Ctype_uint value in argument to (_Cfunc__CMalloc) 82s dh_auto_build: error: cd _build && go install -trimpath -v -p 2 github.com/google/go-pkcs11/pkcs11 returned exit code 1
Bug#1056841: pymatgen: ftbfs with cython 3.0.x
On 2024-01-19 18:52, Drew Parsons wrote: Hi Andreas, could you push your upstream and pristine-tar branches? Otherwise we can't use your 2023.12.18 branch. I see what you mean. The tag is there, the orig tarball can be regenerated with gbp export-orig.
Bug#1058040: pymatgen: FTBFS with Python 3.12
Source: pymatgen Followup-For: Bug #1058040 No, other way around. The new monty is causing the problem. Will need to patch or upgrade pymatgen.
Bug#1058040: pymatgen: FTBFS with Python 3.12
Source: pymatgen Followup-For: Bug #1058040 Sounds like it will need the new version of monty
Bug#1056841: pymatgen: ftbfs with cython 3.0.x
On 2024-01-16 17:55, Andreas Tille wrote: Control: tags -1 pending Hi, I've applied the patch in Git and also tried to upgrade to latest upstream since there is a chance that other Python3.12 issues might be fixed. Unfortunately the upgrade is all but straightforward and I gave up finally over the changes in the sphinx documention where finally some files are missing. I've created a branch 2023.12.18 which fails with Sphinx error: root file /build/pymatgen-2023.12.18+dfsg1/docs/apidoc/index.rst not found I hope that my preliminary work might be helpful for the package but I have to give up now due to time constraints. Hope this helps Andreas. Hi Andreas, could you push your upstream and pristine-tar branches? Otherwise we can't use your 2023.12.18 branch. Drew
Bug#1061063: armhf: h5py's tests expose unaligned memory accesses during the build
Source: h5py Followup-For: Bug #1061063 Control: forwarded 1061063 https://github.com/h5py/h5py/issues/1927 The problem was raised upstream at https://github.com/h5py/h5py/issues/1927 Makes it difficult to test if we can't reproduce it on all armhf environments. A patch was suggested for the upstream report but has already been applied (fix-unaligned-access.patch). I'm not sure that we can do much more than that, since we can't reproduce the bug on debian armhf systems.
Bug#1058122: python-griddataformats: FTBFS: AttributeError: module 'configparser' has no attribute 'SafeConfigParser'. Did you mean: 'RawConfigParser'?
Source: python-griddataformats Followup-For: Bug #1058122 THanks for the patch, Yogeswaran. Upstream has fixed it in their latest release however.
Bug#1058122: marked as pending in python-griddataformats
Control: tag -1 pending Hello, Bug #1058122 in python-griddataformats reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/python-griddataformats/-/commit/259b08e1c7c28c8dd669f960f86b0badfe6297fd mark new upstream release in changelog new release fixes configparser. Closes: #1058122. (this message was generated automatically) -- Greetings https://bugs.debian.org/1058122
Bug#1056841: pymatgen: ftbfs with cython 3.0.x
On 2024-01-16 17:55, Andreas Tille wrote: Control: tags -1 pending Hi, I've applied the patch in Git and also tried to upgrade to latest upstream since there is a chance that other Python3.12 issues might be fixed. Unfortunately the upgrade is all but straightforward and I gave up finally over the changes in the sphinx documention where finally some files are missing. I've created a branch 2023.12.18 which fails with Sphinx error: root file /build/pymatgen-2023.12.18+dfsg1/docs/apidoc/index.rst not found I hope that my preliminary work might be helpful for the package but I have to give up now due to time constraints. Hope this helps Andreas. Thanks Andreas. It has a few moving parts, all should be upgraded together. That's partly why I haven't got round to it yet. Upgrading to latest upstream versions is probably the way to do it. We'll get it done before next stable release. Drew
Bug#1057949: nbconvert: needs update for new version of pandoc: PDF creating failed
Source: nbconvert Version: 6.5.3-4 Followup-For: Bug #1057949 An nbconvert update (>= 7.6) is also needed to support the latest version of pandoc 3.1.3. That is, to avoid the warning that pandoc 3.1.3 is "unsupported". cf. https://github.com/spatialaudio/nbsphinx/issues/750#issuecomment-1613973946
Bug#1060804: hickle: failing tests with h5py 3.10
Source: hickle Version: 5.0.2-7 Severity: serious Justification: debci h5py 3.10 is triggering test failure in hickle 54s test_H5NodeFilterProxy 54s 54s h5_data = 54s 54s def test_H5NodeFilterProxy(h5_data): 54s """ 54s tests H5NodeFilterProxy class. This class allows to temporarily rewrite 54s attributes of h5py.Group and h5py.Dataset nodes before being loaded by 54s hickle._load method. 54s """ 54s 54s # load data and try to directly modify 'type' and 'base_type' Attributes 54s # which will fail cause hdf5 file is opened for read only 54s h5_node = h5_data['somedata'] 54s pytest_errclass = KeyError if h5py.__version__ >= '3.9.0' else OSError 54s with pytest.raises(pytest_errclass): 54s try: 54s > h5_node.attrs['type'] = pickle.dumps(list) 54s 54s /tmp/autopkgtest-lxc.72qwkxrs/downtmp/build.c7h/src/hickle/tests/test_01_hickle_helpers.py:127: 54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 54s h5py/_debian_h5py_serial/_objects.pyx:54: in h5py._debian_h5py_serial._objects.with_phil.wrapper 54s ??? 54s h5py/_debian_h5py_serial/_objects.pyx:55: in h5py._debian_h5py_serial._objects.with_phil.wrapper 54s ??? 54s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:104: in __setitem__ 54s self.create(name, data=value) 54s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:200: in create 54s h5a.delete(self._id, name) 54s h5py/_debian_h5py_serial/_objects.pyx:54: in h5py._debian_h5py_serial._objects.with_phil.wrapper 54s ??? 54s h5py/_debian_h5py_serial/_objects.pyx:55: in h5py._debian_h5py_serial._objects.with_phil.wrapper 54s ??? 54s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 54s 54s > ??? 54s E KeyError: 'Unable to delete attribute (no write intent on file)' 54s 54s h5py/_debian_h5py_serial/h5a.pyx:145: KeyError Sounds like an issue that should be raised upstream, unless it just means that hickle needs rebuilding against h5py 3.10. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.9-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1059634: marked as pending in pythran
Control: tag -1 pending Hello, Bug #1059634 in pythran reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pythran/-/commit/c05ed599007ee520c3b0d8817c3a692ff20d28b3 python3-pythran Depends: python3-setuptools No longer automatically included in python 3.12. Closes: #1059634. (this message was generated automatically) -- Greetings https://bugs.debian.org/1059634
Bug#1059842: FTBFS: test fails: ZFP lib not compiled with -DBIT_STREAM_WORD_TYPE=uint8
Package: python3-hdf5plugin
Version: 4.0.1-3
Severity: serious
Justification: FTBFS
python3-hdf5plugin has started failing testZfp,
causing both FTBFS and debci failure.
The error message from debci is
56s ERROR: testZfp (__main__.TestHDF5PluginRW.testZfp) (options={'lossless':
False}, dtype=)
56s Write/read test with zfp filter plugin
56s --
56s Traceback (most recent call last):
56s File "/usr/lib/python3/dist-packages/hdf5plugin/test.py", line 245, in
testZfp
56s self._test('zfp', dtype=dtype, **options)
56s File "/usr/lib/python3/dist-packages/hdf5plugin/test.py", line 86, in
_test
56s f.create_dataset("data", data=data, chunks=data.shape, **args)
56s File
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/group.py", line
183, in create_dataset
56s dsid = dataset.make_new_dset(group, shape, dtype, data, name, **kwds)
56s^^
56s File
"/usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/dataset.py", line
163, in make_new_dset
56s dset_id = h5d.create(parent.id, name, tid, sid, dcpl=dcpl, dapl=dapl)
56s ^^^
56s File "h5py/_debian_h5py_serial/_objects.pyx", line 54, in
h5py._debian_h5py_serial._objects.with_phil.wrapper
56s File "h5py/_debian_h5py_serial/_objects.pyx", line 55, in
h5py._debian_h5py_serial._objects.with_phil.wrapper
56s File "h5py/_debian_h5py_serial/h5d.pyx", line 138, in
h5py._debian_h5py_serial.h5d.create
56s ValueError: Unable to create dataset (ZFP lib not compiled with
-DBIT_STREAM_WORD_TYPE=uint8)
There is a "BIT_STREAM_WORD_TYPE uint8" build definition in
setup.py. Sounds like it might not have been activated but is needed.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.6.8-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-hdf5plugin depends on:
ii python3 3.11.6-1
ii python3-h5py 3.9.0-5
Versions of packages python3-hdf5plugin recommends:
ii hdf5-filter-plugin [hdf5-filter-plugin-lz4-seria 0.0~git2022.49e3b65-4
l]
ii hdf5-filter-plugin-blosc-serial 0.0~git20220616.9683f7d-5
pn hdf5-filter-plugin-bz2-serial
ii hdf5-filter-plugin-zfp-serial 1.1.0+git20221021-4
ii hdf5-plugin-lzf 3.9.0-5
python3-hdf5plugin suggests no packages.
-- no debconf information
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
Hi Alistair, given the complexity around hacking openmpi to accommodate placing the mod files under /usr/include, I'm starting to wonder whether it's the best way of resolving Bug#1058526 in the first place. I did it bit of background reading on the fortran mod files. There's a fair bit of dissent about them, and no consensus on a proper location. e.g. https://fortranwiki.org/fortran/show/Library+distribution The files are binary dependent (and compiler version dependent), and not clear that /usr/include is the best place for them anyway. mpich seems to be fine placing them in /usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/mpich, and openmpi seemed to be happy enough doing the same up until Bug#1058526. Is there a different way of resolving Bug#1058526 without moving the mod files to /usr/include? Drew
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 2023-12-27 09:51, Alastair McKinstry wrote:
On 27/12/2023 08:45, Drew Parsons wrote:
...
I guess the problem must be the common files from openmpi-common in
/usr/share/openmpi/. They're not actually arch-independent. Do
mpif90.openmpi and the other components actively read them at runtime?
..
This appears to be it. I've been building on arm64 recently (a VM on a
mac) and don't see this.
There appears to be a mechanism for including ${includedir} and
${libdir} and evaluating the wrapper-data files at runtime. My hacking
on these files in d/rules is causing the errors. I'll work on a better
solution.
I can see at the lowest level the location is pkgdatadir at l.110 (and
elsewhere) in ompi/tools/wrappers/Makefile.am
Not clear if hacking it at that point will interfere with the orterun
binary finding them.
If not, then it could in principle be replaced with something like
$(pkglibdir)/$(datadir) (i.e. in a share subdir under the openmpi
libdir). Might call it "pkglibdatadir".
The default value for pkgdatadir is set as $(datadir)/@PACKAGE@, l.129
in toplevel Makefile.in
datadir is the autotool default ${prefix}/share (i.e. /usr/share),
https://www.gnu.org/software/automake/manual/html_node/Standard-Directory-Variables.html
If orterun can be trained to look for the wrapper txt files in
pkglibdatadir (presumably as well as pkgdatadir, not instead of), then
setting and using "pkglibdatadir" instead of pkgdatadir in
ompi/tools/wrappers/Makefile.am "might" be simple and reliable.
Reliability depends on whether any other component uses these wrapper
txt files.
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 2023-12-26 12:45, Drew Parsons wrote: I can manually reproduce the error trivially on an arm64 chroot (amdahl.debian.org). Copying hello.f90 from openmpi's debian/tests and manually running mpif90 -o hello hello.f90 reproduces the error reference to the x86_64 include path on the arm64 machine. `mpif90.openmpi -print-search-dirs` only shows aarch64 paths though. I guess the problem must be the common files from openmpi-common in /usr/share/openmpi/. They're not actually arch-independent. Do mpif90.openmpi and the other components actively read them at runtime? For instance, /usr/share/openmpi/mpif90.openmpi-wrapper-data.txt contains fmoddir=/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15 Since openmpi-common is marked Arch: all, it's only built once, on amd64, hence x86_64-linux-gnu gets carried to the other arches. The compiler_flags variables is also affected, alongside as fmoddir. It looks like only the mpi fortran wrapper txts are affected, mpif77-wrapper-data.txt mpif77.openmpi-wrapper-data.txt mpif90-wrapper-data.txt mpif90.openmpi-wrapper-data.txt mpifort-wrapper-data.txt mpifort.openmpi-wrapper-data.txt Should these be moved from openmpi-common to libopenmpi-dev (or openmpi-bin) at /usr/lib//openmpi/share ?
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 2023-12-26 12:31, Drew Parsons wrote: ... It's not just adios2 and sundials though. openmpi's own arm64 tests are failing on debci with a reference to x86_64-linux-gnu ... openmpi's compile_run_mpif90 test doesn't use pkgconfig anyway. It builds directly with mpif90. Could the problem be inside the mpif90.openmpi binary? That would be strange though. arm64's mpif90.openmpi oughtn't be referring to x86_64 any more than the pkgconfig file. I can manually reproduce the error trivially on an arm64 chroot (amdahl.debian.org). Copying hello.f90 from openmpi's debian/tests and manually running mpif90 -o hello hello.f90 reproduces the error reference to the x86_64 include path on the arm64 machine. `mpif90.openmpi -print-search-dirs` only shows aarch64 paths though.
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
On 2023-12-26 11:00, Alastair McKinstry wrote: On 24/12/2023 10:50, Drew Parsons wrote: reopen 1058876 block 1058944 by 1058876 thanks Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi fortran modules has hardcoded x86_64-linux-gnu This is preventing builds and tests on other architectures, e.g. rebuilding sundials for the petsc transition. I think openmpi's debian/tests will also need Depends: pkg-config for the new compile_run_cc_pkgconfig test. The problem appears to be the heuristics in upstream/FindMPI.cmake in adios2 (and sundials). It happens in sid tests but not my arm64 devel environment. Debugging slowly. It's not just adios2 and sundials though. openmpi's own arm64 tests are failing on debci with a reference to x86_64-linux-gnu e.g. 79s Setting up libopenmpi-dev:arm64 (4.1.6-3) ... 79s update-alternatives: using /usr/lib/aarch64-linux-gnu/openmpi/include to provide /usr/include/aarch64-linux-gnu/mpi (mpi-aarch64-linux-gnu) in auto mode 79s Setting up autopkgtest-satdep (0) ... 79s Processing triggers for libc-bin (2.37-12) ... 83s (Reading database ... 17753 files and directories currently installed.) 83s Removing autopkgtest-satdep (0) ... 86s autopkgtest [03:14:37]: test compile_run_mpif90: [--- 86s f951: Warning: Nonexistent include directory ‘/usr/include/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi’ [-Wmissing-include-dirs] 86s hello.f90:3:11: 86s 86s 3 | use mpi 86s | 1 86s Fatal Error: Cannot open module file ‘mpi.mod’ for reading at (1): No such file or directory It's a strange error to be sure. From that error message, I thought x86_64-linux-gnu might have gotten hardcoded into the include path in ompi-f90.pc for arm64. But downloading libopenmpi-dev_4.1.6-3_arm64.deb and inspecting manually, I can see that arm64's ompi-f90.pc contains -I/usr/include/aarch64-linux-gnu/fortran/gfortran-mod-15/openmpi which would be the correct path. I unpacked libopenmpi-dev_4.1.6-3_arm64.deb manually, but I can't find any reference to include/x86_64 inside its files. openmpi's compile_run_mpif90 test doesn't use pkgconfig anyway. It builds directly with mpif90. Could the problem be inside the mpif90.openmpi binary? That would be strange though. arm64's mpif90.openmpi oughtn't be referring to x86_64 any more than the pkgconfig file. Best of luck with debugging. Drew
Bug#1058876: libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod)
reopen 1058876 block 1058944 by 1058876 thanks Alas, the fix in openmpi 4.1.6-3 for the include path to the openmpi fortran modules has hardcoded x86_64-linux-gnu This is preventing builds and tests on other architectures, e.g. rebuilding sundials for the petsc transition. I think openmpi's debian/tests will also need Depends: pkg-config for the new compile_run_cc_pkgconfig test.
Bug#1055698: marked as pending in py-ubjson
Control: tag -1 pending Hello, Bug #1055698 in py-ubjson reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/py-ubjson/-/commit/a0be18e429338345b1d9f98161c5e59634058d4e add debian patch py12_recursion_PR19.diff adapts upstream PR12 to fix recursion handling with Python 3.12. Closes: #1055698 (this message was generated automatically) -- Greetings https://bugs.debian.org/1055698
Bug#1058876: libopenmpi-dev: configured header paths don't provide /usr/include
Source: openmpi Followup-For: Bug #1058876 Control: retitle 1058876 libopenmpi-dev: paths missing /usr/include...(for fortran mpi.mod) We can see from debci that openmpi's own tests are affected by the same underlying problem. That indicates that the configuration for mpif90.openmpi itself is missing the required include paths, not just the pkgconfig files. Adjusting the bug title to match.
Bug#1056515: marked as pending in pythran
Control: tag -1 pending Hello, Bug #1056515 in pythran reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pythran/-/commit/62d67370b0cabcc2e626f01a160d90824835076d add debian patch python_3.12_258ab9a.diff applies upstream commit 258ab9a to support Python 3.12. https://github.com/serge-sans-paille/pythran/commit/258ab9aaf26172f669eab1bf2a346b5f65db3ac0 Closes: #1056515. (this message was generated automatically) -- Greetings https://bugs.debian.org/1056515
Bug#1057863: slepc4py ftbfs with Python 3.12
Source: slepc4py Followup-For: Bug #1057863 Correction: curexc_traceback is not used in slepc4py 3.19. Maybe it's time to upgrade to PETSc 3.19.
Bug#1057863: slepc4py ftbfs with Python 3.12
Source: slepc4py Followup-For: Bug #1057863 slepc4py does not use curexc_traceback. Perhaps this is a bug in cython?
Bug#1058876: libopenmpi-dev: cmake builds do not find fortan mpimod in /usr/include
Package: libopenmpi-dev Version: 4.1.6-2 Severity: serious Justification: ftbfs (other) openmpi 4.1.6-2 moved the fortran mod files from /usr/lib to /usr/include. This is probably correct, but has some consequences we need to sort out. Applications using cmake for configuration are still looking for the mod files in /usr/lib, so their builds now fail. An example is adios2, with error message: [384/1029] /usr/bin/gfortran -I/build/adios2-2.9.2+dfsg1/examples/hello/bpWriter -I/build/adios2-2.9.2+dfsg1/build-mpi/bindings/Fortran -I/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi -I/usr/lib/x86_ 64-linux-gnu/openmpi/lib -g -O2 -ffile-prefix-map=/build/adios2-2.9.2+dfsg1=. -fstack-protector-strong -fstack-clash-protection -fcf-protection -Jexamples/hello/bpWriter -fpreprocessed -c examples/hello/bpWriter /CMakeFiles/hello_bpWriter_f_mpi.dir/helloBPWriter.F90-pp.f90 -o examples/hello/bpWriter/CMakeFiles/hello_bpWriter_f_mpi.dir/helloBPWriter.F90.o FAILED: examples/hello/bpWriter/CMakeFiles/hello_bpWriter_f_mpi.dir/helloBPWriter.F90.o /usr/bin/gfortran -I/build/adios2-2.9.2+dfsg1/examples/hello/bpWriter -I/build/adios2-2.9.2+dfsg1/build-mpi/bindings/Fortran -I/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi -I/usr/lib/x86_64-linux-gn u/openmpi/lib -g -O2 -ffile-prefix-map=/build/adios2-2.9.2+dfsg1=. -fstack-protector-strong -fstack-clash-protection -fcf-protection -Jexamples/hello/bpWriter -fpreprocessed -c examples/hello/bpWriter/CMakeFiles /hello_bpWriter_f_mpi.dir/helloBPWriter.F90-pp.f90 -o examples/hello/bpWriter/CMakeFiles/hello_bpWriter_f_mpi.dir/helloBPWriter.F90.o /build/adios2-2.9.2+dfsg1/examples/hello/bpWriter/helloBPWriter.F90:3:9: 3 | use mpi | 1 Fatal Error: Cannot open module file ‘mpi.mod’ for reading at (1): No such file or directory compilation terminated. We can see that the compilation got configured to use -I/usr/lib/x86_64-linux-gnu/fortran/gfortran-mod-15/openmpi which would be why it can't find mpi.mod in /usr/include As far as I can tell, adios2 is not making assumptions itself about the location of the mod files. I suspect the configuration is coming from cmake's FindMPI.cmake I guess we don't want openmpi 4.1.6-2 to migrate to testing until this issue is resolved, which is why I've marked Severity: serious. There are openmpi's pkgconfig files. $ pkg-config --cflags mpi-fort -I/usr/lib/x86_64-linux-gnu/openmpi/include -I/usr/lib/x86_64-linux-gnu/openmpi/include/openmpi -I/usr/lib/x86_64-linux-gnu/openmpi/lib The fortrandir variable set in ompi-fort.pc is also located in /usr/lib (perhaps it should be so) So /usr/include is not used in the include path flags. But /usr/lib is. This must be the origin of the problem. cmake's FindMPI.cmake does indeed use pkgconfig to extract the paths: "if(_MPI_PKG AND PKG_CONFIG_FOUND)" -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libopenmpi-dev depends on: ii gfortran [gfortran-mod-15] 4:13.2.0-2 ii gfortran-11 [gfortran-mod-15] 11.4.0-7 ii gfortran-12 [gfortran-mod-15] 12.3.0-13 ii gfortran-13 [gfortran-mod-15] 13.2.0-9 ii libevent-dev 2.1.12-stable-8 ii libhwloc-dev 2.10.0-1 ii libibverbs-dev 48.0-1 ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-jquery-ui1.13.2+dfsg-1 ii libopenmpi34.1.6-2 ii libpmix-dev5.0.1-4 ii openmpi-bin4.1.6-2 ii openmpi-common 4.1.6-2 ii zlib1g-dev 1:1.3.dfsg-3 Versions of packages libopenmpi-dev recommends: ii libcoarrays-openmpi-dev 2.10.1-1+b1 Versions of packages libopenmpi-dev suggests: pn openmpi-doc -- no debconf information
Bug#1058353: libadios2-mpi-c-dev: ships headers already shipped in libadios2-common-c-dev
Source: adios2 Followup-For: Bug #1058353 Damn, something went badly wrong in debian/rules. Sorry about that. I'll fix it as soon as possible, in the meantime use the version in testing. Drew
Bug#1058018: libadios2-common-core-dev has an undeclared file conflict on /usr/lib/x86_64-linux-gnu/cmake/adios2/adios2-config.cmake
Source: adios2 Followup-For: Bug #1058018 Control: severity -1 important Call it teething issues. This is a new package, so I'm trying to avoid making debian/control more verbose than it needs to be by not crowding the fields with the strict specifications needed to avoid this error. Once the new version migrates to testing, I'll close this bug and we can pretend it never happened.
Bug#1054712: ensmallen: FTBFS: adam_test.cpp:17:10: fatal error: catch2/catch.hpp: No such file or directory
Source: ensmallen Followup-For: Bug #1054712 Should be noted that the problem is linked to debian patch 0002-use-system-catch.patch, which disables upstream's local copy of catch in order to use the system catch2 library. So one workaround could be to disable 0002-use-system-catch.patch.
Bug#1053774: spdlog: need new upstream release 1.12 for catch2 v3
Source: spdlog Followup-For: Bug #1053774 Looks like you'll need to grab PR#2827 from upstream https://github.com/gabime/spdlog/pull/2827
Bug#1054712: ensmallen: FTBFS: adam_test.cpp:17:10: fatal error: catch2/catch.hpp: No such file or directory
Source: ensmallen Followup-For: Bug #1054712 Control: forwarded 1054712 https://github.com/mlpack/ensmallen/issues/372 This error occurs because of the upgrade of catch2 from v2 to v3. Unfortunately ensmallen upstream don't sound very enthusiastic about dealing with it, https://github.com/mlpack/ensmallen/issues/372 Arguably the catch developers made life unjustifiablydifficult. Maybe they should have released catch3 rather than catch2 v3. On the other hand, judging by the patch for termpaint, the required changes are likely to be essentially trivial, e.g. #include "catch2/catch_all.hpp" instead of #include "catch2/catch.hpp" cf. https://github.com/termpaint/termpaint/commit/dc293554b745b3f010445e9445e620399f8ee2f7
Bug#1054646: gammapy: test_binary_dilate fails on i386, s390x
Source: gammapy Version: 1.1-1 Severity: serious Justification: debci scipy 1.10.1-4 is triggering errors in test_ndmap.py test_binary_dilate and test_binary_dilate_erode_3d on both i386 and s390x. The error looks a little like https://github.com/gammapy/gammapy/issues/3662 which was solved by adding error tolerance, https://github.com/gammapy/gammapy/pull/3907 Perhaps that tolerance needs to be increased a little. The failing difference here is 23 not 20. test_binary_dilate_erode_3d isn't using a tolerance like that, should it add it? Not entirely clear why scipy 1.10.1-4 is giving failures now. The tests were passing with scipy 1.10.1-2. scipy 1.10.1-4 now builds with pythran 0.14, so perhaps some pythran 0.11 functions had gotten built into the scipy 1.10.1-2 libraries that gammapy uses.
Bug#1053527: marked as pending in python-scipy
Control: tag -1 pending Hello, Bug #1053527 in python-scipy reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/scipy/-/commit/41ebf615e6166d23a5745276008a5caf7086ff60 drop pythran upper version in Build-Depends. Apparently pythran 0.14 fixed some things, cf. upstream issues scipy#19150, pythran#2139, scipy PR#19191. Furthermore, the upper bound is only added upstream to release branches, it is not used in the main development branch. That is, the upper bound is only provided for pypi (pip) stability, it is not a true strict requirement. Closes: #1053527. (this message was generated automatically) -- Greetings https://bugs.debian.org/1053527
Bug#1053090: libxsimd-dev: arm64 error in xtensor: usage of batch type with unsupported type
Source: xtensor Version: 0.24.7-4 Followup-For: Bug #1053090 Control: severity 1053090 important xsimd support is optional for xtensor. Use of batch is apparently not expected to be routinely used anyway. See further discussion at https://github.com/xtensor-stack/xsimd/issues/945 In summary, xtensor can be run on arm64 (and armel) without xsimd, and batch support should not be considered release-critical. For these reasons I'm downgrading this bug to Severity: important. It wouldn't be constructive to remove xtensor from testing.
Bug#1053776: tuiwidgets: catch2 v3 breaks tests
Source: tuiwidgets Version: 0.2-1.1 Severity: serious Justification: debci catch2 v3 was recently uploaded and breaks tuiwidgets's tests The needed patch is likely to be simple, similar to the one prepared for termpaint
Bug#1053775: termpaint: catch2 v3 breaks debci tests
Source: termpaint Version: 0.3.0-2 Severity: serious Justification: debci Control: tags -1 patch catch2 v3 was recently uploaded, and breaks termpaint's tests Upstream has made a patch: https://github.com/termpaint/termpaint/commit/dc293554b745b3f010445e9445e620399f8ee2f7
Bug#1053774: spdlog: need new upstream release 1.12 for catch2 v3
Source: spdlog Version: 1:1.10.0+ds-1 Severity: serious Justification: debci catch2 v3 was recently uploaded, but breaks spdlog's tests. spdlog upstream has released v1.12.0 which uses catch2 v3.
Bug#1053768: posixsignalmanager: tests fail with catch2 v3
Source: posixsignalmanager Version: 0.3-3 Severity: serious Justification: debci Control: forwarded -1 https://github.com/textshell/posixsignalmanager/issues/2 Control: tags -1 patch catch2 v3 was recently uploaded, and breaks posixsignalmanager's tests Upstream has prepared a patch, https://github.com/textshell/posixsignalmanager/pull/3
Bug#1053314: Depends: python3-h5py-mpi without python3-h5py
On 2023-10-10 09:26, Rafael Laboissière wrote: * Rafael Laboissière [2023-10-09 08:30]: […] At least, I hope that version 3.1.0+dfsg2-5 will really fix Bug#1053314 and the h5py transition will be completed. Unfortunately, it is still not working: https://ci.debian.net/data/autopkgtest/testing/arm64/x/xmds2/38836874/log.gz I guess that the problem comes from the absence of /usr/bin/h5cc, which is in the hdf5-helpers package. This package, which is a dependency of libhdf5-dev, is not installed at the autopkgtest run. I confess that I am confused and need your advice here. Currently, the xmds2 package depends on libhdf5-mpi-dev. Should hdf5-helpers or libhdf5-dev be added to Depends? The hdf5 packages have some complex symlink management to allow for mpi to be either openmpi or mpich. Possibly xdms2 got caught by that. Sometimes the symlink goes wrong and the hdf-mpi packages need to be reinstalled to refresh it. But that shouldn't affect a buildd (or debci) run, it should already have a fresh installation of the packages. I'll take a closer look. Drew
Bug#1053314: Depends: python3-h5py-mpi without python3-h5py
On 2023-10-09 08:30, Rafael Laboissière wrote: Thanks for this detailed explanation, Drew. I released version 3.1.0+dfsg2-5 of the xmds2 package before reading it. I added python3-h5py to Build-Depends and libhdf5-mpi-dev to Depends, as you suggested (even though there is a typo in the debian/changelog entry, stating eroneaously that libhdf5-serial-dev has been added; I will fix this in the next release). I also used H5PY_ALWAYS_USE_MPI=1, as you mentioned. As regards adding also python3-h5py-serial to Depends and putting a fallback code in place, I will have to give it a little thought. Maybe, I should discuss this with the upstream authors, to know what they thing. Let us see how things evolve. At least, I hope that version 3.1.0+dfsg2-5 will really fix Bug#1053314 and the h5py transition will be completed. Keep in mind when I discussed the fallback mechanism, I meant the way it is handled in the h5py package (h5py/__init__.py), not xmds2 directly. If xmds2 itself doesn't really care which variant of h5py it uses, then (in terms of xdms2 runtime) it can just import h5py as normal and let h5py figure out which variant it's serving up. (although it might need to Depend on both variants to ensure they're both available) But it would be helpful to hear from xmds2 upstream what their intentions with h5py and MPI are, especially given that xmds2 links to libhdf5 directly. Drew
Bug#1053314: Depends: python3-h5py-mpi without python3-h5py
Nilesh explained most of the situation correctly. I can give some more background.It made sense (to me) to have h5py built against hdf5-mpi, since I figured that if you need the complexity of the hdf5 file format then you probably want to use it in an MPI environment. There was a complaint from a user though, who wanted to make use of a massive ensemble of HDF5 (h5py) serial jobs, and the small cost of loading up MPI support was interfering with their throughput. So the compromise solution was to provide both builds, with a custom __init__.py to select the serial or MPI build depending on runtime environment. If an MPI environment is detected then the h5py MPI build is loaded, otherwise the serial build is loaded. If you want to run h5py in a serial process, then one might say you'd normally want the serial build. As Nilesh noted, I put in a mechanism to load the MPI build if you really want to access the mpi build in a serial process (mpirun -n 1 is not a "serial" process as such, it's still an MPI environment even though using only 1 process). The mechanism to force MPI loading is NOT to set OMPI_COMM_WORLD_SIZE. I recommend NOT doing that. I couldn't promise it won't mess up other things, certainly it will get in the way of an MPICH environment. No, the mechanism for handling this for h5py is described in /usr/share/doc/python3-h5py/README.Debian: set H5PY_ALWAYS_USE_MPI=1 Is there a way to force h5py to import _debian_h5py_serial instead of _debian_h5py_mpi, via the generic h5py namespace? It sounds like there is some confusion about how xmds2 should be used. Is it intended to be used as a serial process or MPI? I noted in the bug report that xmds2 Depends: libhdf5-serial-dev. Is it even using MPI? If you want it to be using h5py-serial, then why does xmsd2 depend on python3-h5py-mpi? It seems to me that xmds2's h5py dependency should be the same as its hdf5 dependency. If it uses libhdf5-serial then should it be depending on just python3-h5py (implying python3-h5py-serial, make it explicit if needed) and not depend on python3-h5py-mpi? If xmds2 is intended to be flexible, equally happy in serial and MPI environments (and can actually make use of h5py-mpi) then perhaps the dependency should cover all cases, Depends: python3-h5py, python3-h5py-serial, python3-h5py-mpi all three explicitly, since otherwise one or the other of -serial or -mpi would be missed. The problem raises interesting questions about h5py configuration. I set up it so you could choose how you want it to work, with or without MPI support. But it looks like an edge case is missing: it's failing in serial jobs if you chose to set up your installation with python3-h5py-mpi and explicitly don't want python3-h5py-serial (unless you always set H5PY_ALWAYS_USE_MPI). Perhaps I should add an additional fallback to try h5py-mpi if h5py-serial is not found (in a serial job), the same way that h5py-serial is loaded as a fallback in an MPI job if h5py-mpi is not found. On the other hand maybe that just hides the real problem, that h5py-serial was not installed when actually it was wanted after all. The ImportError correctly identifies that case. On 2023-10-08 17:38, Nilesh Patra wrote: Hello, On 10/8/23 17:22, Rafael Laboissière wrote: Ok, I tried to fix the building problem by including python3-h5py, alongside with python3-h5py-mpi, into Build-Depends, as suggested by Drew, but the xmds2 package FTBFS. Here is a way to reproduce the problem without building the package: $ dpkg -l python3-h5py\* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-===---=== ii python3-h5py 3.9.0-3 all general-purpose Python interface to hdf5 ii python3-h5py-mpi 3.9.0-3 amd64 general-purpose Python interface to hdf5 (Python 3 MPI) un python3-h5py-serial (no description available) $ echo 'import h5py' | python3 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/h5py/__init__.py", line 21, in from . import _debian_h5py_serial as _h5py ImportError: cannot import name '_debian_h5py_serial' from partially initialized module 'h5py' (most likely due to a circular import) (/usr/lib/python3/dist-packages/h5py/__init__.py) Is there a way to force h5py to import _debian_h5py_serial instead of _debian_h5py_mpi, via the generic h5py namespace? Drew would probably answer that question better but from taking a brief look, it seems to be on expected lines. This should work if you run it explicitly with mpi. $ mpirun -n 1 python3 -c "import h5py" && echo
Bug#1053090: libxsimd-dev: arm64 error in xtensor: usage of batch type with unsupported type
Package: libxsimd-dev
Followup-For: Bug #1053090
Control: reassign 1053090 libxtensor-dev
Control: forwarded 1053090 https://github.com/xtensor-stack/xtensor/issues/2733
xsimd upstream https://github.com/xtensor-stack/xsimd/issues/945
identified the problem that neon64 does not support bool.
A minimal test case using xtensor only was found:
#include
int main()
{
{
xt::xtensor a{0., 1.};
xt::xtensor b = a && 0.;
}
{
xt::xtensor a{false, true};
//xt::xtensor b = a && false;
}
return 0;
}
That contains the problem inside xtensor, so transferring this bug to
the xtensor package.
Bug#1053267: hickle: test_H5NodeFilterProxy fails with h5py 3.9.0: Unable to delete attribute (no write intent on file)
reopen 1053267 thanks hickle 5.0.2-6 was intended to fix the "No write intent on file" error in Bug#1053267. But the error still occurs, see https://ci.debian.net/data/autopkgtest/testing/amd64/h/hickle/38426042/log.gz Note that this time the error occurred with old h5py 3.7.0, so there must be more to the problem than just h5py 3.9.0 on its own.
Bug#1053341: h5py FTBFS on 32-bit archs: OverflowError: Python int too large to convert to C ssize_t
forwarded 1053341 https://github.com/h5py/h5py/issues/2315 thanks I suspect it can be resolved by casting the int returned by addressof to ctypes.c_int. Waiting to hear what upstream thinks. Note it's not quite as simple as "32-bit". sparc64 is also affected.
Bug#1053314: Depends: python3-h5py-mpi without python3-h5py
Package: xmds2 Version: 3.1.0+dfsg2-4 Severity: serious Justification: debci xmds2 Depends: python3-h5py-mpi without depending on python3-h5py python3-h5py-mpi only provides the h5py._debian_h5py_mpi namespace, not h5py. Hence tests using h5py without specifying _debian_h5py_mpi fail. This is the case with h5py 3.9.0. (Marking Severity: serious due to debci failure) python3-h5py provides the h5py namespace, so if xmds2 strictly needs the mpi build, but accessing via the generic h5py namespace, then the Depends should specify both packages Depends: python3-h5py python3-h5py-mpi Note there seems to be an inconsistency in the xmds2 package configuration. It has MPI dependencies (python3-h5py-mpi, also mpi-default-dev, libfftw3-mpi-dev), but with respect to hdf5 it has Depends: libhdf5-serial-dev Should that instead be Depends: libhdf5-mpi-dev ?
Bug#1053274: ont-fast5-api: test_001_read_events fails with h5py 3.9.0: 'AstypeWrapper' object does not support the context manager protocol
Source: ont-fast5-api Version: 4.1.1+dfsg-2 Severity: serious Justification: debci h5py 3.9.0 is triggering an error ont-fast5-api debci tests, https://ci.debian.net/data/autopkgtest/testing/amd64/o/ont-fast5-api/38279479/log.gz 33s ERROR: test_001_read_events (test.test_event_detection_tools.TestEventDetectionTools.test_001_read_events) 33s -- 33s Traceback (most recent call last): 33s File "/tmp/autopkgtest-lxc.jqw02kin/downtmp/autopkgtest_tmp/test/test_event_detection_tools.py", line 26, in test_001_read_events 33s data, attrs = fh.get_event_data(time_in_seconds=True) 33s ^^^ 33s File "/usr/lib/python3/dist-packages/ont_fast5_api/analysis_tools/event_detection.py", line 84, in get_event_data 33s with dataset.astype(np.dtype(descr)): 33s TypeError: 'AstypeWrapper' object does not support the context manager protocol 33s 33s -- 33s Ran 76 tests in 1.416s 33s 33s FAILED (errors=1, skipped=5)
Bug#1053267: hickle: test_H5NodeFilterProxy fails with h5py 3.9.0: Unable to delete attribute (no write intent on file)
Source: hickle Version: 5.0.2-5 Severity: serious Justification: debci h5py 3.9.0 is triggering an error in hickle tests, found by debci, https://ci.debian.net/data/autopkgtest/testing/amd64/h/hickle/38279474/log.gz 62s test_H5NodeFilterProxy 62s 62s h5_data = 62s 62s def test_H5NodeFilterProxy(h5_data): 62s """ 62s tests H5NodeFilterProxy class. This class allows to temporarily rewrite 62s attributes of h5py.Group and h5py.Dataset nodes before being loaded by 62s hickle._load method. 62s """ 62s 62s # load data and try to directly modify 'type' and 'base_type' Attributes 62s # which will fail cause hdf5 file is opened for read only 62s h5_node = h5_data['somedata'] 62s with pytest.raises(OSError): 62s try: 62s > h5_node.attrs['type'] = pickle.dumps(list) 62s 62s /tmp/autopkgtest-lxc.kwo7jiul/downtmp/build.aWU/src/hickle/tests/test_01_hickle_helpers.py:126: 62s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 62s h5py/_debian_h5py_serial/_objects.pyx:54: in h5py._debian_h5py_serial._objects.with_phil.wrapper 62s ??? 62s h5py/_debian_h5py_serial/_objects.pyx:55: in h5py._debian_h5py_serial._objects.with_phil.wrapper 62s ??? 62s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:104: in __setitem__ 62s self.create(name, data=value) 62s /usr/lib/python3/dist-packages/h5py/_debian_h5py_serial/_hl/attrs.py:200: in create 62s h5a.delete(self._id, name) 62s h5py/_debian_h5py_serial/_objects.pyx:54: in h5py._debian_h5py_serial._objects.with_phil.wrapper 62s ??? 62s h5py/_debian_h5py_serial/_objects.pyx:55: in h5py._debian_h5py_serial._objects.with_phil.wrapper 62s ??? 62s _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 62s 62s > ??? 62s E KeyError: 'Unable to delete attribute (no write intent on file)' 62s 62s h5py/_debian_h5py_serial/h5a.pyx:145: KeyError
Bug#1053266: python3-h5sparse incomplete Depends: python3-h5py-serial
Package: python3-h5sparse Version: 0.1.0-6 Severity: serious Justification: debci Currently python3-h5sparse Depends: python3-h5py-serial, but h5sparse tests access h5py, not h5py._debian_h5py_serial. The python3-h5py-serial package only provides h5py._debian_h5py_serial. If you need to use the generic h5py namespace rather than the specific serial namespace, then you need Depends: python3-h5py python3-h5py depends on python3-h5py-serial by default but that might alternatively be satisfied by python3-h5py-mpi. If h5sparse strictly needs python3-h5py-serial and not python3-h5py-mpi, then the dependency should declare both Depends: python3-h5py, python3-h5py-serial -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-h5sparse depends on: ii python3 3.11.4-5+b1 ii python3-h5py-serial 3.9.0-2 ii python3-numpy1:1.24.2-1 ii python3-scipy1.10.1-2 ii python3-six 1.16.0-4 python3-h5sparse recommends no packages. python3-h5sparse suggests no packages. -- no debconf information
Bug#1053265: dipy: test_icm_square test fails since exact equality used with floating point numbers
Source: dipy
Version: 1.7.0-2
Severity: serious
Justification: debci
h5py 3.9.0 is triggering an error in dipy debci tests,
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dipy/38279462/log.gz
However from the error log, it's not clear that the problem is
directly related to h5py. An exact [in]equality test is failing
between floating point numbers.
The error log is:
1967s ___ test_icm_square
1967s
1967s def test_icm_square():
1967s
1967s com = ConstantObservationModel()
1967s icm = IteratedConditionalModes()
1967s
1967s initial_segmentation = square
1967s
1967s mu, sigma = com.seg_stats(square_1, initial_segmentation,
1967s nclasses)
1967s sigmasq = sigma ** 2
1967s npt.assert_(mu[0] >= 0.0)
1967s npt.assert_(mu[1] >= 0.0)
1967s npt.assert_(mu[2] >= 0.0)
1967s npt.assert_(mu[3] >= 0.0)
1967s npt.assert_(sigmasq[0] >= 0.0)
1967s npt.assert_(sigmasq[1] >= 0.0)
1967s npt.assert_(sigmasq[2] >= 0.0)
1967s npt.assert_(sigmasq[3] >= 0.0)
1967s
1967s negll = com.negloglikelihood(square_1, mu, sigmasq, nclasses)
1967s
1967s final_segmentation_1 = np.empty_like(square_1)
1967s final_segmentation_2 = np.empty_like(square_1)
1967s
1967s beta = 0.0
1967s
1967s for i in range(max_iter):
1967s
1967s print('\n')
1967s print('>> Iteration: ' + str(i))
1967s print('\n')
1967s
1967s final_segmentation_1, energy_1 = icm.icm_ising(negll, beta,
1967s
initial_segmentation)
1967s initial_segmentation = final_segmentation_1
1967s
1967s beta = 2
1967s initial_segmentation = square
1967s
1967s for j in range(max_iter):
1967s
1967s print('\n')
1967s print('>> Iteration: ' + str(j))
1967s print('\n')
1967s
1967s final_segmentation_2, energy_2 = icm.icm_ising(negll, beta,
1967s
initial_segmentation)
1967s initial_segmentation = final_segmentation_2
1967s
1967s difference_map = np.abs(final_segmentation_1 -
final_segmentation_2)
1967s > npt.assert_(np.abs(np.sum(difference_map)) != 0)
1967s E AssertionError
1967s
1967s dipy/segment/tests/test_mrf.py:370: AssertionError
I'm assumung final_segmentation is floating point, not integer.
Correct me if that's wrong. In general exact equality of floating
point numbers should always be expected to fail. The test should be
something like
npt.assert_( not np.isclose( np.abs(np.sum(difference_map)), 0 ) )
If final_segmentation is an integer then of course it's a different
problem.
Bug#1049903: petsc: misbuild with gcc-13
Source: petsc Followup-For: Bug #1049903 Control: severity 1049903 important Control: tags 1049903 moreinfo I said previously I'd apply the patch, but I wanted to check the problem first. No problem is showing at https://tests.reproducible-builds.org/debian/rb-pkg/petsc.html even in the experimental rebuilds. I tried rebuilding in an experimental chroot on barriere.debian.org porterbox (amd64), using libc6-dev 2.38-3 with 13.2.0-4. No problem there either, even with libc6 version 28. It sounds like some problem might have entered into ubuntu mantic. I think it would be better to track down that problem rather than papering over it and ignoring it. Downgrading severity since the error is not reliably reproducible. Is Ubuntu still affected by the problem?
Bug#1052748: mpi4py fails test_dynproc.TestDPM.testJoin: socket.gaierror: [Errno -2] Name or service not known
Source: mpi4py Followup-For: Bug #1052748 Control: severity 1052748 important Control: tags 1052748 moreinfo I can't reproduce this error, and debci tests at https://ci.debian.net/packages/m/mpi4py/ continue to pass So I'm downgrading severity. I figure there are two possibilities - it was a transitory error related to some other library transition - or it's triggered by the network configuration on your test system. For instance, https://github.com/mpi4py/mpi4py/issues/240 was triggered by a network configured with IPV6 only. But that issue should be resolved already in mpi4py 3.1.4 Your test log shows your network accesses http://127.0.0.1:12990 so it is using IPv4. Can you reproduce the testJoin error?
Bug#1052748: mpi4py fails test_dynproc.TestDPM.testJoin: socket.gaierror: [Errno -2] Name or service not known
Source: mpi4py Followup-For: Bug #1052748 Control: retitle 1052748 mpi4py fails test_dynproc.TestDPM.testJoin: socket.gaierror: [Errno -2] Name or service not known The failure was incorrectly identified. The build log says the problem was in testJoin: ERROR: testJoin (test_dynproc.TestDPM.testJoin) -- Traceback (most recent call last): File "/<>/test/test_dynproc.py", line 172, in testJoin addresses = socket.getaddrinfo(host, None, 0, socket.SOCK_STREAM) ^ File "/usr/lib/python3.11/socket.py", line 962, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): ^^^ socket.gaierror: [Errno -2] Name or service not known Likely it is related to https://github.com/mpi4py/mpi4py/issues/240 concerning running the test in ipv6 networks.
Bug#1052882: xtensor: FTBFS: make[1]: *** [debian/rules:65: override_dh_auto_configure] Error 2
Source: xtensor Followup-For: Bug #1052882 Control: fixed 1052882 0.24.7-1 This bug is weird, in the sense that xtensor 0.24.3-2 in testing failed its test against xsimd 10.0.0-3 from unstable. So why then did the migration daemon allow xsimd to migrate from unstable to testing?
Bug#1053090: libxsimd-dev: arm64 error in xtensor: usage of batch type with unsupported type
Package: libxsimd-dev
Version: 10.0.0-3
Severity: serious
Justification: debci
libxsimd-dev 10 triggers an error in xtensor tests on arm64
xsimd passes its own tests, and xtensor passes on other arches (except
armel which has known issues)
The error output from
https://ci.debian.net/data/autopkgtest/unstable/arm64/x/xtensor/38197207/log.gz
is
127s [ 26%] Building CXX object
CMakeFiles/test_xtensor_lib.dir/test_xoptional_assembly.cpp.o
127s /usr/bin/g++ -DXSIMD_ENABLE_XTL_COMPLEX -DXTENSOR_USE_XSIMD
-DXSIMD_ENABLE_XTL_COMPLEX=1 -march=native -std=c++14 -Wunused-parameter
-Wextra -Wreorder -Wconversion -Wno-sign-conversion -Wold-style-cast
-Wunused-variable -ftemplate-backtrace-limit=0 -O3 -DNDEBUG -MD -MT
CMakeFiles/test_xtensor_lib.dir/test_xoptional_assembly.cpp.o -MF
CMakeFiles/test_xtensor_lib.dir/test_xoptional_assembly.cpp.o.d -o
CMakeFiles/test_xtensor_lib.dir/test_xoptional_assembly.cpp.o -c
/tmp/autopkgtest-lxc.1p570fd4/downtmp/autopkgtest_tmp/test_xoptional_assembly.cpp
131s In file included from /usr/include/xsimd/types/xsimd_batch.hpp:493,
131s from /usr/include/xsimd/xsimd.hpp:61,
131s from /usr/include/xtensor/xtensor_config.hpp:61,
131s from /usr/include/xtensor/xexception.hpp:24,
131s from /usr/include/xtensor/xstorage.hpp:21,
131s from /usr/include/xtensor/xbuffer_adaptor.hpp:21,
131s from /usr/include/xtensor/xarray.hpp:19,
131s from
/tmp/autopkgtest-lxc.1p570fd4/downtmp/autopkgtest_tmp/test_xoperation.cpp:13:
131s /usr/include/xsimd/types/xsimd_traits.hpp: In instantiation of ‘struct
xsimd::detail::static_check_supported_config_emitter’:
131s /usr/include/xsimd/types/xsimd_traits.hpp:84:19: required from ‘void
xsimd::detail::static_check_supported_config() [with T = bool; A =
xsimd::neon64]’
131s /usr/include/xsimd/types/xsimd_api.hpp:437:55: required from
‘xsimd::simd_return_type xsimd::broadcast_as(From) [with To = int;
A = neon64; From = bool; simd_return_type = batch_bool]’
131s /usr/include/xtensor/xscalar.hpp:952:53: required from
‘xt_simd::simd_return_type
>::value_type, requested_type> xt::xscalar::load_simd(size_type) const
[with align = xt::inner_aligned_mode; requested_type = int; long unsigned int N
= 4; CT = bool; xt_simd::simd_return_type >::value_type, requested_type> =
xsimd::batch_bool; typename
xt::xcontainer_inner_types >::value_type = bool; size_type =
long unsigned int]’
...
131s /usr/include/xtensor/xarray.hpp:510:30: required from
‘xt::xarray_container::xarray_container(const
xt::xexpression&) [with E = xt::xfunction >,
xt::layout_type::row_major, xt::svector, true>, xt::xtensor_expression_tag>&,
xt::xscalar >; EC = xt::uvector
>; xt::layout_type L = xt::layout_type::row_major; SC = xt::svector, true>; Tag =
xt::xtensor_expression_tag]’
131s
/tmp/autopkgtest-lxc.1p570fd4/downtmp/autopkgtest_tmp/test_xoperation.cpp:378:28:
required from ‘void xt::DOCTEST_ANON_SUITE_131::DOCTEST_ANON_TMP_150() [with
TypeParam = xt::xarray_container >, xt::layout_type::row_major,
xt::svector, true>,
xt::xtensor_expression_tag>]’
131s
/tmp/autopkgtest-lxc.1p570fd4/downtmp/autopkgtest_tmp/test_xoperation.cpp:372:9:
required from
‘xt::DOCTEST_ANON_SUITE_131::{anonymous}::DOCTEST_ANON_TMP_150ITERATOR >::DOCTEST_ANON_TMP_150ITERATOR(const char*, unsigned int, int) [with
Type = xt::xarray_container >, xt::layout_type::row_major,
xt::svector, true>,
xt::xtensor_expression_tag>; Rest = {xt::xtensor_container >, 2, xt::layout_type::row_major,
xt::xtensor_expression_tag>}]’
131s
/tmp/autopkgtest-lxc.1p570fd4/downtmp/autopkgtest_tmp/test_xoperation.cpp:372:9:
required from here
131s /usr/include/xsimd/types/xsimd_traits.hpp:64:43: error: static assertion
failed: usage of batch type with unsupported type
131s64 | static_assert(!A::supported() ||
xsimd::has_simd_register::value,
131s |
^~~~
131s /usr/include/xsimd/types/xsimd_traits.hpp:64:43: note: ‘((!
xsimd::neon64::supported()) || ((bool)std::integral_constant::value))’ evaluates to false
Since xsimd passes it's own test, this might be a bug in xtensor.
Filing against libxsimd-dev to pause migration to testing.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
libxsimd-dev depends on no packages.
libxsimd-dev recommends no packages.
Versions of packages libxsimd-dev suggests:
ii libxsimd-doc
Bug#1052544: xtl 0.7.5 could not find "doctest"
Source: xtl Version: 0.7.5-2 Severity: serious Justification: debci There's a problem with the xtk 0.7.5 cmake configuration. It fails debian/tests (debci) since it can't find doctest: 46s CMake Error at CMakeLists.txt:12 (find_package): 46s By not providing "Finddoctest.cmake" in CMAKE_MODULE_PATH this project has 46s asked CMake to find a package configuration file provided by "doctest", but 46s CMake did not find one. 46s 46s Could not find a package configuration file provided by "doctest" with any 46s of the following names: 46s 46s doctestConfig.cmake 46s doctest-config.cmake 46s 46s Add the installation prefix of "doctest" to CMAKE_PREFIX_PATH or set 46s "doctest_DIR" to a directory containing one of the above files. If 46s "doctest" provides a separate development package or SDK, be sure it has 46s been installed. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1042034: marked as pending in nwchem
Control: tag -1 pending Hello, Bug #1042034 in nwchem reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/nwchem/-/commit/2de418a62b358f2c1ec0db6307cc4c396f8b2fb0 add debian patch fix_py310_6384013.diff applies upstream commit 6384013 to build with python3.10 and higher. Build with set -e so as not to continue build if there are failures. The build problem was not -ldangchang as such, but attempting to link nwchem after compilation had already failed due to the changed python libraries (graminit.h) Closes: #1042034 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042034
Bug#1042034: marked as pending in nwchem
Control: tag -1 pending Hello, Bug #1042034 in nwchem reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debichem-team/nwchem/-/commit/2de418a62b358f2c1ec0db6307cc4c396f8b2fb0 add debian patch fix_py310_6384013.diff applies upstream commit 6384013 to build with python3.10 and higher. Build with set -e so as not to continue build if there are failures. The build problem was not -ldangchang as such, but attempting to link nwchem after compilation had already failed due to the changed python libraries (graminit.h) Closes: #1042034 (this message was generated automatically) -- Greetings https://bugs.debian.org/1042034
Bug#1042034: nwchem: FTBFS: ld: cannot find -ldangchang: No such file or directory
Package: nwchem Version: 7.0.2-4 Followup-For: Bug #1042034 The problem seems to be specific to mpich, which is a bit peculiar. The openmpi build remains successful.
Bug#1049903: petsc: misbuild with gcc-13
Source: petsc Followup-For: Bug #1049903 Thanks for the clarification. I'll apply the patch.
Bug#1049903: petsc: misbuild with gcc-13
Source: petsc Followup-For: Bug #1049903 Hi Steve, thanks for the bug report. With patching, wouldn't it be simpler to just add -lstdc++ to CXX_LINKER_FLAGS at configuration time (in debian/rules) rather than hacking the upstream detection code? As you say, hardcoding in the upstream scripts doesn't really resolve the underlying problem. Is there a reason why hacking CXX_LINKER_FLAGS in debian/rules doesn't fix the build? Drew
Bug#1043313: libsuperlu-dev: Inconsistent declaration of double{C,M}alloc()
Source: superlu Followup-For: Bug #1043313 Upstream has just released a new version to fix it. Apparently it introduced other problems however. Let's see what upstream's response to that is.
Bug#1041372: #1041372 xtensor autopkg tests fail on i386 and s390x
forwarded 1041372 https://github.com/xtensor-stack/xtensor/issues/2718 thanks Evidently triggered by excess precision changes in gcc-13, see https://gcc.gnu.org/gcc-13/porting_to.html
Bug#1041705: dolfin: libdolfin needs ABI bump
Source: dolfin Version: 2019.2.0~legacy20230609.8b85e9d.ar-2 Severity: serious Justification: Policy 8.6.2 Control: affects -1 python3-mshr The accumulation of git changes and gcc-13 fixes has apparently introduced an ABI inconsistency in libdolfin.so, such that mshr can no longer be imported in python, and mshr tests fails. see https://ci.debian.net/data/autopkgtest/testing/amd64/f/fenics/36044020/log.gz https://ci.debian.net/data/autopkgtest/testing/amd64/m/mshr/36044021/log.gz A rebuild of mshr fixes the issue, but really dolfin shouldn't migrate to testing if it's doing this, so marking severity: serious. A new upstream release is expected soon which we'll treat as an ABI upgrade to resolve the issue.
Bug#1037823: marked as pending in pythran
Control: tag -1 pending Hello, Bug #1037823 in pythran reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/pythran/-/commit/3dedbc4004f9321559311ad246d77ddccebbbcb3 add debian patch gcc13_PR2029.patch applies upstream PR#2029 to fix build with gcc-13. Closes: #1037823. (this message was generated automatically) -- Greetings https://bugs.debian.org/1037823
Bug#1037854: scipy: ftbfs with GCC-13
Source: scipy Followup-For: Bug #1037854 The errors in the build log refer to pythran, not scipy.
Bug#1036576: libscotch{,par}metis-dev: broken symlinks: /usr/lib//*metis-*/lib*metis.* -> ../scotch-*/lib*metis.*
Package: libscotchmetis-dev Version: 7.0.3-1 Followup-For: Bug #1036576 Awkward. Thanks for catching it.
Bug#1032488: opendrop: arkode (sundials) error prevents interfacial tension analysis
Package: opendrop Version: 3.3.1-4 Severity: grave Tags: patch upstream Justification: renders package unusable debian patch sundials_nvector_API6.patch enabled opendrop to build against sundials 6. Nevertheless it still fails when attempting to analysis interfacial tension measurements: [ARKODE::ERKStep ERROR] erkStep_FullRHS At t = inf, the right-hand side routine failed in an unrecoverable manner. [ARKODE ERROR] ARKODE At t = 0, the right-hand side routine failed in an unrecoverable manner. Exception in callback PendantAnalysisJob._ylfit_done() handle: )> concurrent.futures.process._RemoteTraceback: """ Traceback (most recent call last): File "/usr/lib/python3.11/concurrent/futures/process.py", line 256, in _process_worker r = call_item.fn(*call_item.args, **call_item.kwargs) ^ File "/usr/lib/python3/dist-packages/opendrop/fit/younglaplace/__init__.py", line 51, in young_laplace_fit model.set_params(initial_params) File "/usr/lib/python3/dist-packages/opendrop/fit/younglaplace/model.py", line 86, in set_params dr_dBo, dz_dBo = radius * shape.DBo(s) File "opendrop/fit/younglaplace/shape.pyx", line 71, in opendrop.fit.younglaplace.shape.YoungLaplaceShape.DBo File "opendrop/fit/younglaplace/shape.pyx", line 89, in opendrop.fit.younglaplace.shape.YoungLaplaceShape.DBo_array RuntimeError: ERKStepEvolve() failed. """ The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/opendrop/vendor/aioglib/_loop.py", line 463, in __call__ self._context.run(self._callback, *self._args) File "/usr/lib/python3/dist-packages/opendrop/app/ift/services/analysis.py", line 219, in _ylfit_done raise e File "/usr/lib/python3/dist-packages/opendrop/app/ift/services/analysis.py", line 217, in _ylfit_done result = fut.result() RuntimeError: ERKStepEvolve() failed. Upstream has prepared a patch to update properly for sundials 6 in commit cf9d5aa (development branch), https://github.com/jdber1/opendrop/commit/cf9d5aa2f06d625f306114d001a99934cb913ff0 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_AU:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages opendrop depends on: ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1 ii gir1.2-gtk-3.03.24.36-4 ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libpython3.11 3.11.2-5 ii libstdc++612.2.0-14 ii libsundials-arkode5 6.4.1+dfsg1-3 ii python3 3.11.2-1 ii python3-cairo 1.20.1-5+b1 ii python3-gi3.42.2-3+b1 ii python3-injector 0.20.1-1 ii python3-matplotlib3.6.3-1+b1 ii python3-numpy 1:1.24.2-1 ii python3-opencv4.6.0+dfsg-11 ii python3-scipy 1.10.1-2 opendrop recommends no packages. Versions of packages opendrop suggests: ii opendrop-doc 3.3.1-4.1 -- no debconf information
