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
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: 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: 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: 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
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: 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
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
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
Package: libopenmpi-dev
Version: 5.0.7-1
Severity: serious
Justification: FTBFS (dependencies)
mpi4py build-time tests are showing problems in openmpi, with
buildtime tests failing. That's with mpi4py 4.0.3-1.
debci tests from its last build are still passing for now.
I'm assuming the bug is in o
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: 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: 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
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
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
Control: tag -1 pending
Hello,
Bug #1094477 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/a021a20cf8d7ae58
Source: scipy
Followup-For: Bug #1094477
Control: tags -1 ftbfs
Control: forwarded -1 https://github.com/scipy/scipy/issues/21393
The problem seems to be complex number support on mips64el.
There had already been problems with test_cython.py, see upstream
Issue#21393.
The issue was supposed to ha
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
On 2025-01-19 14:44, Colin Watson wrote:
You can achieve that with:
PY3VERS=$(PY3DEF)
+PY3RANGE=$(shell echo $(PY3DEF) | awk 'BEGIN { FS="." }; { print $$1
"." $$2 "-" $$1 "." $$2 + 1 }')
+ dh_python3 -V $(PY3RANGE) --no-ext-rename # Hack: Do not rename
libraries from e.g. vtkClientServerPy
Package: paraview
Followup-For: Bug #1093278
I'd be interested too to know if there's an existing mechanism for
this situation. paraview can't be the only package with python
extensions that can only be built for the default python.
I'd say we'd want
Depends: python3.13
rather than
Depends: p
On 2025-01-13 21:12, Drew Parsons wrote:
Both these patches landed in vtk 9.4,
so the simplest fix is to upgrade to the latest upstream release.
Well, maybe not the "simplest" fix since it will need new binary package
libvtk9.4.
But that needs to be done sooner or later.
Package: vtk9
Followup-For: Bug #1092354
Control: forwarded 1092354 https://gitlab.kitware.com/vtk/vtk/-/issues/19466
Reported and fixed upstream,
https://gitlab.kitware.com/vtk/vtk/-/merge_requests/11486
Found also in paraview, which shamefully ships its own vtk and needs
the same patch.
There
Source: dolfin
Followup-For: Bug #1088865
I tested my own legacy code with dolfin on python3.13.
It's still running perfectly fine.
It looks like the damage here is restricted to the mesh iterators,
in MESHITERATOR_MACRO and also mesh.SubsetIterator()
If you're not using those iterators, then th
Source: dolfin
Followup-For: Bug #1088865
All of the MESHITERATOR_MACRO functions in python/src/mesh.cpp are
affected (cells, facets, faces, edges, vertices)
so I guess the problem is somewhere in MESHITERATOR_MACRO:
#define MESHITERATOR_MACRO(TYPE, NAME) \
py::class_, \
std::
Source: dolfin
Version: 2019.2.0~legacy20240219.1c52e83-11
Followup-For: Bug #1088865
The mesh itself seems to be fine.
>From Francesco's example, both python 3.12 and 3.12 give
>>> mesh.cells()
array([[0, 1, 4],
[0, 3, 4],
[1, 2, 5],
Control: tag -1 pending
Hello,
Bug #1088664 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/70d458df13fe80d2dce3996fad95
On 2024-12-22 11:33, Emilio Pozuelo Monfort wrote:
On Sat, 21 Dec 2024 23:34:42 +0100 Andreas Beckmann
wrote:
Control: affects -1 + src:slepc src:fenics-dolfinx src:mpich
On Sat, 21 Dec 2024 19:19:43 +0200 Drew Parsons
wrote:
> This is a delicate issue. The strict version test is in
Source: petsc
Followup-For: Bug #1090791
This is a delicate issue. The strict version test is in the upstream
headers. I imagine they have their reasons for making it so.
Source: fenics-dolfinx
Followup-For: Bug #1090900
X-Debbugs-Cc: 1088...@bugs.debian.org
There's something wrong here.
fenics-dolfinx 1:0.9.0-5+b1 is rebuilt against the
new hdf5 1.14, and passing tests in unstable.
The tests in testing are still using the old build 1:0.9.0-5 not
1:0.9.0-5+b1, so
On 2024-12-05 23:43, Santiago Vila wrote:
reopen 1087784
thanks
Hi. The OpenMPI transition has already happened, and this package still
fails to build in the AWS machines on which I do archive rebuilds.
I've put a recent build log in the same directory as before:
https://people.debian.org/~san
Source: openmpi
Followup-For: Bug #1088767
Looking into it a little, the soname for libprrte.so itself is set to 3.0.7
in 3rd-party/prrte/VERSION
https://salsa.debian.org/hpc-team/openmpi/-/blame/debian/latest/3rd-party/prrte/VERSION?ref_type=heads#L20
The symlink to 3.0.6 is set by debian in d
On 2024-11-30 20:23, stefa...@debian.org wrote:
Hi pini (2024.11.28_17:58:24_+)
Here is an improved patch proposal.
That's staged in git now. If you have any further improvements, let me
know, or I can upload it.
Thanks for helping sort it out. cmake doesn't make it easy to do
multi-py
On 2024-11-29 13:18, Emilio Pozuelo Monfort wrote:
On Fri, 22 Nov 2024 23:55:29 +0100 Drew Parsons
wrote:
Control: forwarded 1086489
https://github.com/xtensor-stack/xsimd/issues/1066
...
There's a suggestion in the bug report to fix an uninitialized read in
lgamma, which could be ca
Package: mantis-ray
Version: 3.1.15-3
Severity: serious
Justification: debci
mantis-ray is failing debci test due to use of a deprecated scipy API,
trapz from scipy.integrate, now removed in scipy 1.14
The error from
https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mantis-xray/54678182/log
Source: gerris
Version: 20131206+dfsg-19.1
Followup-For: Bug #1074988
Unfortunately that patch is not sufficient.
/bin/bash ../libtool --silent --tag=CC --mode=compile mpicc -DHAVE_CONFIG_H
-I. -I.. -I../src -I/usr/include -DG_LOG_DOMAIN=\"Gfs-modules\"
-I/usr/include/glib-2.0 -I/usr/lib/x86
On 2024-11-23 17:51, Stephane Popinet wrote:
Hi again,
Attached is a patch which should fix the (first) problem.
Stephane
Thanks Stephane, I'll apply the patch.
Drew
Source: gerris
Followup-For: Bug #1074988
Gerris upstream has not been updated since 2013.
We probably won't be able to (easily) patch it to work with gcc-14.
Probably we should just drop the gerris package from Debian.
Upstream has moved on to basilisk, which supersedes gerris.
http://basili
Package: paraview
Followup-For: Bug #1087764
Control: tags -1 ftbfs
Thanks Brad, that's fantastic.
I'll apply the patch.
Control: forwarded 1086489 https://github.com/xtensor-stack/xsimd/issues/1066
Emilio's verbose log shows
2885s 1:
/tmp/autopkgtest-lxc.8mniqst8/downtmp/build.OlH/src/test/test_xsimd_api.cpp:631:
ERROR: CHECK_EQ( extract(xsimd::lgamma(T(val))), std::lgamma(val) ) is NOT
correct!
2885s 1: valu
Subject: Re: hypre: FTBFS: Unable to find reachable pairing between local and
remote interfaces
Followup-For: Bug #1087784
Source: hypre
Control: tags -1 ftbfs
I'm pretty sure this is not a bug in hypre.
The OpenMPI 5 transition is still ongoing, it's almost certainly a
side effect of that.
Dre
On 2024-11-22 15:55, Emilio Pozuelo Monfort wrote:
On 19/11/2024 09:54, Emilio Pozuelo Monfort wrote:
Hi,
Running ctest in debian/tests/xsimd-test with --verbose and/or
--output-on-failure may help diagnose the issue.
I have uploaded the attached debdiff to DELAYED/2 to help debug this
fail
Control: tag -1 pending
Hello,
Bug #1086108 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/171db2f9ddeb
Package: cmake
Version: 3.31.0-2
Severity: serious
Justification: FTBFS
Control: block 1087764 by -1
cmake 3.31 has made a radical overhaul of LINKER handling, and appears
to have introduced a regression handling -Wl in LDFLAGS.
We applied a linker-related upstream patch in Bug#1087983, but the
p
Package: cmake
Version: 3.31.0-1
Severity: serious
Tags: patch
Justification: FTBFS
X-Debbugs-Cc: 1087...@bugs.debian.org
Control: block 1087764 by -1
Control: forwarded -1
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/10010
cmake 3.31 has made a radical change to LINKER handling
http
Subject: Re: FTBFS: /usr/bin/ld: unrecognized option '-Wl'
Followup-For: Bug #1087764
Package: paraview
Control: tags -1 ftbfs help
Looks like cmake 3.31 must have changed the way it handles LDFLAGS.
Nothing else in the tool chain handling LDFLAGS has changed since
october.
paraview debian/rules
Package: paraview
Followup-For: Bug #1087764
Control: tags -1 ftbfs
Note amd64 build perfectly fine before.
I'm not convinced this is a paraview bug,
feels more like the toolchain got broken somewhere.
Drew
Source: facet-analyser
Followup-For: Bug #1040334
Looking at the upstream repo, upstream is indeed using paraview to
build, not released VTK. i.e. it uses paraview's version of VTK
https://github.com/romangrothausmann/FacetAnalyser :
-DVTK_DIR=/paraview-build-dir/VTK/
see also
https://githu
Control: tag -1 pending
Hello,
Bug #1087609 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/6d16c18c56e3208c39ceda6901856
Control: tag -1 pending
Hello,
Bug #1087609 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/19d8f08d816c214cf8e8bfbc2feec
Source: python-orjson
Version: 3.10.7-1
Severity: serious
Justification: FTBFS
Control: affects -1 src:mypy src:numpy
python-orjson Build-Depends: cargo
But cargo was removed from Debian (unstable) in May 2024.
python-orjson therefore fails to build.
This prevents mypy and therefore numpy from b
Source: facet-analyser
Followup-For: Bug #1040334
As far as I can tell facet-analyser does not actually need
python3-paraview, except for two build-time tests
(basicPluginTest01 pvsm2webgl.py, and basicPluginTest02 pvsm2x3d.py)
I believe there is no conflict between paraview-dev and libvtk9-dev
t
Source: python-meshplex
Followup-For: Bug #1081876
Control: tags -1 ftbfs
I can't reproduce this bug.
Other tests are failing today (possibly python3.13 issues with scipy)
but test_remove_cells.py is passing its tests.
Drew
On 2024-11-08 20:26, Bill Allombert wrote:
Le Thu, Nov 07, 2024 at 08:12:22PM +0100, Andreas Tille a écrit :
Control: tags -1 help
Thanks
Hi,
today molds (from Debichem team) came up as candidate for the Bug of
the
Day[1]. I considered bug #1075979 easy to fix by simply adding
libopenmpi-de
Control: tag -1 pending
Hello,
Bug #1085264 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/fb3d0e721576acb2d9382cc3e326
Source: xtensor
Followup-For: Bug #1080464
X-Debbugs-Cc: Matthias Klose
> Fix feature check for clang-19+, taken from upstream.
Hi Matthias, could you provide a link to the upstream patch?
Drew
Source: hypre
Followup-For: Bug #1086275
Control: tags -1 ftbfs
> There are still failures like
> https://ci.debian.net/packages/s/superlu-dist/testing/amd64/53986621/
> which are a mystery to us (Francesco and Drew).
> Not sure from where the libmpi_cxx.so.40 dependency is coming in, and
> I can'
Source: hypre
Followup-For: Bug #1086275
Control: tags -1 ftbfs
> max available processors nproc=1
Almost certainly an oversubscribe issue.
OpenMPI 5 changed env variables: OMPI_ → PRTE_
Debian scripts will need to be updated in
most packages using MPI.
Source: sundials
Followup-For: Bug #1086386
Control: tags -1 ftbfs
For the most part it seems to be the _4 variants of the tests that
failed.
My guess is that 4 is the number of the processes used for the MPI test,
and the test machine does not have 4 CPUs available.
OpenMPI 5 changed the env va
Control: tag -1 pending
Hello,
Bug #1033528 in apbs 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/apbs/-/commit/5c4755dc8eb83913c2a727892bdb7797
Control: tag -1 pending
Hello,
Bug #1077646 in apbs 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/apbs/-/commit/c6ccac2e746f303b321ed132355d3a41
On 2024-10-26 14:24, Roland Mas wrote:
Hi Drew and Debichem team,
I just uploaded python-maggma to unstable; it's in NEW for now, but it
can be built from
https://salsa.debian.org/python-team/packages/python-maggma
If this helps python-mp-api forward, then that will unblock xraylarch
that d
Package: nwchem
Version: 7.2.3-3
Severity: serious
Justification: debci
/usr/bin/nwchem is provided by the nwchem package as a symlink to the
nwchem build for the default MPI. But the nwchem package is
arch-independent, and so built on amd64. Hence the symlink is set to
nwchem.openmpi (for amd64)
Package: catch2
Version: 3.7.1-0.1
Followup-For: Bug #1084909
Control: tags -1 ftbfs
Control: forwarded -1 https://github.com/catchorg/Catch2/issues/2808
Control: affects -1 src:fenicsx-dolfinx
One possible patch proposed at
https://github.com/AlexandreTunstall/nixos-riscv/commit/2c89852a2809a006f
reopen 1084255
thanks
I closed this bug too soon. It is triggered in rebuild against the new adios2.
Weird.
Package: python3-pydata-sphinx-theme
Followup-For: Bug #1084781
As as petsc4py goes, it can just switch off use of pydata-sphinx-theme
until this bug is fixed.
Source: pydata-sphinx-theme
Version: 0.15.4+dfsg-1
Followup-For: Bug #1084781
Control: affects 1084781 src:petsc4py
Control: block 1082552 by 1084781
petsc4py also uses pydata-sphinx-theme for docs, and FTBFS because of
this bug. The error log is
PYTHONPATH=/home/drew/projects/petsc/build/petsc4
Source: bmtk
Version: 1.1.1+ds-1
Severity: serious
Justification: debci
Control: affects -1 src:mpi4py
bmtk has started failing debci tests, due to a requirement for
distutils which is no longer packaged for debian
70s Processing triggers for libc-bin (2.40-3) ...
70s autopkgtest [13:09:51]: te
Source: pyzoltan
Followup-For: Bug #1081631
Ah, correction, zoltan is not built on the 32-bit arches, so we don't
need to worry about pyzoltan and mpi4py interacting with mpich.
Source: pyzoltan
Followup-For: Bug #1081631
Control: tags -1 ftbfs
Looks like one of the two solutions at
https://github.com/mpi4py/mpi4py/issues/525#issuecomment-2256633404
is what's needed.
We'll need to see how it goes with mpich (on the 32-bit arches).
Source: h5py
Followup-For: Bug #1080198
As far as I can read the test log, the mpich (32-bit) tests are not
actually failing. It looks like the error conditions is occuring
afterwards during shutdown. Perhaps some test files need to be
explicitly closed before shutdown.
reassign 1081631 src:pyzoltan
thanks
MPI_Session is defined in mpi4py.h
(/usr/lib/python3/dist-packages/mpi4py/include/mpi4py/mpi4py.h)
pyzoltan is not including it
Package: python3-mpi4py
Followup-For: Bug #1081631
mpi4py is scrupulously tested. It's more likely a bug in pyzoltan.
Control: tag -1 pending
Hello,
Bug #1081459 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/dcef3684f2a91cf3b798aa53c43b2
Package: python3-mpi4py
Version: 4.0.0-2
Severity: serious
Tags: ftbfs
Justification: FTBFS
Control: forwarded -1 https://github.com/mpi4py/mpi4py/issues/545
mpi4py 4 was building fine in experimental but shows tests error in
unstable:
testTestAll (test_util_pkl5.TestPKL5World.testTestAll) ... ok
Control: tag -1 pending
Hello,
Bug #1080179 in pydantic 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/pydantic/-/commit/342a764319ab68872
Source: pydantic
Version: 2.4.2-2
Severity: serious
Justification: FTBFS on related packages
The update to pydantic 2 is a Transition, so needs extra care
pydantic 2 breaks the old versions of dirty-equals, python-djantic,
python-maison.
They have all been updated in unstable, but for migration
Control: tag -1 pending
Hello,
Bug #1078540 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/5f2e00e6c69dbcf6
Control: tag -1 pending
Hello,
Bug #1078540 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/5a4b7e28c5de1b59
Package: python3-setuptools
Version: 73.0.0-1
Severity: serious
Tags: patch fixed-upstream
Justification: FTBFS [scipy]
Control: forwarded -1 https://github.com/pypa/setuptools/issues/4579
python3-setuptools 73.0.0-1 causes scipy to FTBFS, see
https://buildd.debian.org/status/package.php?p=scipy
h
Control: tag -1 pending
Hello,
Bug #1078977 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/ce868a6fa9c5c0ee
Package: python3-scipy
Followup-For: Bug #1078977
In principle it probably should have been Multi-Arch: same
(not Multi-Arch: no) instead of Multi-Arch: foreign. The python
extensions do not cause a clash since they are explictly marked
multiarch
e.g.
/usr/lib/python3/dist-packages/scipy/_lib/_fpu
1 - 100 of 719 matches
Mail list logo
