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: debian-arm@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/ slangasek@ubuntu.com vorlon@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=debian-arm@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-0