info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: 64-bit time_t transition in progress
36 views
Skip to first unread message
Steve Langasek
Feb 2, 2024, 11:50:05 AMFeb 2
to
Hello,
debian-devel-announce wouldn't let me attach the file, but for those on
debian-devel at least, you can find the dd-list of to-be-NMUed source
packages attached.
Thanks,
--
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/
slan...@ubuntu.com vor...@debian.org
On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> Dear developers,
>
> A number of you will have noticed already that the 64-bit time_t transition
> is now in progress in Debian experimental.
>
> The goal of this transition is to ensure that 32-bit architectures in trixie
> (whether they are currently release architectures, or out of archive, etc)
> will be capable of handling current and future timestamps referring to times
> beyond 2038.
>
> The release goal is described here:
>
> https://wiki.debian.org/ReleaseGoals/64bit-time
>
> The implementation of this plan, as discussed on debian-devel[1], involves
> mass-NMUs of > 1200 library packages to rename them for (presumed)
> ABI-breaking changes. These (0-day) NMUs started on Monday, and about 500
> libraries have been uploaded to experimental so far. The goal is to get all
> source packages that can be SRUed to experimental uploaded by this weekend.
>
> By my reckoning, this is the largest cross-archive ABI transition we've ever
> had in Debian.[2] Exciting times!
>
> NMU bugs with patches are filed with User: debia...@lists.debian.org and
> Usertag: time-t. You can see these bugs at [3].
>
> A dd-list of maintainers whose packages would be NMUed has previously been
> posted to debian-devel in several iterations. The archive is a moving
> target and there have been various challenges in getting coherent reporting
> across everything, so regenerating an up to date list today includes some
> packages that were not previously included in the dd-list output that had
> been posted. The packages previously not reported are:
>
> flint
> flint-arb
> gcc-14
> libsysstat
> mrmpi
> qt6-virtualkeyboard
> qt-qml-models
> tuiwidgets
>
> None of the late-added packages have yet been included in the NMUs that have
> been uploaded, but they should all be addressed shortly.
>
> And if you have not previously checked whether any of your packages are
> affected, please see the current list at [4].
>
>
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
>
> - dpkg uploaded to unstable with abi=time64 enabled by default[5]
> - immediately start cranking these same NMUs to unstable, including those
> for any packages which could not be uploaded to experimental first due to
> conflicting experimental package versions there
> - once these are built, trigger binNMUs for all of the reverse
> dependencies.
>
> As mentioned previously on debian-devel[6], we know that there are a number
> of library packages being included in this transition which we have not
> proven have an ABI affected by 64-bit time_t. This is because the
> engineering cost of analyzing the long tail of packages whose headers
> out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> than the cost of just changing the package name and moving forward with
> rebuilds. Packages in [7],[8] are those that are included in the mass-NMU
> for this reason. However, any maintainer receiving an NMU of their package
> to experimental which they believe is unnecessary, is still more than
> welcome to provide a fix that allows us to completely analyze their headers
> to prove that the library's ABI is not affected. Logs from most recent
> failures to analyze can be found under [9], and MPs can be raised to fix
> [10].
>
> (It is not sufficient to assert that time_t does not appear in a grep of the
> library's headers. There are many derivative types in glibc that inherit
> from time_t, and we will not accept proof by assertion that it is safe to
> not include a library in this transition. It is safer by far to be
> overbroad in including libraries in the transition, than to omit a library
> and leave users to trip over ABI breakage after a rebuild in the arbitrary
> future, possibly not even discovered until after trixie's release.)
>
> For interest, a list of these "unconfirmed" header packages, sorted by
> number of reverse-dependencies, can be found at [11].
>
> If your library does not appear in one of those lists, and you don't know
> why it has been included in the transition, you can see the
> per-header-package a-c-c compatibility reports at [12].
>
> Thanks,
> --
> 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/
> slan...@ubuntu.com vor...@debian.org
>
> [1] https://lists.debian.org/debian-devel/2024/01/msg00063.html
> [2] of course, just as with new movies continually breaking box-office
> records, there's an element of inflation here as the Debian archive is
> also now much larger than the last time we had to do such a transition
> :)
> [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debia...@lists.debian.org;tag=time-t
> [4] https://people.canonical.com/~vorlon/armhf-time_t/maintainer-list
> [5] https://bugs.debian.org/1037136
> [6] https://lists.debian.org/debian-devel/2023/07/msg00232.html
> [7] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_failed.txt
> [8] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_uninstallable.txt
> [9] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/
> [10] https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads
> [11] https://people.canonical.com/~vorlon/armhf-time_t/sorted-revdep-count
> [12] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/
debian-devel-announce wouldn't let me attach the file, but for those on
debian-devel at least, you can find the dd-list of to-be-NMUed source
packages attached.
Thanks,
--
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/
slan...@ubuntu.com vor...@debian.org
On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> Dear developers,
>
> A number of you will have noticed already that the 64-bit time_t transition
> is now in progress in Debian experimental.
>
> The goal of this transition is to ensure that 32-bit architectures in trixie
> (whether they are currently release architectures, or out of archive, etc)
> will be capable of handling current and future timestamps referring to times
> beyond 2038.
>
> The release goal is described here:
>
> https://wiki.debian.org/ReleaseGoals/64bit-time
>
> The implementation of this plan, as discussed on debian-devel[1], involves
> mass-NMUs of > 1200 library packages to rename them for (presumed)
> ABI-breaking changes. These (0-day) NMUs started on Monday, and about 500
> libraries have been uploaded to experimental so far. The goal is to get all
> source packages that can be SRUed to experimental uploaded by this weekend.
>
> By my reckoning, this is the largest cross-archive ABI transition we've ever
> had in Debian.[2] Exciting times!
>
> NMU bugs with patches are filed with User: debia...@lists.debian.org and
> Usertag: time-t. You can see these bugs at [3].
>
> A dd-list of maintainers whose packages would be NMUed has previously been
> posted to debian-devel in several iterations. The archive is a moving
> target and there have been various challenges in getting coherent reporting
> across everything, so regenerating an up to date list today includes some
> packages that were not previously included in the dd-list output that had
> been posted. The packages previously not reported are:
>
> flint
> flint-arb
> gcc-14
> libsysstat
> mrmpi
> qt6-virtualkeyboard
> qt-qml-models
> tuiwidgets
>
> None of the late-added packages have yet been included in the NMUs that have
> been uploaded, but they should all be addressed shortly.
>
> And if you have not previously checked whether any of your packages are
> affected, please see the current list at [4].
>
>
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
>
> - dpkg uploaded to unstable with abi=time64 enabled by default[5]
> - immediately start cranking these same NMUs to unstable, including those
> for any packages which could not be uploaded to experimental first due to
> conflicting experimental package versions there
> - once these are built, trigger binNMUs for all of the reverse
> dependencies.
>
> As mentioned previously on debian-devel[6], we know that there are a number
> of library packages being included in this transition which we have not
> proven have an ABI affected by 64-bit time_t. This is because the
> engineering cost of analyzing the long tail of packages whose headers
> out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> than the cost of just changing the package name and moving forward with
> rebuilds. Packages in [7],[8] are those that are included in the mass-NMU
> for this reason. However, any maintainer receiving an NMU of their package
> to experimental which they believe is unnecessary, is still more than
> welcome to provide a fix that allows us to completely analyze their headers
> to prove that the library's ABI is not affected. Logs from most recent
> failures to analyze can be found under [9], and MPs can be raised to fix
> [10].
>
> (It is not sufficient to assert that time_t does not appear in a grep of the
> library's headers. There are many derivative types in glibc that inherit
> from time_t, and we will not accept proof by assertion that it is safe to
> not include a library in this transition. It is safer by far to be
> overbroad in including libraries in the transition, than to omit a library
> and leave users to trip over ABI breakage after a rebuild in the arbitrary
> future, possibly not even discovered until after trixie's release.)
>
> For interest, a list of these "unconfirmed" header packages, sorted by
> number of reverse-dependencies, can be found at [11].
>
> If your library does not appear in one of those lists, and you don't know
> why it has been included in the transition, you can see the
> per-header-package a-c-c compatibility reports at [12].
>
> Thanks,
> --
> 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/
> slan...@ubuntu.com vor...@debian.org
>
> [1] https://lists.debian.org/debian-devel/2024/01/msg00063.html
> [2] of course, just as with new movies continually breaking box-office
> records, there's an element of inflation here as the Debian archive is
> also now much larger than the last time we had to do such a transition
> :)
> [3] https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debia...@lists.debian.org;tag=time-t
> [4] https://people.canonical.com/~vorlon/armhf-time_t/maintainer-list
> [5] https://bugs.debian.org/1037136
> [6] https://lists.debian.org/debian-devel/2023/07/msg00232.html
> [7] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_failed.txt
> [8] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/summary/results_uninstallable.txt
> [9] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/
> [10] https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/check-armhf-time_t?ref_type=heads
> [11] https://people.canonical.com/~vorlon/armhf-time_t/sorted-revdep-count
> [12] https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/
Scott Kitterman
Feb 2, 2024, 12:30:04 PMFeb 2
to
On February 2, 2024 4:43:52 PM UTC, Steve Langasek <vor...@debian.org> wrote:
>Hello,
>
>debian-devel-announce wouldn't let me attach the file, but for those on
>debian-devel at least, you can find the dd-list of to-be-NMUed source
>packages attached.
Thanks,
Scott K
Steve Langasek
Feb 2, 2024, 12:50:04 PMFeb 2
to
the patch against unstable applies cleanly to the version in experimental
(no fuzz), we upload to experimental.
Otherwise, patches are sent to the BTS but we skip uploading to experimental
and will NMU directly to unstable at the next stage (handling binary NEW
there).
Abridged citation from the code used, which probably explains as clearly as
anything:
apt-get source --only-source "$src"/unstable
cd "$src"-*
oldsrcver=$(dpkg-parsechangelog -S Version)
"$toolsdir"/time-t-me
dch -n 'Rename libraries for 64-bit time_t transition.'
dch -r -D experimental ''
sudo env APT_CONFIG=$APT_CONFIG mk-build-deps -i -r
dpkg-buildpackage -S -uc -us
srcver=$(dpkg-parsechangelog -S Version)
# make sure the package from unstable builds with the patch
# before we send it to the BTS
DEB_BUILD_OPTIONS="$DEB_BUILD_OPTIONS nocheck" \
dpkg-buildpackage -uc -us
cd ..
debdiff "$src"_${oldsrcver#*:}.dsc "$src"_${srcver#*:}.dsc \
> nmu_"$src".debdiff || true
# maybe there's a new version, or maybe we fall back to
# unstable
apt-get source --only-source "$src"/experimental \
|| apt-get source --only-source "$src"/unstable
cd "$src"-*
# we filter out debian/changelog and regenerate it with
# matching content, because if there is a new version then
# that part of the diff will fail to apply; but if everything
# else applies we should just upload to experimental anyway
# with an appropriate bumped version.
if ! filterdiff -x '*/debian/changelog' ../nmu_"$src".debdiff \
| patch -p1 -f -F0
then
cd ..
echo "$src: failed" >> upload-nmus.log
rm -f nmu_"$src".debdiff
rm -rf "$src"[_-]*
continue
fi
Steve Langasek
Feb 2, 2024, 1:20:05 PMFeb 2
to
Sorry, I mean to add: in the specific case of clamav, the source in
experimental has a new soname. So the patch will definitely not apply; and
we will want to NMU clamav to unstable, with a rename of whatever runtime
library package is there at the time the NMUs happen; so the version of
clamav in experimental can ignore this transition and just use the new
soname once it finally lands (is superseded by the next LTS version?)
experimental has a new soname. So the patch will definitely not apply; and
we will want to NMU clamav to unstable, with a rename of whatever runtime
library package is there at the time the NMUs happen; so the version of
clamav in experimental can ignore this transition and just use the new
soname once it finally lands (is superseded by the next LTS version?)
Bill Allombert
Feb 2, 2024, 1:50:04 PMFeb 2
to
On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> Dear developers,
>
> Dear developers,
>
> As mentioned previously on debian-devel[6], we know that there are a number
> of library packages being included in this transition which we have not
> proven have an ABI affected by 64-bit time_t. This is because the
> engineering cost of analyzing the long tail of packages whose headers
> out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> than the cost of just changing the package name and moving forward with
> rebuilds.
Why not use reproducible build on a 32bit platform and see whether the new
> of library packages being included in this transition which we have not
> proven have an ABI affected by 64-bit time_t. This is because the
> engineering cost of analyzing the long tail of packages whose headers
> out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> than the cost of just changing the package name and moving forward with
> rebuilds.
library is different from the old one ?
Do the libxxxt64 in experimental supposed to use the new ABI ? Because it does not
seem to be always the case. Is there a lintian test for that ?
Relying on dpkg-buildflags alone cannot be sufficient.
Cheers,
--
Bill. <ball...@debian.org>
Imagine a large red swirl here.
Steve Langasek
Feb 2, 2024, 2:00:04 PMFeb 2
to
On Fri, Feb 02, 2024 at 07:34:46PM +0100, Bill Allombert wrote:
> On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> > Dear developers,
> > As mentioned previously on debian-devel[6], we know that there are a number
> > of library packages being included in this transition which we have not
> > proven have an ABI affected by 64-bit time_t. This is because the
> > engineering cost of analyzing the long tail of packages whose headers
> > out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> > than the cost of just changing the package name and moving forward with
> > rebuilds.
> Why not use reproducible build on a 32bit platform and see whether the new
> library is different from the old one ?
Well, if this suggestion had come 6 months ago when this plan was laid out
> On Fri, Feb 02, 2024 at 08:21:57AM -0800, Steve Langasek wrote:
> > Dear developers,
> > As mentioned previously on debian-devel[6], we know that there are a number
> > of library packages being included in this transition which we have not
> > proven have an ABI affected by 64-bit time_t. This is because the
> > engineering cost of analyzing the long tail of packages whose headers
> > out-of-the-box fail ABI analysis under abi-compliance-checker is much higher
> > than the cost of just changing the package name and moving forward with
> > rebuilds.
> Why not use reproducible build on a 32bit platform and see whether the new
> library is different from the old one ?
on debian-devel, I think it would have been worth exploring.
Though I would have still expected a large number of false-positives,
because there would be differences for any library using time_t-derived
types internally, *or* any filesystem access affected by LFS.
> Do the libxxxt64 in experimental supposed to use the new ABI ? Because it
> does not seem to be always the case. Is there a lintian test for that ?
realized that wasn't actually relevant so we revised the plan on the fly and
skipped dpkg in experimental.
> Relying on dpkg-buildflags alone cannot be sufficient.
Bill Allombert
Feb 2, 2024, 2:30:05 PMFeb 2
to
On Fri, Feb 02, 2024 at 10:58:51AM -0800, Steve Langasek wrote:
> Well, if this suggestion had come 6 months ago when this plan was laid out
> on debian-devel, I think it would have been worth exploring.
>
> Though I would have still expected a large number of false-positives,
> because there would be differences for any library using time_t-derived
> types internally, *or* any filesystem access affected by LFS.
The idea was to compare the shared library binaries not the packages.
> Well, if this suggestion had come 6 months ago when this plan was laid out
> on debian-devel, I think it would have been worth exploring.
>
> Though I would have still expected a large number of false-positives,
> because there would be differences for any library using time_t-derived
> types internally, *or* any filesystem access affected by LFS.
> > Do the libxxxt64 in experimental supposed to use the new ABI ? Because it
> > does not seem to be always the case. Is there a lintian test for that ?
>
> No. Earlier this had been the plan, but after discussing with Guillem we
> realized that wasn't actually relevant so we revised the plan on the fly and
> skipped dpkg in experimental.
ones in unstable ?
> > Relying on dpkg-buildflags alone cannot be sufficient.
>
> I don't see any practical reason why not.
Alastair McKinstry
Feb 3, 2024, 3:40:03 AMFeb 3
to
Hi,
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.
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.
Thanks
Alastair
On 02/02/2024 16:43, Steve Langasek wrote:
> Hello,
>
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
>
> Thanks,
--
Alastair McKinstry,
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alas...@mckinstry.ie, im: @alastair:mckinstry.ie
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.
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.
Thanks
Alastair
On 02/02/2024 16:43, Steve Langasek wrote:
> Hello,
>
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
>
> Thanks,
--
GPG: 82383CE9165B347C787081A2CBE6BB4E5D9AD3A5
ph: +353 87 6847928 e: alas...@mckinstry.ie, im: @alastair:mckinstry.ie
julien...@gmail.com
Feb 3, 2024, 4:20:04 AMFeb 3
to
Hi,
Le vendredi 02 février 2024 à 08:21 -0800, Steve Langasek a écrit :
> The packages previously not reported are:
>
> flint
> flint-arb
About flint-arb: its code has been merged into flint, so it's abandoned
upstream. The package is in FTBFS... only the sagemath package prevents
its removal. Don't get blocked by this mess, you already have enough on
your plate.
Cheers,
J.Puydt
Fabio Fantoni
Feb 3, 2024, 6:20:04 AMFeb 3
to
Il 02/02/2024 17:43, Steve Langasek ha scritto:
> Hello,
>
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
>
> Thanks,
Sorry to bother you (or anyone else who wants to answer) with a question
> Hello,
>
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
>
> Thanks,
that might be stupid, maybe I didn't understand something.
From what I understand, for most of the packages involved a rebuild is
enough but this rebuild must be done after that of all their
dependencies (dependencies of dependencies etc...) involved to avoid
unexpected events that could cause crashes on some architectures (in
cases ABI changes occurred in the underlying dependencies but the
rebuild was done before one of those).
Having a package that depends on many and that part of those are
themselves involved in various other chains, how do NMU (when needed) to
unstable and rebuilds of other packages happen?
A single NMU on unstable or rebuild (for each package involved) but with
such an order so that when it is done all dependencies are already
rebuild, or with multiple rebuilds between the various migration chains
involved?
Thanks for any reply and sorry for my bad english.
Sebastian Andrzej Siewior
Feb 3, 2024, 9:00:03 AMFeb 3
to
On 2024-02-02 10:12:18 [-0800], Steve Langasek wrote:
> Sorry, I mean to add: in the specific case of clamav, the source in
> experimental has a new soname. So the patch will definitely not apply; and
> we will want to NMU clamav to unstable, with a rename of whatever runtime
> library package is there at the time the NMUs happen; so the version of
> clamav in experimental can ignore this transition and just use the new
> soname once it finally lands (is superseded by the next LTS version?)
I just updated the upload in experimental including the t64 changes. I
> Sorry, I mean to add: in the specific case of clamav, the source in
> experimental has a new soname. So the patch will definitely not apply; and
> we will want to NMU clamav to unstable, with a rename of whatever runtime
> library package is there at the time the NMUs happen; so the version of
> clamav in experimental can ignore this transition and just use the new
> soname once it finally lands (is superseded by the next LTS version?)
suggest to do the transition clamav at the same time.
Sebastian
Sebastian Andrzej Siewior
Feb 3, 2024, 9:10:04 AMFeb 3
to
On 2024-02-02 08:43:52 [-0800], Steve Langasek wrote:
> Hello,
Hi,
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
OpenSSL is on the list. I did not see a NMU bug report. Was the bug
missed or can it be removed the list of packages that require a NMU?
> Thanks,
Sebastian
> Hello,
Hi,
> debian-devel-announce wouldn't let me attach the file, but for those on
> debian-devel at least, you can find the dd-list of to-be-NMUed source
> packages attached.
missed or can it be removed the list of packages that require a NMU?
> Thanks,
Sebastian
julien...@gmail.com
Feb 3, 2024, 9:30:04 AMFeb 3
to
Le samedi 03 février 2024 à 10:16 +0100, julien...@gmail.com a
écrit :
a new upload go in your way or on the contrary help you ? [I'll refrain
any move until you confirm I won't break your effort.]
Cheers,
J.Puydt
écrit :
>
> About flint: if you need anything done, don't hesitate to ask me.
>
In fact multi-arch is broken for flint and I can probably fix it: would
> About flint: if you need anything done, don't hesitate to ask me.
>
a new upload go in your way or on the contrary help you ? [I'll refrain
any move until you confirm I won't break your effort.]
Cheers,
J.Puydt
Andreas Metzler
Feb 3, 2024, 10:40:04 AMFeb 3
to
"These (0-day) NMUs started on Monday, and about 500 libraries have been
uploaded to experimental so far. The goal is to get all source packages
that can be SRUed to experimental uploaded by this weekend."
The fact that no "We are done" message followed suggests that Steve and
uploaded to experimental so far. The goal is to get all source packages
that can be SRUed to experimental uploaded by this weekend."
his colleagues are still working on it and will get to OpenSSL in due
time.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Steve Langasek
Feb 3, 2024, 2:00:04 PMFeb 3
to
version in December successfully analyzed and showed no ABI breakage, but
flint 3.01-2 which is now current can't be analyzed due to compilation
errors.
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09%3A53%3A00/logs/libflint-dev/base/log.txt
So *maybe* a quirk could be added for a-c-c to let the headers be analyzed
and show that no change is needed. Or maybe the analysis would show that
the new version has introduced new entry points that do depend on time_t
size. I can't tell from here.
I'm not bothered either way, but by default we're going to wind up picking
this up in the mass NMUs and libflint18 will change to libflint18t64, which
will have no effect either way on users upgrading from stable releases since
this is a new soname since bookworm.
Steve Langasek
Feb 3, 2024, 3:20:06 PMFeb 3
to
usrmerge analysis. Once that is all done and dpkg is uploaded to unstable,
we will rebase all patches on whatever version of the library is in unstable
at that time. You don't need to hold off on an upload to unstable for fear
of conflicts.
Steve Langasek
Feb 3, 2024, 4:20:05 PMFeb 3
to
On Sat, Feb 03, 2024 at 12:04:49PM +0100, Fabio Fantoni wrote:
> > debian-devel-announce wouldn't let me attach the file, but for those on
> > debian-devel at least, you can find the dd-list of to-be-NMUed source
> > packages attached.
> > debian-devel-announce wouldn't let me attach the file, but for those on
> > debian-devel at least, you can find the dd-list of to-be-NMUed source
> > packages attached.
> From what I understand, for most of the packages involved a rebuild is
> enough
This list of packages are the packages that require sourceful changes
> enough
because the runtime library packages must be renamed to declare the ABI
incompatibility (or, if a package rename is not appropriate, then managed
Breaks: against binaries built against the old ABI).
We have a list of the packages that need no-change-rebuilds, but it's not
this list.
> but this rebuild must be done after that of all their dependencies
> (dependencies of dependencies etc...) involved to avoid unexpected events
> that could cause crashes on some architectures (in cases ABI changes
> occurred in the underlying dependencies but the rebuild was done before
> one of those).
> Having a package that depends on many and that part of those are themselves
> involved in various other chains, how do NMU (when needed) to unstable and
> rebuilds of other packages happen?
> A single NMU on unstable or rebuild (for each package involved) but with
> such an order so that when it is done all dependencies are already rebuild,
> or with multiple rebuilds between the various migration chains involved?
we will push no-change rebuilds of all packages depending on the old runtime
library names.
There should be no need for multiple rounds of uploads; *all* packages with
dependencies on *any* of the renamed libraries will be triggered as a batch.
There may be build failures if there are interdependencies between some of
these packages because of unsatisfiable build dependencies, but those will
be resolved semi-automatically in cooperation with the buildd maintainers
and only one round of builds will actually be required.
Christoph Berg
Feb 4, 2024, 5:00:05 PMFeb 4
to
Re: Steve Langasek
> Christoph Berg <my...@debian.org>
> postgresql-16 (U)
Please do not upload postgresql-16 before I ack the diff.
I'll also note that *ALL* nmu diffs I've seen so far are using the
wrong version number in debian/changelog, missing the "~exp1" upload
from the actual upload. I've imported some nmu diffs into the
packaging gits, and now everything is wrong.
Christoph
> Christoph Berg <my...@debian.org>
> postgresql-16 (U)
Please do not upload postgresql-16 before I ack the diff.
I'll also note that *ALL* nmu diffs I've seen so far are using the
wrong version number in debian/changelog, missing the "~exp1" upload
from the actual upload. I've imported some nmu diffs into the
packaging gits, and now everything is wrong.
Christoph
Otto Kekäläinen
Feb 4, 2024, 7:10:07 PMFeb 4
to
done for the wrong package, it should probably have been done for
libmariadb3 and not for libmariabd19.
apt-cache rdepends --no-recommends --no-suggests libmariadb3
= 120 packages
vs zero packages using libmariadbd (that library is useful mostly for
embedded systems doing custom binaries)
I am ready to update/finalize the name change myself (draft at
https://salsa.debian.org/mariadb-team/mariadb-server/-/merge_requests/68)
if I get a reply from Graham on how you wish to proceed with this.
Steve Langasek
Feb 5, 2024, 2:10:05 AMFeb 5
to
On Mon, Feb 05, 2024 at 08:57:50AM +0200, Andrius Merkys wrote:
> will be NMU'd directly to unstable. After that happens, will it be OK to
> upload libfoo2 to unstable (as part of libfoo transition), or will it have
> to carry t64 suffix, i.e., libfoo2t64?
In my view, it's fine then to upload libfoo2 to unstable without the t64
suffix as ABI compatibility with experimental is not really required. In
fact, none of the t64 binaries currently being uploaded to experimental have
the final ABI either, we're just using experimental to clear binary NEW.
> On 2024-02-02 19:46, Steve Langasek wrote:
> > If there is no new version in experimental, or there is a new version BUT
> > the patch against unstable applies cleanly to the version in experimental
> > (no fuzz), we upload to experimental.
> > Otherwise, patches are sent to the BTS but we skip uploading to experimental
> > and will NMU directly to unstable at the next stage (handling binary NEW
> > there).
> Given libfoo1 in unstable and libfoo2 in experimental, I assume libfoo1t64
> > If there is no new version in experimental, or there is a new version BUT
> > the patch against unstable applies cleanly to the version in experimental
> > (no fuzz), we upload to experimental.
> > Otherwise, patches are sent to the BTS but we skip uploading to experimental
> > and will NMU directly to unstable at the next stage (handling binary NEW
> > there).
> will be NMU'd directly to unstable. After that happens, will it be OK to
> upload libfoo2 to unstable (as part of libfoo transition), or will it have
> to carry t64 suffix, i.e., libfoo2t64?
In my view, it's fine then to upload libfoo2 to unstable without the t64
suffix as ABI compatibility with experimental is not really required. In
fact, none of the t64 binaries currently being uploaded to experimental have
the final ABI either, we're just using experimental to clear binary NEW.
Steve Langasek
Feb 5, 2024, 10:50:05 PMFeb 5
to
On Sun, Feb 04, 2024 at 04:08:43PM -0800, Otto Kekäläinen wrote:
> +1 for MariaDB for the above. Also I think the package name change was
> done for the wrong package, it should probably have been done for
> libmariadb3 and not for libmariabd19.
> apt-cache rdepends --no-recommends --no-suggests libmariadb3
> = 120 packages
> vs zero packages using libmariadbd (that library is useful mostly for
> embedded systems doing custom binaries)
$ grep mariadb results/*
> +1 for MariaDB for the above. Also I think the package name change was
> done for the wrong package, it should probably have been done for
> libmariadb3 and not for libmariabd19.
> apt-cache rdepends --no-recommends --no-suggests libmariadb3
> = 120 packages
> vs zero packages using libmariadbd (that library is useful mostly for
> embedded systems doing custom binaries)
results/results_dumped.txt:libmariadb-dev
results/results_failed.txt:libmariadbd-dev
results/results_none.txt:libmariadb-dev
$
There was nothing unintentional here. libmariadb-dev is clean wrt time_t.
libmariadbd-dev failed to be analyzed because it has header ordering
requirements which did not get resolved.
https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt
Much better that there be a library transition only for the lesser-used
library!
Otto Kekäläinen
Feb 5, 2024, 11:10:06 PMFeb 5
to
> $ grep mariadb results/*
> results/results_dumped.txt:libmariadb-dev
> results/results_failed.txt:libmariadbd-dev
> results/results_none.txt:libmariadb-dev
> $
>
> There was nothing unintentional here. libmariadb-dev is clean wrt time_t.
> libmariadbd-dev failed to be analyzed because it has header ordering
> requirements which did not get resolved.
>
> https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt
>
> Much better that there be a library transition only for the lesser-used
> library!
Ok, good. Thanks for the clarification!
> results/results_dumped.txt:libmariadb-dev
> results/results_failed.txt:libmariadbd-dev
> results/results_none.txt:libmariadb-dev
> $
>
> There was nothing unintentional here. libmariadb-dev is clean wrt time_t.
> libmariadbd-dev failed to be analyzed because it has header ordering
> requirements which did not get resolved.
>
> https://adrien.dcln.fr/misc/armhf-time_t/2024-02-03T09:18:00/logs/libmariadbd-dev/base/log.txt
>
> Much better that there be a library transition only for the lesser-used
> library!
Alberto Garcia
Feb 6, 2024, 12:40:05 PMFeb 6
to
On Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek wrote:
> In fact, none of the t64 binaries currently being uploaded
> to experimental have the final ABI either, we're just using
> experimental to clear binary NEW.
I was having a look at two of the packages that I maintain that have
> In fact, none of the t64 binaries currently being uploaded
> to experimental have the final ABI either, we're just using
> experimental to clear binary NEW.
t64 binaries in experimental and I noticed that while the binary
package does have a different name the .so files themselves are the
same. Is this expected when we're talking about an ABI break?
Berto
Andreas Metzler
Feb 6, 2024, 12:50:05 PMFeb 6
to
It is expected for this ABI break yes. Essentially we are just doing a
rebuild-everything-involved while making sure the package
interdependencies avoid a (breaking) mixture. This is similar what we
did when the C++ ABI changed.[1]
cu Andreas
https://lists.debian.org/debian-release/2005/04/msg00153.html
Bill Allombert
Feb 7, 2024, 5:20:04 AMFeb 7
to
Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit :
> > I don't see any practical reason why not.
>
> Because packages are not required to use dpkg-buildflags.
And more generally, does this scheme will require to build third-party
> > I don't see any practical reason why not.
>
> Because packages are not required to use dpkg-buildflags.
packages on 32bit Debian system to set
CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
or will this be made the default in gcc or glibc ?
Ansgar
Feb 8, 2024, 2:10:05 PMFeb 8
to
Hi,
On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
>
> - dpkg uploaded to unstable with abi=time64 enabled by default[5]
How does this work when a user builds their own software using any
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?
If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.
Ansgar
On Fri, 2024-02-02 at 08:21 -0800, Steve Langasek wrote:
> Once all of these packages have built in experimental and we have identified
> and addressed all adverse interactions with the usrmerge transition, the
> plan is:
>
> - dpkg uploaded to unstable with abi=time64 enabled by default[5]
library build with abi=time64? They will still get a 32bit time_t &
others unless they use dpkg-buildflags as well, won't they?
If we already change ABI, why not change this in the toolchain (glibc,
gcc) so also user-build packages use the correct ABI? That was what
happened for other ABI changes like the C++ ABI change as far as I
remember.
Ansgar
Matthias Klose
Feb 8, 2024, 3:00:04 PMFeb 8
to
both the old and the new ABI, defaulting to the new ABI.
We can define that macro in GCC, however at the moment I'm unsure how to
turn it off when passing explicitly -U. When doing that in GCC, it also
should be done in other compilers like clang.
And there should be an explicit document/wiki page, which architectures
(including ports) will have this turned on. For now I only know that it
will be turned on for armhf, and not for i386.
Matthias
Bill Allombert
Feb 14, 2024, 10:50:04 AMFeb 14
to
Le Sun, Feb 04, 2024 at 11:05:46PM -0800, Steve Langasek a écrit :
> In my view, it's fine then to upload libfoo2 to unstable without the t64
> suffix as ABI compatibility with experimental is not really required. In
> fact, none of the t64 binaries currently being uploaded to experimental have
> the final ABI either, we're just using experimental to clear binary NEW.
But then libfoo2t64 will need to clear binary NEW again.
> In my view, it's fine then to upload libfoo2 to unstable without the t64
> suffix as ABI compatibility with experimental is not really required. In
> fact, none of the t64 binaries currently being uploaded to experimental have
> the final ABI either, we're just using experimental to clear binary NEW.
Would not have been possible to send the list of new t64 package names
to approve to the ftp-master team directly, instead of using the NEW
queue and interferring with the maintainers use of experimental ?
Bill Allombert
Feb 14, 2024, 5:20:04 PMFeb 14
to
On Fri, Feb 02, 2024 at 08:23:44PM +0100, Bill Allombert wrote:
> > > Relying on dpkg-buildflags alone cannot be sufficient.
> >
> > I don't see any practical reason why not.
>
> Because packages are not required to use dpkg-buildflags.
Also currently, there are about 20 lib*t64 packages in experimental
> > > Relying on dpkg-buildflags alone cannot be sufficient.
> >
> > I don't see any practical reason why not.
>
> Because packages are not required to use dpkg-buildflags.
that are missing the actual library file:
compare:
https://packages.debian.org/sid/amd64/libbigwig0/filelist
with
https://packages.debian.org/experimental/amd64/libbigwig0t64/filelist
and
https://packages.debian.org/sid/amd64/libbpp-core4/filelist
with
https://packages.debian.org/experimental/amd64/libbpp-core4t64/filelist
etc. (List below).
--
libbigwig0t64
libbpp-core4t64
libbpp-phyl12t64
libbpp-phyl-omics3t64
libbpp-popgen8t64
libbpp-qt2t64
libbpp-raa4t64
libbpp-seq12t64
libbpp-seq-omics3t64
libcamp0.8t64
libcapi20-3t64
libc-client2007t64-dev
libhighwayhash0t64
libmems1t64
libpari-gmp-tls8t64
librostlab3t64
libslow5-0t64
libtabixpp0t64
libtecla1t64
libterralib3t64
libxqdbm3t64
Steve Langasek
Feb 16, 2024, 1:40:04 AMFeb 16
to
Thank you for your rigorous scrutiny regarding the proposed plan.
It was a blindspot on my part that dpkg-buildflags was not a policy mandate,
because by this point I'm quite *used* to using dpkg-buildflags to manage
transitions in the default build flags for the compiler.
What I hadn't taken into account is that in those previous transitions, the
consequence of failing to use dpkg-buildflags in a small number of packages
was that those packages did not get certain improvements (in QA,
performance, security, etc) - whereas in this case the consequence of
missing these flags is instead a potentially critical crasher bug due to ABI
skew.
I am delayed in responding to this feedback in part because the realization
pulled me up short and caused me to have to take stock internally of the
overall transition plan.
I think we do need to change the default gcc behavior on our 32-bit archs to
correctly manage this transition. I believe the correct sequence now should
be:
- change (the default) gcc to emit the necessary preprocessor flags by
default.
- also change dpkg-buildflags to emit them by default (abi=+time64:
-D[...]; abi=-time64: -U[...]).
- do the mass uploads to unstable.
(I don't think the critical path here should block on changing the default
behavior of non-default compilers - either non-default gcc versions or llvm.
Packages that *both* use a non-default C compiler to build *and* don't honor
dpkg-buildflags are a corner case, and we can identify any affected packages
retrospectively rather than having them delay the main event to the
detriment of other development in unstable.)
On Wed, Feb 07, 2024 at 10:12:33AM +0000, Bill Allombert wrote:
> Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit :
Right: addressing this in the default behavior of the default compiler sorts
out the non-package build question also.
I (and colleagues on the Ubuntu Foundations team) will work with the gcc
maintainer to establish a timeline for when we can have such a change
landed.
It was a blindspot on my part that dpkg-buildflags was not a policy mandate,
because by this point I'm quite *used* to using dpkg-buildflags to manage
transitions in the default build flags for the compiler.
What I hadn't taken into account is that in those previous transitions, the
consequence of failing to use dpkg-buildflags in a small number of packages
was that those packages did not get certain improvements (in QA,
performance, security, etc) - whereas in this case the consequence of
missing these flags is instead a potentially critical crasher bug due to ABI
skew.
I am delayed in responding to this feedback in part because the realization
pulled me up short and caused me to have to take stock internally of the
overall transition plan.
I think we do need to change the default gcc behavior on our 32-bit archs to
correctly manage this transition. I believe the correct sequence now should
be:
- change (the default) gcc to emit the necessary preprocessor flags by
default.
- also change dpkg-buildflags to emit them by default (abi=+time64:
-D[...]; abi=-time64: -U[...]).
- do the mass uploads to unstable.
(I don't think the critical path here should block on changing the default
behavior of non-default compilers - either non-default gcc versions or llvm.
Packages that *both* use a non-default C compiler to build *and* don't honor
dpkg-buildflags are a corner case, and we can identify any affected packages
retrospectively rather than having them delay the main event to the
detriment of other development in unstable.)
On Wed, Feb 07, 2024 at 10:12:33AM +0000, Bill Allombert wrote:
> Le Fri, Feb 02, 2024 at 08:23:42PM +0100, Bill Allombert a écrit :
> > > I don't see any practical reason why not.
> > Because packages are not required to use dpkg-buildflags.
> > Because packages are not required to use dpkg-buildflags.
> And more generally, does this scheme will require to build third-party
> packages on 32bit Debian system to set
> CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> or will this be made the default in gcc or glibc ?
> packages on 32bit Debian system to set
> CFLAGS=D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64
> or will this be made the default in gcc or glibc ?
out the non-package build question also.
I (and colleagues on the Ubuntu Foundations team) will work with the gcc
maintainer to establish a timeline for when we can have such a change
landed.
Steve Langasek
Feb 16, 2024, 3:00:06 AMFeb 16
to
toolchain-driven ABI transitions where the upstream soname of the library
does not change (c102, c2, c2a, ldbl, v5...).
It is also an important part of ensuring this transition is NOT disruptive
on architectures where there is no ABI change (all 64-bit architectures +
i386).
Steve Langasek
Feb 16, 2024, 3:20:04 AMFeb 16
to
Hi Alastair,
On Sat, Feb 03, 2024 at 08:11:21AM +0000, 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.
On Sat, Feb 03, 2024 at 08:11:21AM +0000, 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.
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.
possible, but we will not be pulling experimental versions into unstable as
part of this.
Alastair McKinstry
Feb 18, 2024, 1:10:06 PMFeb 18
to
Hi Steve
On 16/02/2024 08:11, Steve Langasek wrote:
> Hi Alastair,
>
> On Sat, Feb 03, 2024 at 08:11:21AM +0000, 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
On 16/02/2024 08:11, Steve Langasek wrote:
> Hi Alastair,
>
> On Sat, Feb 03, 2024 at 08:11:21AM +0000, 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.)
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.
>
Alastair
Alastair McKinstry
Feb 19, 2024, 10:30:03 AMFeb 19
to
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 ;
>
> 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
> in close inspection: it moves MPI_Integer type from 4 to 8 bytes.
>
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
> I have yet to upload an mpich transition bug to request transition.
SO interface hasn't changed, so how do I write the appropriate BEN code?
0 new messages