Hi folks,
Over on debian-arm@lists, there has been discussion on and off for several
months now about the impending 32-bit timepocalypse. As many of you are
aware, 32-bit time_t runs out of space in 2038; the exact date is now less
than 15 years away. It is not too early to start addressing the question of
32-bit architecture compatibility, as there are already reports in the wild
of calendar failures for future events on 32-bit archs.
While it’s debatable whether most of the 32-bit archs in Debian (and as
unofficial ports) will be in use long enough to worry about 2038, there’s at
least substantial reason to believe that 32-bit ARM (armhf and possibly
armel) will still be in use 15 years from now. Solving this problem has
already been proposed as a release goal for trixie:
https://wiki.debian.org/ReleaseGoals/64bit-time
For those who prefer a primer in video form, Wookey gave a talk at FOSDEM
about this:
https://fosdem.org/2023/schedule/event/fixing_2038/ ;
There are two basic ways to solve this. Either we can rebootstrap the ports
that we want to keep; this makes upgrades unreliable, and doesn’t help any
ports for which we don’t do this work. Or we can do library transitions for
the set of all libraries that reference time_t in their ABI; this is a bit
more work for everyone in the short term because it will impact testing
migration across all archs rather than being isolated to a single port, but
it’s on the order of 500 library packages which is comparable to other ABI
transitions we’ve done in the past (e.g. ldbl
https://lists.debian.org/debian-devel/2007/05/msg01173.html).
The difficulty is, unlike the ldbl or c2 transitions of the past, time_t ABI
compatibility can’t be worked out by static analysis of the exposed symbols,
only by traversing the headers and mapping them to the library ABI. So when
I say “on the order of 500 packages”, this is because at the moment we have
about 1900 -dev packages that have failed to be analyzed because their
headers don’t compile out of the box. I am currently working through
getting these all analyzed, prioritized by number of reverse-dependencies,
but this process will take at least a couple of months before we have a
complete list of libraries to be transitioned. Help improving the scripts
at https://salsa.debian.org/vorlon/armhf-time_t/ to complete this analysis
is welcome.
Based on the analysis to date, we can say there is a lower bound of ~4900
source packages which will need to be rebuilt for the transition, and an
upper bound of ~6200. I believe this is a manageable transition, and
propose that we proceed with it at the start of the trixie release cycle.
=== Technical details ===
The proposed implementation of this transition is as follows:
* Update dpkg-buildflags to emit -D_FILE_OFFSET_BITS=64 and -D_TIME_BITS=64
by default on 32-bit archs. (Note that this enables LFS support, because
glibc’s 64-bit time_t implementation is only available with LFS also
turned on, to avoid a combinatorial explosion of entry points.)
* … but NOT on i386. Because i386 as an architecture is primarily of
interest for running legacy binaries which cannot be rebuilt against a new
ABI, changing the ABI on i386 would be counterproductive, as mentioned in
https://wiki.debian.org/ReleaseGoals/64bit-time.
* For a small number of packages (~80) whose ABI is not sensitive to time_t
but IS sensitive to LFS, along with their reverse-dependencies, filter out
the above buildflags with DEB_BUILD_MAINT_OPTIONS=future=-lfs[1].
Maintainers may choose to introduce an ABI transition for LFS, but as this
is not required for time_t, we should not force it as part of *this*
transition. If there is a package that depends on both a time_t-sensitive
library and an LFS-sensitive but time_t-insensitive library, however, then
the LFS library will need to transition.
* Largely via NMU, add a “t64” suffix to the name of runtime library
packages whose ABI changes on rebuild with the above flags. If an
affected library already has a different suffix (c102, c2, ldbl, g…), drop
it at this time.
* In order to not unnecessarily break compatibility with third-party (or
obsolete) packages on architectures where the ABI is not actually
changing, on 64-bit archs + i386, emit a Provides/Replaces/Breaks of the
old library package name. A sample implementation of the necessary
packaging changes is at
https://salsa.debian.org/vorlon/armhf-time_t/-/blob/main/time-t-me.
* Once the renamed library packages have been built on all archs and
accepted through binary NEW, issue binNMUs of the reverse-dependencies
across *all* architectures, to ensure that users get upgraded to the
current runtime library package and aren’t left with stale packages under
the old name on upgrade.
* In the future when the upstream SONAME changes, the t64 suffix should be
dropped.
Your thoughts?
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] Seeing that the future is now, maybe we want to consider changing the
canonical name for this from future=-lfs to abi=-lfs? Bikeshed at will!
Attachment:
signature.asc
Description: PGP signature