On 2025-05-30 23:23, Santiago Vila wrote:
El 30/5/25 a las 23:10, Drew Parsons escribió:
Source: pymatgen
Followup-For: Bug #1106436
Ah true, in this case the test failure is more specific.
uncertainties/3.2.3-2 was uploaded in the middle of the package
freeze,
and seems to be triggering
Source: pymatgen
Followup-For: Bug #1106436
Ah true, in this case the test failure is more specific.
uncertainties/3.2.3-2 was uploaded in the middle of the package freeze,
and seems to be triggering failure in pymatgen's
TestInterfaceReaction.test_get_entry_energy
Should uncertainties/3.2.3-2 b
Source: pymatgen
Followup-For: Bug #1106436
pymatgen tests are known to be broadly flakey.
If you run your build test again, it will likely pass.
Package: release.debian.org
Followup-For: Bug #1106702
I think the risk is low.
It's a new package so there won't be so many users using the old version.
And the new version will be good for new users.
So I'll take responsibility and upload to unstable.
2025-05-27 12:30:36.0 +0200
@@ -1,3 +1,12 @@
+scifem (0.6.0-1) experimental; urgency=medium
+
+ * New upstream release
+- updates blocked solver API
+- updates read_mri_data_to_function
+- fixes xdmf and adios2 file handling
+
+ -- Drew Parsons Tue, 27 May 2025 12:3
Package: ovito
Followup-For: Bug #1071132
For the record, the problem is the sphinx flag -W,
which treats warnings as errors.
This flag is activated by default by ovito's cmake configuration option
OVITO_BUILD_DOCUMENTATION_STRICT.
Our build will be more robust against doc build issues if we swit
Source: qwt
Version: 6.3.0-1
Severity: serious
Justification: Policy 8.1
Control: affects -1 src:ovito
qwt 6.3.0-1 generates binary packages libqwt-qt6-dev and libqwt-qt6-6.3
The problem is that qwt previously generated libqwt-qt6-6.2, and both
libqwt-qt6-6.2 and libqwt-qt6-6.3 provide
/usr/lib/
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: ov...@packages.debian.org
Control: affects -1 + src:ovito
User: release.debian@packages.debian.org
Usertags: binnmu
nmu ovito_3.10.5~ds-1 . ANY . experimental . -m "rebuild against libqwt-qt6-dev
6.3"
Provisioning of libqwt-qt6-dev
Package: release.debian.org
Followup-For: Bug #1106409
Thanks Bastian, and thanks all for the discussion.
Drew
On 2025-05-24 19:30, Sebastian Ramacher wrote:
On 2025-05-24 15:58:02 +0200, Drew Parsons wrote:
[ ] I reviewed all changes and I approve them
No, this is not "my" package. I'm just trying to prevent removal of
sasview.
With "978 files changed, 431012 insertions
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: magic...@packages.debian.org
Control: affects -1 + src:magics++
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package magics++
[ Reason ]
I'm not sure why magics++ wasn't ready to migrate before.
It was up
Source: entrypoints
Followup-For: Bug #1105737
Control: affects 1105737 - release.debian.org
The evil eye on adios4dolfinx has now been lifted, thank you.
Source: entrypoints
Followup-For: Bug #1105737
Control: affects 1105737 release.debian.org
Why is Bug#1105737 causing python3-adios4dolfinx to get kicked out
from trixie?
Please stop it doing that.
+++ nwchem-7.2.3/debian/changelog 2025-05-12 22:07:59.0 +0200
@@ -1,3 +1,16 @@
+nwchem (7.2.3-10) unstable; urgency=medium
+
+ * rebuild against ga (libglobalarrays-dev) 5.9.2
+
+ -- Drew Parsons Mon, 12 May 2025 22:07:59 +0200
+
+nwchem (7.2.3-9) unstable; urgency=medium
On 2025-05-17 18:56, Paul Gevers wrote:
Hi,
On 17-05-2025 17:21, Drew Parsons wrote:
Please unblock package petsc
The excuses already say:
Will attempt migration (Any information below is purely informational)
In other words, I already took care of this earlier today.
Paul
Thanks Paul!
#4906.
+Closes: #1104387
+
+ -- Drew Parsons Sun, 11 May 2025 23:44:46 +0200
+
mdanalysis (2.9.0-7) unstable; urgency=medium
* skip all parallel tests, including multiprocess tests.
diff -Nru mdanalysis-2.9.0/debian/rules mdanalysis-2.9.0/debian/rules
--- mdanalysis-2.9.0/debian/rules
gelog
--- ga-5.9.1/debian/changelog 2025-03-20 00:51:24.0 +0100
+++ ga-5.9.2/debian/changelog 2025-05-11 13:55:07.0 +0200
@@ -1,3 +1,19 @@
+ga (5.9.2-1) unstable; urgency=medium
+
+ * Team upload.
+ * New upstream release
+ * Standards-Version: 4.7.2
+
+ -- Drew Parsons Sun, 1
Package: release.debian.org
Followup-For: Bug #1105946
Control: block 1102696 by bug 1105946
Control: affects 1105946 src:petsc4py
The impact of this unblock request is stronger than I first indicated.
Some dependent packages have been marked with removal bugs because
migration was delayed by mpic
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: pe...@packages.debian.org
Control: affects -1 + src:petsc
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package petsc
[ Reason ]
petsc migration was held up for a long long time by problems with the
mpich
.0.2/debian/changelog 2025-05-08 22:45:59.0 +0200
@@ -1,3 +1,9 @@
+packmol (1:21.0.2-1) unstable; urgency=medium
+
+ * New upstream release
+
+ -- Drew Parsons Thu, 08 May 2025 22:45:59 +0200
+
packmol (1:21.0.1-1) unstable; urgency=medium
* New upstream release
diff -Nru pack
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: sc...@packages.debian.org
Control: affects -1 + src:scipy
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package scipy
[ Reason ]
scipy 1.15.3 is an upstream bugfix release with no new features.
It would be
Source: python-ase
Followup-For: Bug #1042048
Control: tags -1 ftbfs
python-ase 3.24.0-1 is still building successfully on buildd and
the regular reproducibility checks at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-ase.html
Lucas, is your test system still reporting
Package: ovito
Followup-For: Bug #1071132
There is something weird about this error
(not the accessing internet, but the failure when it cannot).
sphinx does not normally fail if the intersphinx urls cannot be
accessed. For instance scipy docs refer to "neps", which is not
available, but that in
Source: python-diagrams
Version: 0.23.4-1
Followup-For: Bug #1057174
This dependency was fixed in diagrams 0.24.1.
typed_ast was only needed for python_version<'3.8',
The dependency was fixed when python 3.12/3.13 support was added,
https://github.com/mingrammer/diagrams/pull/972
See also https
Source: libfabric
Followup-For: Bug #1102068
Control: tags -1 ftbfs patch
It looks like Gonzalo Silvalde Blanco's patch (salsa MR) at
https://salsa.debian.org/hpc-team/libfabric/-/merge_requests/4
should be able to fix the bug.
Source: flox
Version: 0.10.3-1
Severity: serious
Justification: debci
test_first_last from test_properties.py is regularly failing in debci
testing on riscv64, e.g.
https://ci.debian.net/data/autopkgtest/testing/riscv64/f/flox/60337814/log.gz
https://ci.debian.net/data/autopkgtest/testing/riscv64/
Source: mdanalysis
Followup-For: Bug #1104387
Control: tags -1 ftbfs
Control: forwarded -1 https://github.com/MDAnalysis/mdanalysis/issues/4906
There is a degree of flakiness in the mdanalysis tests, known upstream,
https://github.com/MDAnalysis/mdanalysis/issues/4209
https://github.com/MDAnalysis
e
reverted really4.2.1 version of mpich.
Drew
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: python-meshp...@packages.debian.org
Control: affects -1 + src:python-meshplex src:python-dmsh
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package python-meshplex
[ Reason ]
meshplex was removed from test
Package: mpich
Followup-For: Bug #1101686
Control: forwarded -1 https://github.com/pmodels/mpich/issues/7399
Post scriptum for this mpich gpu bug,
upstream received notice about the problem with gpu support
https://github.com/pmodels/mpich/issues/7399
and has now applied a patch
https://github.c
Thanks. Confirming the bug seems to be fixed in Gnome 48.
Source: pymatgen
Followup-For: Bug #1103427
Control: severity -1 normal
It's a network test, and marked with needs-internet
At the particular point in time you saw a failure,
online database being accessed was offline.
Downgrading severity. This is not an ongoing bug.
Package: mpich
Version: 4.3.0-5
Followup-For: Bug #1102612
Control: found -1 4.3.0-5
Control: fixed -1 4.3.0-6
Updating tags (the fixed version is in experimental, the version in
unstable is not yet updated).
Source: superlu-dist
Version: 8.2.1+dfsg1-5
Severity: important
Tags: ftbfs
Control: forwarded -1 https://github.com/xiaoyeli/superlu_dist/issues/165
Upstream has release superlu-dist 9,
but it fails to build against CombBLAS:
cd /repositories/superlu-dist/obj-x86_64-linux-gnu/EXAMPLE && /usr/bin
Source: libfabric
Version: 2.1.0-1
Followup-For: Bug #1102068
Control: tags -1 ftbfs
Control: reopen -1
I think that bug closed by mpich 4.3.0-6 was meant to be one of the
other mpich bugs (#1102612).
32-bit arches are still failing to build libfabric 2.1.0-1 the same way,
so reopening this bug.
Package: mpich
Followup-For: Bug #1102612
Is this upstream bug related to the problem?
https://github.com/pmodels/mpich/issues/7064#issuecomment-2301026290
It suggests the pmix build configuration might be an issue.
The timing of that bug doesn't match well, though, it was made in
August 2024, be
Package: nwchem
Followup-For: Bug #1102731
Control: tags 1102731 moreinfo
Control: severity 1102731 normal
Hi Helmut, can you give more information on where you find the file
conflict?
/usr/bin/nwchem is a symlink to the build for the default MPI for the
given architecture.
On 64-bit systems op
Package: mpich
Followup-For: Bug #1102612
There is evidence that libucx0 might be the problem, or a problem,
in the ga (libglobalarrays-dev) build logs
https://buildd.debian.org/status/fetch.php?pkg=ga&arch=amd64&ver=5.9.1-1&stamp=1744381093&raw=0
e.g. FAIL: global/testing/pgtest
copy is OK
Package: mpich
Version: 4.3.0-5
Followup-For: Bug #1102612
One data point might be relevant. The bug reported here manifests in
the amd64 and arm64 tests of armci-mpi.
But the armci-mpi tests are passing cleanly on the 32-bit arches, armhf and
the others.
I note that the build time mpich errors
Source: petsc
Followup-For: Bug #1102465
Control: block 1102465 by 1102612
Control: severity 1102465 normal
Thinking about it further, I don't think we have a bug here as such,
and I'm therefore lowering severity.
I don't think any action is needed either. The latest petsc build requires
the late
Package: mpich
Version: 4.3.0-5
Severity: serious
Justification: debci
I apologise for another serious bug, but mpich 4.3 is doing weird
things that we don't want in trixie. I see the problem in mpich test
errors in armci-mpi
(https://buildd.debian.org/status/fetch.php?pkg=armci-mpi&arch=amd64&ver
Control: block -1 by 1101686
On 2025-04-09 11:15, Adrian Bunk wrote:
Source: petsc
Version: 3.22.3+dfsg1-1
Issues preventing migration:
∙ ∙ autopkgtest for dolfin/2019.2.0~legacy20240219.1c52e83-18: amd64:
Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻),
armhf: Regression or
Package: mpich
Version: 4.3.0-4
Followup-For: Bug #1101686
Control: reopen 1101686
Alistair, mpich 4.3.0-4 is still triggering gpu errors in armci-mpi,
bagel and eztrace.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500,
Source: fenics-dolfinx
Followup-For: Bug #1096624
Control: tags -1 ftbfs
There is a fair change this is not a gcc-15 bug, nor even a bug at all.
It's more likely to be a nanobind inconsistency.
All nanobind clients need to be rebuilt at the same time to maintain
interoperability.
cf. dolfinx-mpc
Source: xtl
Version: 0.7.7-1
Severity: normal
xtl 0.8.0 is now released.
It is needed by xtensor 0.26.0.
Should we try to get them into trixie?
On 2025-04-01 02:08, Dirk Lehmann wrote:
Package: wnpp
Severity: wishlist
Owner: Dirk Lehmann
X-Debbugs-Cc: debian-scie...@lists.debian.org
* Package name: python-qutip
Version : 5.1.1
Upstream Contact: https://github.com/qutip/qutip/discussions
* URL : https://githu
Source: libfabric
Severity: serious
Tags: ftbfs
Justification: ftbfs
X-Debbugs-Cc: debian-am...@lists.debian.org, debian-...@lists.debian.org,
debian-h...@lists.debian.org, debian-powe...@lists.debian.org,
debian-sup...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: armel armhf
User
Package: pipewire
Version: 1.4.1-1
Followup-For: Bug #1100943
Also happening on my end with combination of this and fluidsynth. I
independently stumbled upon the workaround. As I don't want to get rid of
fluidsynth, I've put the workaround in my session startup for now.
Thank you for your time.
Package: mpich
Version: 4.3.0-4
Followup-For: Bug #1101686
Control: affects -1 src:armci-mpi src:bagel src:eztrace
It looks like there might have been a problem with the 4.3.0-4 upload.
Changelog says it disabled GPU (HIP) support, but looks like the wrong
bug numbers might have been given (this
On 2025-04-01 03:00, Dirk Lehmann wrote:
Hello Drew
On 4/1/25 2:56 AM, Drew Parsons wrote:
On 2025-04-01 02:08, Dirk Lehmann wrote:
Package: wnpp
Severity: wishlist
Owner: Dirk Lehmann
X-Debbugs-Cc: debian-scie...@lists.debian.org
* Package name : python-qutip
Version : 5.1.1
for `python3-qutip-qip`.
Note that the ITPs are filed for source packages, not binary packages.
So only one python-qutip-qip source package is needed.
The docs are included in the source, and built
alongside the python3-qutip-qip binary package.
Drew
27;re just reconfiguring
the packaging to move the existing contents to a new python3-qutip-core
package instead of python3-qutip, and retaining python3-qutip as a
dependency package. They're made from the same (existing) source
package.
Drew
Package: mpich
Version: 4.3.0-3
Severity: serious
Justification: FTBFS
The new mpich 4.3.0 is doing something different with GPUs that is
causing test failures.
mpich itself was affected, Bug#1100880, but 4.3.0-3 hid the problem by
disabling GPU support in autopkgtests. That doesn't help other
pa
Source: fenics-dolfinx
Followup-For: Bug #1096624
Control: tags -1 ftbfs
"change" = "chance" in the message above
Source: fenics-dolfinx
Version: 1:0.9.0-6
Severity: normal
The pusimp test in fenics-dolfinx/debian/tests/test-dolfinx-python-pusimp
invokes pytest with -s.
This means the tested error conditions get displayed, even when the
test is successful, e.g. showing
ImportError: pusimp has detected the
Source: scipy
Followup-For: Bug #1100538
Control: tags -1 moreinfo
How are you accessing the docs?
The doc packages are constructed to be accessed locally
from the local filesystem, not from a web server, at least that's how
I access them
i.e. from
file:///usr/share/doc/HTML/index.html
not
h
Source: pmix
Version: 5.0.7-1
Followup-For: Bug #1098576
Control: tags -1 ftbfs
There is some caprice in this bug.
I tested mpi4py again with the new versions pmix 5.0.7 and linux 6.12.19.
Locally (dpkg-buildpackage) the tests passed without error.
So I figured the problem might have been fixed
Upon further investigation, I think it is very unlikely this misbehavior is
due to the gnome-keyring
debian package. The relevant code in upstream[1] is very old. It appears to
check for the existence
of both dirs and prioritizes the new one if both dirs exist. The creation
timestamp for the new di
Package: gnome-keyring
Version: 48~beta-3
Severity: important
X-Debbugs-Cc: drewpvo...@gmail.com
Dear Maintainer,
It appears the upgrade of gnome-keyring-daemon does not always
account for the existance of keyring files. After upgrading
with apt dist-upgrade, I rebooted.
After reboot, multiple
On 2025-03-22 13:22, Santiago Vila wrote:
Hi.
I've just made a team upload trying to address this.
The skips would probably needs to be added to both debian/rules and
debian/tests.
I was unsure about how to do that, but then I looked at the
autopkgtests logs
and realized that the tests mark
Package: mpich
Version: 4.3.0-2
Severity: serious
Justification: debci
Control: affects -1 src:armci-mpi
mpich 4.3 is doing something different with gpu support,
that is causing tests to fail, both mpich's own tests (on amd64 etc)
and build tests in other packages like armci-mpi.
For instance, mp
Source: dipy
Version: 1.10.0-2
Severity: serious
Tags: ftbfs
Justification: FTBFS
X-Debbugs-Cc: debian-s...@lists.debian.org
User: debian-s...@lists.debian.org
Usertags: s390x
dipy 1.11 is trying to access a scipy algorithm which is apparently
not supported on s390x,
ValueError: scipy.sparse doe
Source: dolfinx-mpc
Followup-For: Bug #1096535
Control: tags -1 ftbfs
Upstream has run a battery of tests.
Looks like gcc-15 is not a problem itself.
The problem might not be the nanobind version either (sometimes
nanobind upgrades will give an ABI conflict, but 2.5 is supposed to be
be compatib
Package: dh-python
Followup-For: Bug #958152
Correction, PYBUILD_TEST_PYTEST=1 actually does work.
Which proves the point of this bug. How are we supposed to know that
is the env variable syntax for --test-pytest, without having to wildly
guess it? Please add documentation for the variables.
Package: dh-python
Version: 6.20250308
Followup-For: Bug #958152
I agree with this bug report. The documention does not make it clear
how to set the environment variables that control dh's use of pybuild.
For instance the pybuild man page says there are options to set which
test system is used.
Package: libopenmpi-dev
Followup-For: Bug #1100120
Control: retitle -1 libopenmpi-dev: mpi4py spawn tests fail with MPI_ERR_UNKNOWN
Control: severity -1 normal
The OPAL ERROR or libucs segfault at the end of the tests can be
avoided by setting OMPI_MCA_btl_tcp_if_include=lo
(that's with OMPI_ not
Package: libopenmpi-dev
Followup-For: Bug #1100120
We can see the spawn errors in the mpi4py 4.0.3-2 build logs,
e.g.
https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=amd64&ver=4.0.3-2&stamp=1741705221&raw=0
Skipping the test_spawn tests, remaing tests pass
but I get the following err
Many.testNoArgs)
--
Traceback (most recent call last):
File "/home/drew/projects/python/build/mpi4py/test/test_spawn.py", line 175,
in testNoArgs
child = self.COMM.Spawn(
script, None, self.MAXPROCS,
info=self.INFO, root=self.ROOT,
)
File "src/
Source: pmix
Followup-For: Bug #1098576
Control: tags -1 ftbfs
These PMIx errors seem to be accompanied with kernel errors, including
a GPF from libc which doesn't sound good. In /var/log/syslog:
2025-03-10T20:51:04.457486+01:00 debbox kernel: traps: prte[126492] general
protection fault ip:7f00
Source: dolfinx-mpc
Followup-For: Bug #1096535
Control: tags -1 ftbfs
Control: affects -1 src:nanobind
Your build log shows the build used package versions
gcc-15 15-20250213-1
nanobind 2.5.0-1
dolfinx 1:0.9.0-6+b2
python 3.13.2-1
dolfinx 1:0.9.0-6+b2 was built against nanobind 2.4.0-1 and python
Source: dipy
Followup-For: Bug #1096208
Control: severity -1 serious
scipy 1.15 is now uploaded to unstable, so raising to severity: serious
Source: pmix
Followup-For: Bug #1098576
Control: tags -1 ftbfs
It's quite possible the bug is in openmpi, not pmix itself.
For instance mpich isn't triggering the error in the mpi4py tests
cf.
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/mpi4py.html
There was a patch in ope
Source: datalab
Followup-For: Bug #1098652
Control: forwarded -1 https://github.com/DataLab-Platform/DataLab/issues/117
reported upstream
https://github.com/DataLab-Platform/DataLab/issues/117
Upstream says this is a bug in scipy 1.15,
https://github.com/scipy/scipy/issues/22586
proposed patch i
Source: dipy
Followup-For: Bug #1096208
numpy 2 is now transitioned to testing.
I guess it should be safe to upload the dipy patch now?
Drew
Package: gdm3
Followup-For: Bug #1008296
Poking the internet around wayland and nvidia, I found that gdm3 is
set up to deactivate wayland if it finds nvidia is available but not fully
configured. This is why gdm does not show the Wayland option for the
Gnome session. It has deliberately been dis
Source: mpi4py
Followup-For: Bug #1098576
Control: tags -1 ftbfs
Control: reassign -1 libpmix-dev
Control: affects -1 src:mpi4py
I guess this is a problem in the PMIX library, not mpi4py.
It might be just a transition mismatch with the recent
pmix and openmpi updates.
Drew
Source: spglib
Followup-For: Bug #1094821
numpy2 is now in testing, and spglib tests are passing.
I think we can close this bug now.
Package: acpi-call-dkms
Followup-For: Bug #1098805
X-Debbugs-Cc: debian-am...@lists.debian.org
User: debian-am...@lists.debian.org
Usertags: amd64
Control: tags -1 ftbfs
Control: severity -1 normal
I was confused by the last update date of acpi-call-dkms (22 Feb)
and thought my issue was triggered
Package: acpi-call-dkms
Version: 1.2.2-2.1
Severity: serious
Tags: ftbfs
Justification: FTBFS
Upgrading to 1.2.2-2.1, acpi-call-dkms is failing to build kernel modules,
complaining about existing source:
Setting up acpi-call-dkms (1.2.2-2.1) ...
Removing old acpi-call/1.2.2 DKMS files...
Loading
Source: datalab
Version: 0.18.1-1
Severity: normal
X-Debbugs-Cc: debian-...@lists.debian.org
User: debian-...@lists.debian.org
Usertags: arm64
datalab on arm64 is failing tests against scipy 1.15 from experimental.
amd64 is passing tests. not clear what the problem is.
Source: qutip
Followup-For: Bug #1098454
Control: reassign 1098454 wnpp
Control: retitle 1098454 RFP: qutip-qip -- QuTiP quantum information processing
Hi Dirk, qutip-qip is a separate package (a plugin addon package for
qutip). Its home page is https://github.com/qutip/qutip-qip
What you're requ
The KeyError: 'l' error is no longer triggered.
I think it was an issue in one of the other packages, not pymatgen,
and now fixed.
I think we can close these bugs now unless you're seeing other
issues with the package.
True, there is some other different error in 32-bit testing.
I think again t
mdanalysis 2.8.0-4 is now passing tests.
The only change was to run tests verbose, so perhaps the fix was made in numpy2
or multiprocessing.
1096176 may have been fixed by mdanalysis 2.8.0.
I think we can close these bugs now, unless you're seeing any other problems.
Drew
Package: python3-numpy
Version: 1:2.2.3+ds-1
Severity: important
For numpy2 files for building numpy extensions have been moved to
python3-numpy-dev.
As a side effect this has broken f2py.
/usr/lib/python3/dist-packages/numpy/f2py/f2py2e.py l.451 accesses
fortranobject.c amd .h from the src subd
Package: mc
Version: 3:4.8.33-1
Severity: important
The recent mc upgrade appears to have introduced a major regression in
behaviour of the command line subshell. I'm referring to the
single-line command line appearing near the bottom of the normal mc
screen below the list of files, not the full s
remain operational as they are and
automatically gain from the speed up if executed on GPU-supporting
hardware?
Is the GPU support available for all our CPU architectures?
Drew
Source: xrayutilities
Version: 1.7.8-2
Severity: normal
xrayutilities is failing tests with scipy 1.15 from experimental,
evidently due to use of deprecated API.
Version 1.7.10 has been released upstream and should be compatible.
https://ci.debian.net/data/autopkgtest/unstable/amd64/x/xrayutili
Source: scikit-learn
Version: 1.4.2+dfsg-7
Severity: normal
scikit-learn is failing tests with scipy 1.15 from experimental
https://ci.debian.net/data/autopkgtest/unstable/amd64/s/scikit-learn/57873442/log.gz
256s FAILED
../../../../usr/lib/python3/dist-packages/sklearn/preprocessing/tests/test
Source: dipy
Version: 1.10.0-2
Severity: normal
dipy is failing tests with scipy 1.15 from experimental
e.g.
https://ci.debian.net/packages/d/dipy/unstable/amd64/57839450/
1756s FAILED reconst/tests/test_csdeconv.py::test_odfdeconv - AssertionError:
1756s FAILED reconst/tests/test_csdeconv.py:
Control: reassign 1096194 python3-ffcx
On 2025-02-17 15:18, Stefano Rivera wrote:
Hi Drew (2025.02.17_13:15:52_+)
python3-cffi has Suggests: python3-dev
But when actually using cffi, it needs Python.h and pyconfig.h
(included in /usr/lib/python3/dist-packages/cffi/_cffi_include.h)
There
Followup-For: Bug #1096194
Control: reassign 1096194 src:scifem
No, this was a misdiagnosis.
python3-ffcx already does have Depends: python3-dev
The issue here is that scifem tests do not explicitly require
python3-dev, and then, more to the point, the scifem test is failing
with Python 3.12.
T
Package: python3-cffi
Version: 1.17.1-2
Severity: important
python3-cffi has Suggests: python3-dev
But when actually using cffi, it needs Python.h and pyconfig.h
(included in /usr/lib/python3/dist-packages/cffi/_cffi_include.h)
That suggests to me the dependency might best be bumped to a strong
Source: scipy
Followup-For: Bug #1083172
True, something has gone badly wrong with the doc package for scipy 1.14.
In the meantime you may want to try scipy 1.15 from experimental.
The scipy 1.15 docs are in place.
(the style is broken, which is a different issue as noted in Bug#1088105)
Package: autopkgtest
Version: 5.44
Severity: normal
autopkgtest started failing to start tests today.
Previously it was able to launch tests.
I'm launching tests using autopkgtest-virt-null, as
autopkgtest -B -- null
The new error comes from add_apt_preference.
I haven't (knowingly) changed an
This is a weird error. But pymatgen is successfully building now.
I guess the problem was in another package, and has been fixed.
When the new build passes debci and is ready to migrate to testing,
I'll close these bugs, unless there is any other news
to keep them open.
Drew
Source: mdanalysis
Followup-For: Bug #1095739
Yes, I'll add a verbose test flag to armel to help monitor what's
troubling it. Upstream marked some distance tests as flaky, but the
way they did it broke the tests so it had to be reverted.
Drew
Source: mdanalysis
Followup-For: Bug #1095739
Control: tags -1 ftbfs
Thanks. Waiting for build reports from mips64el riscv64
before fixing.
Drew
Package: python3-meshplex
Followup-For: Bug #1094984
Control: tags -1 ftbfs
Control: block -1 by 1094985
The bug is effectively in meshio, meshplex is simply accessing a mesh
returned by meshio.
The problem is that the 2D cell type ("triangle") has no dtype
attached to the cell array. Evidently
have been fixed in Numpy 2,
but apparently it has gotten worse instead.
The workaround is to skip the tests until a proper fix is found.
Drew
On 2025-01-29 00:53, Adrian Bunk wrote:
Source: scipy
Version: 1.14.1-3
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: Drew Parsons
https://buildd.debian.org/status/package.php?p=scipy
...
=== short test summary info
FAILED scipy/special
1 - 100 of 1217 matches
Mail list logo
