Bug#853029: mpi-default-dev: update mpi defaults for m68k and sh4 to openmpi?

[Mattia Rizzolo]

Control: tag -1 +moreinfo

This bug report follows on from #833425
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833425
openmpi now builds on m68k and sh4.

Yes, also as I reported in that bug report.

For various reasons it could be convenient if the Debian default
mpi on these architectures could be updated from mpich to openmpi.
The specific reason that bothers me is that mpich does not provide
mpi-fort.pc, while openmpi does. This prevents mumps from building on
m68k and sh4 (with blacs-mpi also affected).

Such change really needs to be ACK by a porter, therefore I'm CCing the
68k and sh lists.

@Porters: Are you fine with changing the default MPI implementation in
sh4 and m68k from MPICH to OpenMPI?

[Mattia Rizzolo]

Post by Mattia Rizzolo
Such change really needs to be ACK by a porter, therefore I'm CCing the
68k and sh lists.

Thanks Mattia. J.P. Adrian Glaubitz also replied via the port lists,
and said he'll check to confirm the change won't break anything.

This never happened, but Adrian Bunk insisted on doing the move.
Here is an IRC log from #debian-ports over the course of the past days
(elipsing/removing unrelated lines; all times CEST; first number is the
day of the month):


[19 11:13:22 PM] <bunk> cbmuser, jrtc27: Two questions regarding m68k:
[19 11:13:46 PM] <bunk> 1. [
]
[19 11:15:47 PM] <bunk> 2. https://sources.debian.org/src/mpi-defaults/1.13/debian/rules/#L91-L93 - is this still appropriate, or should m68k and sh4 now default to openmpi like all other architectures?
[19 11:22:06 PM] <cbmuser> [
]
[19 11:22:17 PM] <cbmuser> I can test the other packages tomorrow and look into MPI
[19 11:22:40 PM] <cbmuser> [
]
[19 11:30:34 PM] <bunk> cbmuser: thanks (and no need to hurry on either of these)
[19 11:33:39 PM] <cbmuser> sure
[20 10:31:41 AM] <mapreri> as a reminder: switching the MPI implementation means rebuilding a bunch of things (I don't remember the details, but if you dig into the release.d.o transition bugs and the ben-data repository you should find the one I did for s390x a few years back)
[20 10:35:19 AM] <cbmuser> OK
[20 10:37:11 AM] <mapreri> (oh, past me had already documented it in d/README.source, good past me!)
[20 10:55:21 AM] <bunk> I was considering a private ben tracker and then binNMU through that if changed.
[20 10:56:50 AM] <bunk> Which should be worth the effort if it makes packages like octave build and permanently removes a difference from other ports.
[20 10:58:20 AM] <bunk> mapreri: Was there ever a reason other than "openmpi is not yet available for $architecture" for using mpich as a default?
[20 11:04:38 AM] <mapreri> bunk: there were considerations like "openmpi hasn't been tested here much", but back in 2016-2017 when I was messing with mpi-defaults my driving thought was to make everything the same indeed.
[20 11:04:52 AM] <mapreri> and openmpi wasn't available there at the time indeed.
[20 11:21:15 AM] <bunk> m68k and sh4 are building with nocheck, and mpi is not something I'd expect to be used much on that kind of hw...
[20 11:31:34 AM] <bunk> Multi-Arch: same considerations (if they matter) feel like the strongest point against doing the transition before the release
[31 07:47:49 AM] <bunk> Coming back to a topic already discussed a few days ago: To make it consistent with all other architectures, could mapreri or jrtc27 make a maintainer upload of mpi-defaults changing m68k and sh4 to openmpi into DELAYED/14 ? I can then take care of the binNMUs (ben tracker already setup). Would that be OK for everyone?
[31 08:46:23 AM] <cbmuser> bunk: do we know that openmpi works fine on m68k and sh4?
[31 08:59:46 AM] <bunk> Do we actually know that mpich works fine on these nocheck architectures? My goal is to resolve an architecture-specific difference from a time when openmpi was not available there that currently results in packages like octave and theie rdeps unbuildable there.
[31 09:02:31 AM] <cbmuser> well, so far mpich hasn't made any problems outside the issues you mentioned
[31 09:02:53 AM] <cbmuser> but I just want to avoid many packages starting to FTBFS
[31 09:03:03 AM] <cbmuser> so we should run some basic tests first
[31 09:03:46 AM] <bunk> scalapack builds both an mpich version and an openmpi version, and both build
[31 09:04:09 AM] <cbmuser> OK
[02 12:09:44 PM] <mapreri> bunk: I'm happy to do such upload if somebody opens a bug report requesting so (in a way so I can claim that "i didn't decide on it myself!")
[03 11:31:11 AM] <bunk> mapreri: #853029
[04 11:20:55 AM] <mapreri> bunk: I'll past all the relevant IRC messages in the bug log and upload then

[04 11:21:05 AM] <cbmuser> I am building gcc-11 on sh4 on a local qemu-user now to see whether this fixes the problem
[04 11:21:14 AM] <bunk> mapreri: thanks
[04 11:22:15 AM] <mapreri> paste*



So, overall, I guess I'll go ahead and JFDI.