Bug#1102928: mpich: mpi-defaults autopkgtest regressions on 32-bit

[Alastair McKinstry]

On 23/04/2025 10:47, Simon McVittie wrote:
> 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?
>
Yes, lets go with this.
> (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?
>
No, unfortunately.
> 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.
>
I think that given circumstances 4.3.* is not ready for trixie.

I haven't had word from upstream but am not sure the drop in 
functionality is expected/permanent.

4.3.0-6 in experimental) fixes an important bug in mpich that should 
replace -5 in sid, but think its probably best to leave 4.2* for trixie

>     smcv
>
Alastair

-- 
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
e: alastair at mckinstry.ie, im: @alastair:mckinstry.ie @amckinstry at mastodon.ie

Commander Vimes didn’t like the phrase “The innocent have nothing to fear,”
  believing the innocent had everything to fear, mostly from the guilty but in the longer term
  even more from those who say things like “The innocent have nothing to fear.”
  - T. Pratchett, Snuff