Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Source: petsc Followup-For: Bug #1102465 Control: forwarded -1 https://gitlab.com/petsc/petsc/-/work_items/1881 For further reference and further discussion, and to understand upstream's reasons for the version checks, I raised the question upstream at https://gitlab.com/petsc/petsc/-/work_items/1881 -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
On 2026-03-19 12:49, Drew Parsons wrote: The question of ABI compatibility will get even more complex, or simpler depending on your perspective, in the future when the MPI implementations move to MPI standard 5, which will provide a common stable ABI that will enable swap-out between OpenMPI and MPI (and other implementations). I say "future", but actually that's what mpich v5 is already, it's supporting the new MPI-5 standard. The apparent compatibility that we're seeing between mpich v4 and v5 might be part of that move to a more stable interface, which is a new development. I should correct what I wrote here. The MPI-5 common ABI is a new development, enabling exchange of different MPI-5 implementations (i.e. swapping between openmpi and mpich, etc). But MPICH ABI stability with respect to mpich's own recent versions and derivatives has been in place for a decade or more, the MPICH ABI Compatibility Initiative, https://www.mpich.org/abi/ https://github.com/pmodels/mpich/blob/main/doc/wiki/testing/ABI_Compatibility_Initiative.md cf. https://www.anl.gov/mcs/article/new-initiative-on-runtime-compatibility-for-mpi-implementations This is why libmpich12 in principle hasn't needed ABI transitions. It's a separate question why PETSc nevertheless felt the need to be more restrictive about the mpich version. I haven't found much PETSc discussion upstream about the common ABIs, except there is brief reference in https://www.mpich.org/static/docs/slides/2024-cass-bof/zhang.pdf and a source comment at https://gitlab.com/petsc/petsc/-/blob/main/src/sys/objects/pinit.c#L799 about the MPICH ABI Compatibility Initiative before checking for older mpich (before ABI compatibility) at https://gitlab.com/petsc/petsc/-/blob/main/src/sys/objects/pinit.c#L829 -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
On 19/03/2026 11:49, Drew Parsons wrote: On 2026-03-19 11:47, Adrian Bunk wrote: On Thu, Mar 19, 2026 at 02:13:25AM +0100, Drew Parsons wrote: Source: petsc Followup-For: Bug #1102465 As pointed out already in this bug, this warning is not a bug in PETSc. It is working entirely as intended. No information was given with this bug reopening The bug is still present in 3.24.4+dfsg1-1 (see i386): https://tracker.debian.org/pkg/mpich ... ∙ ∙ Autopkgtest for petsc/3.24.4+dfsg1-1: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ... I presume it refers to the 32-bit build failures of reverse dependencies, which is happening due to the upgrade of mpich from v4 to >v5. Yes. petsc (and all other MPI packages) needs to be rebuilt against the new mpich (on 32-bit arches) (the mpich upgrade needs a transition bug). ... If this is true, then mpich v5 needs a new soname (or at least a package rename) to ensure that packages built against v4 won't use v5. One of the following claims is incorrect: - mpich claims v5 is compatible with v4 - petsc claims v4 and v5 are incompatible Thanks for the extra detail I think part of the situation comes from the historical development of the MPI implementations, and from PETSc trying to manage bug reports coming from different MPI libraries and their different versions. True, mpich is still provided by libmpich12, so it's not a question of transitioning libmpich4 to libmpich5 (I had forgotten that point). So there is some ABI compatibility. It is possible that PETSc is being over-sensitive due to problems that had been arising in the past but are no longer a great problem. There is (supposed to be) no transition; MPI standard v5 designates a standard ABI, but no change in the API. I will need to dig into PETSc to understand how it sees two versions. MPICH provides a new libmpi_abi.so that supplies the new ABI, so as to not break libmpich.so.12 I will need to see if this is specified in v5, or what OpenMPI is expected to do. The question of ABI compatibility will get even more complex, or simpler depending on your perspective, in the future when the MPI implementations move to MPI standard 5, which will provide a common stable ABI that will enable swap-out between OpenMPI and MPI (and other implementations). I say "future", but actually that's what mpich v5 is already, it's supporting the new MPI-5 standard. The apparent compatibility that we're seeing between mpich v4 and v5 might be part of that move to a more stable interface, which is a new development. Once the MPI-5 standard and its common ABI is fully implemented and operating (i.e. once users are routinely using openmpi v5 or mpich v5), I can expect PETSc upstream will be able reevaluate and relax their version tests (at the moment their attention is on ensuring past library versions continue to work, with, as an example of the types of bugs they have to deal with, nvidia's cuda fortran compiler still not supporting an 8-year-old fortran standard [1]). In the short term I think the simplest thing right now for petsc is to just rebuild for the new version 3.24.5, which will reset the 32-bit builds to mpich v5. Beyond that, perhaps both the openmpi and mpich packages will want to be reconfigured so they can equally and alternatively be installed as the preferred MPI on any system. The situation would then probably be similar to what we do with BLAS/LAPACK and the various alternative optimised BLAS implementations. Yes, work will be needed in both to make them intercompatible. Alastair Drew [1] true story. https://gitlab.com/petsc/petsc/-/work_items/1879 -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
On 2026-03-19 11:47, Adrian Bunk wrote: On Thu, Mar 19, 2026 at 02:13:25AM +0100, Drew Parsons wrote: Source: petsc Followup-For: Bug #1102465 As pointed out already in this bug, this warning is not a bug in PETSc. It is working entirely as intended. No information was given with this bug reopening. ... I forgot to unarchive the bug before sending the explanation, but you should have received the personal copy of it: Date: Wed, 18 Mar 2026 13:43:22 +0200 From: Adrian Bunk ... The bug is still present in 3.24.4+dfsg1-1 (see i386): https://tracker.debian.org/pkg/mpich ... ∙ ∙ Autopkgtest for petsc/3.24.4+dfsg1-1: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ... I presume it refers to the 32-bit build failures of reverse dependencies, which is happening due to the upgrade of mpich from v4 to >v5. Yes. petsc (and all other MPI packages) needs to be rebuilt against the new mpich (on 32-bit arches) (the mpich upgrade needs a transition bug). ... If this is true, then mpich v5 needs a new soname (or at least a package rename) to ensure that packages built against v4 won't use v5. One of the following claims is incorrect: - mpich claims v5 is compatible with v4 - petsc claims v4 and v5 are incompatible Thanks for the extra detail I think part of the situation comes from the historical development of the MPI implementations, and from PETSc trying to manage bug reports coming from different MPI libraries and their different versions. True, mpich is still provided by libmpich12, so it's not a question of transitioning libmpich4 to libmpich5 (I had forgotten that point). So there is some ABI compatibility. It is possible that PETSc is being over-sensitive due to problems that had been arising in the past but are no longer a great problem. The question of ABI compatibility will get even more complex, or simpler depending on your perspective, in the future when the MPI implementations move to MPI standard 5, which will provide a common stable ABI that will enable swap-out between OpenMPI and MPI (and other implementations). I say "future", but actually that's what mpich v5 is already, it's supporting the new MPI-5 standard. The apparent compatibility that we're seeing between mpich v4 and v5 might be part of that move to a more stable interface, which is a new development. Once the MPI-5 standard and its common ABI is fully implemented and operating (i.e. once users are routinely using openmpi v5 or mpich v5), I can expect PETSc upstream will be able reevaluate and relax their version tests (at the moment their attention is on ensuring past library versions continue to work, with, as an example of the types of bugs they have to deal with, nvidia's cuda fortran compiler still not supporting an 8-year-old fortran standard [1]). In the short term I think the simplest thing right now for petsc is to just rebuild for the new version 3.24.5, which will reset the 32-bit builds to mpich v5. Beyond that, perhaps both the openmpi and mpich packages will want to be reconfigured so they can equally and alternatively be installed as the preferred MPI on any system. The situation would then probably be similar to what we do with BLAS/LAPACK and the various alternative optimised BLAS implementations. Drew [1] true story. https://gitlab.com/petsc/petsc/-/work_items/1879 -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
On Thu, Mar 19, 2026 at 02:13:25AM +0100, Drew Parsons wrote: > Source: petsc > Followup-For: Bug #1102465 > > As pointed out already in this bug, this warning is not a bug in PETSc. > It is working entirely as intended. > > No information was given with this bug reopening. >... I forgot to unarchive the bug before sending the explanation, but you should have received the personal copy of it: Date: Wed, 18 Mar 2026 13:43:22 +0200 From: Adrian Bunk To: [email protected], Drew Parsons Subject: Re: Bug#1102465 closed by Debian FTP Masters (reply to Drew Parsons ) (Bug#1102465: fixed in petsc 3.22.5+dfsg1-2) Message-ID: The bug is still present in 3.24.4+dfsg1-1 (see i386): https://tracker.debian.org/pkg/mpich Issues preventing migration: ∙ ∙ Autopkgtest for dolfin/2019.2.0~legacy20240219.1c52e83-27: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Failed (not a +regression) ♻ (reference ♻), s390x: Pass ∙ ∙ Autopkgtest for fenics-dolfinx/1:0.10.0.post5-7: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Test triggered (failure will be +ignored), s390x: Pass ∙ ∙ Autopkgtest for fenicsx-performance-tests/0.10.0-2: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for liggghts/3.8.0+repack1-14: amd64: Pass, arm64: Failed (not a regression) ♻ (reference ♻), i386: Pass, ppc64el: Failed (not a regression) +♻ (reference ♻), s390x: Regression ♻ (reference ♻) ∙ ∙ Autopkgtest for mpi4py/4.1.1-1: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for mpich/5.0.0-3: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for nwchem/7.3.1-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Test triggered (failure will be ignored), s390x: Pass ∙ ∙ Autopkgtest for petsc/3.24.4+dfsg1-1: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for python-parsl/2026.02.23+ds-1: amd64: Pass, arm64: Pass, i386: Pass, ppc64el: Pass, s390x: Reference test triggered, but real test failed +already ♻ ∙ ∙ Autopkgtest for slepc/3.24.2+dfsg1-1: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for sundials/7.1.1+dfsg1-10: amd64: Pass, arm64: Pass, i386: Regression ♻ (reference ♻), ppc64el: Pass, s390x: Pass ∙ ∙ Autopkgtest for vtk9/9.5.2+dfsg4-1: amd64: Failed (not a regression) ♻ (reference ♻), arm64: Failed (not a regression) ♻ (reference ♻), i386: Pass, +ppc64el: Regression ♻ (reference ♻), s390x: Regression ♻ (reference ♻) Please remove the bogus version check from include/petscsys.h. > I presume it refers to the 32-bit build failures of reverse > dependencies, which is happening due to the upgrade of mpich from v4 to >v5. Yes. > petsc (and all other MPI packages) needs to be rebuilt against > the new mpich (on 32-bit arches) > (the mpich upgrade needs a transition bug). >... If this is true, then mpich v5 needs a new soname (or at least a package rename) to ensure that packages built against v4 won't use v5. One of the following claims is incorrect: - mpich claims v5 is compatible with v4 - petsc claims v4 and v5 are incompatible > Drew cu Adrian -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Source: petsc Followup-For: Bug #1102465 In any case, there is a new upstream release waiting for package. The build for the new version will update the package for mpich v5. -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Source: petsc Followup-For: Bug #1102465 As pointed out already in this bug, this warning is not a bug in PETSc. It is working entirely as intended. No information was given with this bug reopening. I presume it refers to the 32-bit build failures of reverse dependencies, which is happening due to the upgrade of mpich from v4 to v5. petsc (and all other MPI packages) needs to be rebuilt against the new mpich (on 32-bit arches) (the mpich upgrade needs a transition bug). I will close this bug again if no justification for reopening is given. Drew -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Hi Drew, On Fri, 11 Apr 2025 12:23:45 +0200 Drew Parsons wrote: Two alternative actions could be taken. 1) We could remove upstream's mpich version check, as you suggested. I'm reluctant to take this step, however. Upstream is careful with their code, I imagine they put the version check there for a reason. But in Debian as you explain below, it doesn't really serve a purpose as we're a distribution that ships things together. But ... 2) We could add an mpich versioned depends to the petsc packages, so when a new petsc build is tested in testing, it pulls any new mpich version with it. But this would not actually achieve anything. It does. It shows to all people inspecting the situation exactly what's going on. It would ensure that the migration software triggers the right combinations. The other way around, it might also prevent mpich from migrating too early in the future (with an upper bound, I haven't checked if that's the case here). It would also prevent people from doing partial upgrades (yes, not officially supported yet but we're getting better at it since autopkgtest catch so many of those and a lot of maintainers add versioned Depends). It would prevent running those tests (several are quite long running) over and over again (we retry after a day) because a passing test is remembered for a long time. So this option would significantly complicate build scripts (significantly, because only the 32-bit arches use mpich, so complex logic would need to be added to debian/rules to differentiate the different mpi-default conditions), This is a valid argument too, I don't deny that at all. (Although, you don't have to make it complex and could add things manually (now). I agree that's probably a PITA.) and would provide no functional gain. But this I disagree with. Why would we even have invented versioned Depends in the first place if people agreed this were true? I'm not saying the petsc package should have this logic, I leave that up to you, but I do think there's more value in it than you seem to see. So, coming back to point 1, I think that version testing in Debian usually is wrong. The best case is when upstream gets it right. The great thing is we have versioned Depends to express that at install time. Worse case upstream is wrong, usually too tight. We see that *a lot* and the version checks make it harder for packages to migrate as they need packages to be upgraded in lock step. Regularly because the migration doesn't see *why* the tests fail, it doesn't know there's a solution by testing together and migrating together if not expressed in relations. And then even upstream may have overseen a problem that we only catch while testing in Debian. Again, a versioned dependency can express what we find during unstable-to-testing integration. Paul OpenPGP_signature.asc Description: OpenPGP digital signature -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
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 latest mpich (on 32-bit arches). But the latest mpich has not yet migrated to testing. petsc will pass fine once mpich migrates (petsc is not blocking mpich). Two alternative actions could be taken. 1) We could remove upstream's mpich version check, as you suggested. I'm reluctant to take this step, however. Upstream is careful with their code, I imagine they put the version check there for a reason. 2) We could add an mpich versioned depends to the petsc packages, so when a new petsc build is tested in testing, it pulls any new mpich version with it. But this would not actually achieve anything. It would give a clean migration test, but end up "ready to migrate, waiting for mpich". Which is the state it's currently in, anyway. So this option would significantly complicate build scripts (significantly, because only the 32-bit arches use mpich, so complex logic would need to be added to debian/rules to differentiate the different mpi-default conditions), and would provide no functional gain. So I think for this bug it's just patience that is required, and perhaps assistance with mpich issues (Bug#1102612 is weird). -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: Re: Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Processing control commands: > block -1 by 1101686 Bug #1102465 [src:petsc] petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version 1102465 was blocked by: 1101686 1102465 was not blocking any bugs. Ignoring request to alter blocking bugs of bug #1102465 to the same blocks previously set -- 1102465: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102465 Debian Bug Tracking System Contact [email protected] with problems -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Processed: Re: Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Processing control commands: > block -1 by 1101686 Bug #1102465 [src:petsc] petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version 1102465 was not blocked by any bugs. 1102465 was not blocking any bugs. Added blocking bug(s) of 1102465: 1101686 -- 1102465: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102465 Debian Bug Tracking System Contact [email protected] with problems -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
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 new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Test in progress (will not be considered a regression), s390x: Pass ... Assuming the dependencies generated by the MPICH and Open MPI packages are correct, PETSc should drop these #errors. That's the point. The mpich package is not in good order. Bug#1101686. -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
Bug#1102465: petsc: PETSc was configured with one MPICH/Open MPI mpi.h version but now appears to be compiling using an older version
Source: petsc Version: 3.22.3+dfsg1-1 Severity: serious X-Debbugs-Cc: Drew Parsons https://tracker.debian.org/pkg/petsc 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 new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Test in progress (will not be considered a regression), s390x: Pass ∙ ∙ autopkgtest for fenics-dolfinx/1:0.9.0-6: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Test in progress (will not be considered a regression), riscv64: Test in progress (will not be considered a regression), s390x: Pass ∙ ∙ autopkgtest for fenicsx-performance-tests/0.9.0-2: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass ∙ ∙ autopkgtest for petsc/3.22.5+dfsg1-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass ∙ ∙ autopkgtest for slepc/3.22.2+dfsg1-1: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass ∙ ∙ autopkgtest for sundials/7.1.1+dfsg1-8: amd64: Pass, arm64: Pass, armel: Regression or new test ♻ (reference ♻), armhf: Regression or new test ♻ (reference ♻), i386: Regression or new test ♻ (reference ♻), ppc64el: Pass, riscv64: Pass, s390x: Pass This is due to: https://sources.debian.org/src/petsc/3.22.5%2Bdfsg1-1/include/petscsys.h/#L96 https://sources.debian.org/src/petsc/3.22.5%2Bdfsg1-1/include/petscsys.h/#L104 Assuming the dependencies generated by the MPICH and Open MPI packages are correct, PETSc should drop these #errors. -- debian-science-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-science-maintainers
