Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

64-bit time_t transition in progress

Skip to first unread message

Steve Langasek

Feb 2, 2024, 11:30:04 AMFeb 2
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:

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: 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:


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

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

(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].

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

[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
0 new messages