Re: 64-bit time_t transition in progressL
On 18/02/2024 17:52, Alastair McKinstry wrote: Hi Steve On 16/02/2024 08:11, Steve Langasek wrote: Hi Alastair, There are in fact three related MPI transitions, as mpich-4.2.0 is essentially a mini-transition ; openmpi 4 -> 5 drops 32-bit support, and has a Fortran API change too in close inspection: it moves MPI_Integer type from 4 to 8 bytes. Apologies , I need to correct this; default MPI_Integer does not change from 4 bytes on openmpi5. I have yet to upload an mpich transition bug to request transition. I'm not sure how to do this; the API has changed, but not the ABI? the SO interface hasn't changed, so how do I write the appropriate BEN code? Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Re: 64-bit time_t transition in progressL
Hi Steve On 16/02/2024 08:11, Steve Langasek wrote: Hi Alastair, On Sat, Feb 03, 2024 at 08:11:21AM +, Alastair McKinstry wrote: Since the time transition is going to require an openmpi transition, I suggest that the mpi-defaults transition happen simultaneously; ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 libs builds against 64-bit libs only. If I'm interpreting your message correctly, I believe these are relatively orthogonal: you can change mpi-defaults whenever you wish, the packages that depend on libopenmpi3 would still need binNMUing to make them depend on libopenmpi3t64 on armhf. If you arrange it so that at the same time mpi-defaults changes, so that any armhf packages build-depending on mpi-default-dev get rebuilt to depend on libmpich12 instead of either libopermpi3 or libopenmpi3t64, that's fine and would save a round of binNMUs of those same packages later; but that is not a transition that is going to require the same degree of tight coordination wrt unstable uploads and testing migration so I don't think we should block the t64 unstable uploads on an mpi-defaults change. (If you upload mpi-defaults to unstable *first* and get the binNMUs done before the t64 transition lands, that's great and just saves us on the number of binNMUs we will need to schedule.) There are in fact three related MPI transitions, as mpich-4.2.0 is essentially a mini-transition ; it appears mpich-4.1.2 -> 4.2.0 as a trivial change in Fortran API (renaming a parameter ierr->ierror) the scope of breakage is unknown at this time. openmpi 4 -> 5 drops 32-bit support, and has a Fortran API change too in close inspection: it moves MPI_Integer type from 4 to 8 bytes. To my understanding there are likely to be libmpich12 -> libmpich12t64 transitions but not libopenmpi3t64 , as there will be no 32-bit openmpi packages post openmpi transition. mpi-default can then be done before the t64 binNMUs as you point out , and there need not be libopenmpi3t64 changes. I have yet to upload an mpich transition bug to request transition. Note there is a 5.0.1-1 package in experimental for openmpi that is not ready for primetime; for the t64 transition use 4.1.6 not 5.0.1. Of course. binary NEW changes are being staged in experimental where possible, but we will not be pulling experimental versions into unstable as part of this. Regards Alastair -- Alastair McKinstry, GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5 ph: +353 87 6847928 e: alast...@mckinstry.ie, im: @alastair:mckinstry.ie
Re: 64-bit time_t transition in progressL
Hi Alastair, On Sat, Feb 03, 2024 at 08:11:21AM +, Alastair McKinstry wrote: > Since the time transition is going to require an openmpi transition, I > suggest that the mpi-defaults transition happen simultaneously; > ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 > libs builds against 64-bit libs only. If I'm interpreting your message correctly, I believe these are relatively orthogonal: you can change mpi-defaults whenever you wish, the packages that depend on libopenmpi3 would still need binNMUing to make them depend on libopenmpi3t64 on armhf. If you arrange it so that at the same time mpi-defaults changes, so that any armhf packages build-depending on mpi-default-dev get rebuilt to depend on libmpich12 instead of either libopermpi3 or libopenmpi3t64, that's fine and would save a round of binNMUs of those same packages later; but that is not a transition that is going to require the same degree of tight coordination wrt unstable uploads and testing migration so I don't think we should block the t64 unstable uploads on an mpi-defaults change. (If you upload mpi-defaults to unstable *first* and get the binNMUs done before the t64 transition lands, that's great and just saves us on the number of binNMUs we will need to schedule.) > Note there is a 5.0.1-1 package in experimental for openmpi that is not > ready for primetime; for the t64 transition use 4.1.6 not 5.0.1. Of course. binary NEW changes are being staged in experimental where possible, but we will not be pulling experimental versions into unstable as part of this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
