OpenMPI / MPI transition
Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Re: OpenMPI / MPI transition
Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? For release architectures, the 32bit ones would be armel, armhf and i386. Cheers, Emilio
Re: OpenMPI / MPI transition
On 2023-11-23 12:13, Emilio Pozuelo Monfort wrote: Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. True, in one sense it's simpler to have the same default MPI. But we've set up our package infrastructure so that in principle it should not matter. One architecture does not (or should not) depend on another, so it shouldn't break packages just because we'd have different MPI implementations on different architectures. On the contrary, "actively" using both implementations could lead to more robust packages overall as MPI bugs get fixed against both implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? One point to consider is that upstream developers of several of our numerical libraries have time and again suggested to us that we use mpich instead of openmpi, even before this v5 shift. They perceive (rightly or wrongly) that mpich is more robust, more reliable. It would be useful to know whether that changes with v5, or whether their complaints are historical and openmpi has already fixed the bugs that concerned them. mpich has had its own share of bugs over the years. My memory told me RMA support was an issue in openmpi, but when I checked my facts, it was mpich that had to be fixed (https://github.com/pmodels/mpich/issues/6110) Drew
Re: OpenMPI / MPI transition
On 23/11/2023 12:44, Drew Parsons wrote: On 2023-11-23 12:13, Emilio Pozuelo Monfort wrote: Hi, On 23/11/2023 09:36, Alastair McKinstry wrote: Hi, OpenMPI has a new upstream release 5.0.0. It is in experimental now; the SOVERSION for libraries remains 40.X (minor version increment), there is an SOVERSION increment for private libraries only so in theory this is not an ABI transition. However 5.0.0 drops 32-bit system support. The default MPI implementation for each architecture is set in mpi-defaults; this allows a per-arch MPI choice; in practice we currently use OpenMPI for all archs. The other choice is MPICH. So the question becomes: do we switch MPI for just 32-bit archs, or all? What are the release teams opinion on this transition? Having the same implementation across the board makes things easier for testing purposes et al, however I don't see that as a blocker for not having separate implementations. True, in one sense it's simpler to have the same default MPI. But we've set up our package infrastructure so that in principle it should not matter. One architecture does not (or should not) depend on another, so it shouldn't break packages just because we'd have different MPI implementations on different architectures. On the contrary, "actively" using both implementations could lead to more robust packages overall as MPI bugs get fixed against both implementations. What are your thoughts on it? Is there a strong reason why we should stick with OpenMPI for 64bit releases? Or from a different POV, what are the risks of changing the implementation? Introducing a different set of bugs? One point to consider is that upstream developers of several of our numerical libraries have time and again suggested to us that we use mpich instead of openmpi, even before this v5 shift. They perceive (rightly or wrongly) that mpich is more robust, more reliable. It would be useful to know whether that changes with v5, or whether their complaints are historical and openmpi has already fixed the bugs that concerned them. mpich has had its own share of bugs over the years. My memory told me RMA support was an issue in openmpi, but when I checked my facts, it was mpich that had to be fixed (https://github.com/pmodels/mpich/issues/6110) Drew My understanding is that MPICH has been typically the reference implementation, higher quality but less performant, particularly with the range of fabrics. Certainly I've seen mostly OpenMPI but not MPICH on various HPC machines. People would use either OpenMPI or a vendors MPI (which may be forked MPICH with added network hardware support). I'd really like to hear from upstream users whether they are still encountering OpenMPI issues. Personally I favour splitting, using MPICH on 32-bit archs to flush out bugs, and doing so early in the dev cycle (now) so there is time to change if necessary. Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 e: mckins...@debian.org, im: @alastair:mckinstry.ie
Bug#1056605: ITP: licenserecon -- Reconcile licenses from debian/copyright against license-check
Package: wnpp Severity: wishlist Owner: Peter X-Debbugs-Cc: debian-devel@lists.debian.org, pe...@pblackman.plus.com * Package name : licenserecon Version : 1.0 Upstream Contact: Peter Blackman * URL : https://salsa.debian.org/PeterB/licenserecon * License : BSD-2-clause Programming Lang: Pascal Description : Reconcile debian/copyright licenses against licensecheck output Uses licensecheck to determine file licences and, if not 'UNKNOWN', checks them against Dep5 debian/copyright. Is intended as a partial replacement for license-reconcile (removed in 2019). I use this package for checking debian/copyright in other packages I maintain. Will need a sponsor. From the man page; === lrc DESCRIPTION Lrc parses a valid DEP-5 copyright file and notes the licenses of files in the source tree. Licensecheck is then run, and the results compared. Differences between licenses in debian/copyright and the output of licensecheck are reported. It should be run in the top level of a cleaned Debian source tree, with a valid DEP-5 copyright file. The source tree should be clean, otherwise results will be contaminated by spurious reports on the build's generated files. It is advisable to run lintian first to ensure correct syntax of debian/copyright. The results are indicative only, and not a substitute for manual checking. It is intended to report obvious errors. The design intends to minimise false positives as much as is practical. However, false positives will occur if the spelling of the license short-string is not identical between the file and debian/copyright. This is quite likely with complex licensing such as 'and'/'or' constructs and specific exceptions. Only files with a copyright header are checked. False negatives may occur if licensecheck cannot determine a file's license. Files named copyright, copying, readme etc. are not checked as they often specify the licenses of other files rather than their own. EXIT CODES 0: No differences found 1: Failure to run (no debian/copyright etc) 3: License differences found SAMPLE OUTPUT Sample output invoking lrc. SUCCESS: Parsing Source Tree Running licensecheck No differences found DIFFERENCES: Parsing Source Tree Running licensecheck d/copyright | licensecheck LGPL-2.1+ | GPL-2+ test/src/config/chan.c GPL-2+ | public-domain share/lua/int/dummy.lua GPL-2+ | LGPL-2.1+ modules/access/sr_common.h AUTHOR Peter Blackman SEE ALSO licensecheck (1) 2023-11-21 1 lrc(1) Manual page lrc(1) line 7/56 (END) (press h for help or q to quit)
[no subject]
Good day sir/madam I'm a long time debian user but would like that contribute technical documentation to the community in thanks for your tireless work on this magnificent ecosystem. Thanks Zebb
Bug#1056619: ITP: soplex -- sequential object-oriented simplex solver
Package: wnpp Severity: wishlist Owner: Timo Röhling X-Debbugs-Cc: debian-devel@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: soplex Version : 6.0.3 Upstream Author : Zuse Institute Berlin (ZIB) * URL : https://github.com/scipopt/soplex * License : Apache-2, LGPL-2.1+, BSD-3-clause Programming Lang: C, C++ Description : sequential object-oriented simplex solver This package is part of the SCIP Optimization Suite. SoPlex is an optimization package for solving linear programming problems (LPs) based on an advanced implementation of the primal and dual revised simplex algorithm. It provides special support for the exact solution of LPs with rational input data. The package will be team-maintained under the umbrella of the Debian Math Team at https://salsa.debian.org/math-team/soplex -BEGIN PGP SIGNATURE- iQGzBAEBCgAdFiEEJvtDgpxjkjCIVtam+C8H+466LVkFAmVfzOsACgkQ+C8H+466 LVnexAwAv47byYfXLrXInUiK/H2iFsLMynDDe6RB4eE/kQ0UJmJ769+ZEIU2PPF0 LyHp7SwlJykCrIgmfFI6RFkfpG0Nxk/V3ZmA6jtYr0qEif19062ykIEfkhueCvPY cr7jLBkYTRWpqOA4Ot9d4dc/ZDzmsWHkKmxD5TbRkppgevxnXsbvbOtPtWeGlOgc G4FKW3O+YyyXE14vc2hrwsQILO7zmTzDBnlZa4HYCCn+CNhhzfkIXACafM8nXERg J+MIpJ+e+VQQXwVhIbP1T4XNS20ARyWLBaKkyDRIsa1ieyK95ajZyL7W/v9yRspp vdoFfCWXVqeqr7rg1qFHYB7cbXY0D+W3zOHzEZgm2DHZc6+Ifc6LsLrvGwrmETKT L8iBRiOwA+UUu9ENPV20pn3jUYl/SR975wFjZzwezEbJcQ+KCFiYZmPAWQYEoyWC lI8b7rsw2NO/PBGInJH4vPxUefbhp1MGGIrDQBsUnvaSQHqABj9KZThB+wJzrC0L NfYRW/iB =h/nn -END PGP SIGNATURE-
