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
e hacked to use the "required" specific version,
but I think that wouldn't help anyway to get paraview on the binNMU list
for python3 upgrades.
The ranged version will do it.
Drew
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
Package: wnpp
Severity: wishlist
Owner: Drew Parsons
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-scie...@lists.debian.org
* Package name: scifem
Version : 0.3.0
Upstream Contact: Henrik Finsberg
* URL : https://scientificcomputing.github.io/scifem
* License
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],
stop hindering other packages.
Thanks Bas, that's probably best. facet-analyser is a poor victim of
paraview upstream's VTK policy, not something we can really fix.
Drew
Package: python3-adios4dolfinx
Version: 0.9.0-2
Severity: normal
Control: forwarded -1 https://github.com/jorgensd/adios4dolfinx/issues/147
There is some flakiness in test_original_checkpoint.py
(test_read_write_P_*). It regularly times out.
Perhaps there's some race condition, occasionally it pa
Package: release.debian.org
Severity: normal
X-Debbugs-Cc: fenicsx-performance-te...@packages.debian.org
Control: affects -1 + src:fenicsx-performance-tests
User: release.debian@packages.debian.org
Usertags: binnmu
nmu fenicsx-performance-tests_0.9.0-2 . armel armhf i386 m68k sh4 . unstable .
Source: fenics-dolfinx
Followup-For: Bug #1090900
160s Warning! ***HDF5 library version mismatched error***
160s The HDF5 header files used to compile this application do not match
160s the version used by the HDF5 library to which this application is linked.
160s Data corruption or segmentation f
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
Package: ftp.debian.org
Severity: normal
Tags: ftbfs
X-Debbugs-Cc: parav...@packages.debian.org
Control: affects -1 + src:paraview
User: ftp.debian@packages.debian.org
Usertags: remove
The VTK componant of paraview no longer builds successfully on ppc64el
since paraview version 5.13.
In order
Source: slepc
Followup-For: Bug #972069
I don't think we'll be able to resolve this request.
64-bit arpack is now available in libarpack64-2-dev
But slepc's arpack configuration uses parpack when MPI support is active
64-bit support in ARPACK is explicitly excluded from PARPACK,
see
https://gi
Package: mirrormagic
Followup-For: Bug #1045230
Wait no, the problem is not the deleted orig files, it's the binary
executable left in the source dir. That we can fix easily.
Package: mirrormagic
Version: 3.3.0+dfsg1-1
Followup-For: Bug #1045230
These "orig" files are removed by dh_clean.
I guess they should never have been in the upstream tarball in the
first place.
There's a new upstream release waiting to be processed.
Let's see if this bug is fixed (orig files no
Acknowledging it as a known warning is a reasonable workaround.
Drew
Source: pythran
Followup-For: Bug #1083728
I'm confused by this bug.
pythran does not depend on or refer to pkg-resources anywhere.
On 2024-12-04 20:53, Emilio Pozuelo Monfort wrote:
On 04/12/2024 17:52, Drew Parsons wrote:
Looks like britney sorted it out eventually anyway.
If you mean the autopkgtest, that was Graham scheduling tests with
cmake/sid upon my request.
Ah, now the pixies behind the music in the garden
On 2024-12-04 17:42, Emilio Pozuelo Monfort wrote:
Hi Drew,
On 03/12/2024 16:25, Emilio Pozuelo Monfort wrote:
On 03/12/2024 14:33, Drew Parsons wrote:
All the hypre and petsc uploads for this transition are done,
and packages built against the new openmpi 5.
Looks like the sundials
All the hypre and petsc uploads for this transition are done,
and packages built against the new openmpi 5.
No problem, thanks Andreas.
I need time to focus and finish crafting gworldclock's new replacement.
Drew
figure it is better than the alternative of not having any docs at all.
Drew
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: debian-pyt...@lists.debian.org, debian-scie...@lists.debian.org
Control: block 1088105 by -1
* Package name: python-jupyterlite-sphinx
Version : 0.16.5
Upstream Contact: Martin Renou and JupyterLite Contributors
* URL : htt
_type=heads#L34
Is libprrte.so supposed to point at the directory like this, instead
of the versioned library?
Drew
Package: libopenmpi-dev
Version: 5.0.6-2
Followup-For: Bug #1088767
Control: severity 1088767 serious
I get this error too updating to openmpi 5.0.6-2.
Looks like some intermediate update got caught in the package updates.
libprrte.so is installed by libopenmpi40 5.0.6-2
as /usr/lib/x86_64-linux-
1 - 100 of 1188 matches
Mail list logo
