On Sun, 13 Apr 2025 at 13:14:49 +0300, Adrian Bunk wrote:
214s autopkgtest [01:51:54]: test mpi-compile-run-cc-pkgconf-mpi-c: [-----------------------
214s Package mpi-c was not found in the pkg-config search path.
...
This is related to two lines disappearing from the
libmpich-dev postinst:
--slave /usr/lib/i386-linux-gnu/pkgconfig/mpi-c.pc mpi-c.pc-i386-linux-gnu /usr/lib/i386-linux-gnu/pkgconfig/mpich.pc \
--slave /usr/lib/i386-linux-gnu/pkgconfig/mpi-fort.pc mpi-fort.pc-i386-linux-gnu /usr/lib/i386-linux-gnu/pkgconfig/mpich.pc
Re-adding the first line fixes mpi-compile-run-cc-pkgconf-mpi-c.
Fixing mpi-compile-run-f90-pkgconf-mpi* requires re-adding the second line, >plus reverting the following change:
/usr/lib/i386-linux-gnu/mpich/lib/pkgconfig/mpich.pc
-Libs: -Wl,-z,relro -Wl,-z,now -L${libdir} -lmpichfort -lmpich -lpthread -lhwloc
+Libs: -Wl,-z,relro -Wl,-z,now -L${libdir} -lmpich -Wl,-z,relro -Wl,-z,now -lpthread -lhwloc
On Wed, 16 Apr 2025 at 12:07:36 +0100, Alastair McKinstry wrote:
I'm reluctant to make these changes for mpich as it recently
(upstream) dropped mpi-fort.pc support.
I believe the absence of mpi-c.pc might also be what is causing valgrind
to FTBFS on 32-bit architectures, preventing an unrelated RC bug fix from migrating to testing (which I've reported as a separate bug, initially
against src:valgrind, but it might get reassigned to mpich).
Fixing the C regression by reinstating the first --slave line
seems considerably simpler, and might be enough to fix valgrind on
32-bit. Should we clone this bug into a C part which can certainly be
fixed, and a Fortran part which might need further discussion?
(If the package still contains a libmpichfort that can be linked against,
then it doesn't actually seem particularly hard to retain backward compatibility with mpi-fort.pc for trixie either, but perhaps there are subtleties that I'm not aware of.)
I'd prefer we drop these tests in mpi-default for mpich in trixie than
add code to support in Debian, especially at this late stage.
Has this change been coordinated with mpi-defaults, and consumers of the mpi-fort interface if any?
I understand your concern about the late stage of the release cycle, but
I also notice that mpich 4.3.x was first uploaded to unstable 2 days
before the toolchain freeze, which doesn't seem like an ideal time to be dropping functionality that previously existed and may have been relied on
by dependent packages.
smcv
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)