Bug#1082552: #1082552: transition: petsc and numerical library stack
On 28/11/2024 20:13, Alastair McKinstry wrote:
en filing bugs, doing NMUs and requesting removal for NBS binaries, and we're
at a point I think where we can get rid of openmpi on armel/armhf/i386.
However, the autopkgtest regressions are still an issue for openmpi migration
to testing, and that I think is blocked on the libopenmpi40 transition if I
understood things correctly.
Have you been able to test-rebuild the rdeps against the new libopenmpi40?
Where are we with that?
Cheers,
Emilio
AFAICT the libopenmpi40 transition unblocks most things and should work. Issues
that need addressing:
(1) #1087988 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087988> [/S/|
| ] [src:hdf5 <https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=hdf5>] hdf5:
incomplete openmpi removal on 32-bit architectures <https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1087988>
Needs an answer similar to adios/netcdf-parallel etc with d/control created from
d/control.in
(2) #1079106 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079106> [/S/|
+| ] [boost1.83 <https://bugs.debian.org/cgi-bin/pkgreport.cgi?
package=boost1.83>] boost1.83: Autopkgtests fail on armhf due to OpenMPI changes
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1079106>
(3) #1087853 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087853> [/S/|
| ] [src:boost1.83 <https://bugs.debian.org/cgi-bin/pkgreport.cgi?
src=boost1.83>] boost1.83: autopkgtest regression due to new CMake deprecation
warning <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087853>
boost 1.83 has lots of rdeps. (2) has a patch, (3) needs work.
Those are autopkgtest failures, but looks like they are already failing in
testing, so not a regression.
(4) gyoto/yorick: looks like this is a release manager call. gyoto fails on math
regressions with yorick, but my attempts to rebuild yorick hang.
Those are not key packages. Worst case we can remove them.
(5) mpi4py fails to build with py3.13 (due to cffi dependency). Builds ok with
'nocheck' allowing more of the stack to build.
Are you sure? It looks like it was already built with py3.13, see e.g. [1]
(6) elpa also needed a nocheck build (unrelated to openmpi40).
This is not a key package, so let's not block on it.
I think the openmpi40 transition should proceed to clear up the build issues.
mpi-defaults is essentially done, and openmpi-rm won't progress without the
rebuilds. The only issue with openmpi-5.06.-1 is #1087800, for which there is a
one-line patch to fix s390 which I'll apply in openmpi-5.0.6-2 if the RMs say ok.
Please apply that fix and upload to unstable. Hopefully we can finally sort this
out.
Cheers,
Emilio
[1]
https://buildd.debian.org/status/fetch.php?pkg=mpi4py&arch=i386&ver=4.0.1-6&stamp=1732055780&raw=0
Reply to: