Bug#1108361: release-notes: Document time64 transition on relevant 32-bit arches
Chris Hofstaedtler wrote:
> On Fri, Jun 27, 2025 at 01:14:07AM +0200, Guillem Jover wrote:
>> I see no explicit mention of the time64 transition. I think this should
>> be documented because the transition involved a no-SONAME-rename which
>> means we broke the involved architectures ABI, where we protected the
>> archive from that breakage via packaging metadata. But for locally
>> built code, this can silently break it while those binaries do not fail
>> to link. The exception (and its rationale) for i386 should also be
>> mentioned.
>
> Agreed, but somebody needs to come up with the text.
>
> I don't know the rationales and what is actually noteworthy about
> the transition.
First question: where does it go? If we think of it as a "new
feature" of Y2038-safety, it ought to go in 2.2 or thereabouts; if
we're putting the emphasis on the dangers then it belongs in 5.1
(perhaps immediately after the section on i386).
There's material at
https://wiki.debian.org/ReleaseGoals/64bit-time (including
particularly the "Goal Description" and "Issues" sections), though
that page could itself do with an overhaul to account for the fact
that the transition is finished.
Here's a first stab at it just to get the ball rolling:
2.x time64 ABI transition
~~~~~~~~~~~~~~~~~~~~~~~~~
All architectures other than `i386` now use a 64-bit `time_t` ABI,
which can deal with dates beyond 2038. This transition required the
32-bit `armel` and `armhf` architectures to change the libraries
involved without a change of soname
([[https://wiki.debian.org/ReleaseGoals/64bit-time|see wiki page for
details]]), so third-party software handling dates on these systems
will need to be recompiled to avoid breakage. The `i386` architecture
did not participate in this transition, since its primary function is
to support legacy software.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: