Re: Y2038 - best way forward in Debian?
On Tue, Feb 4, 2020 at 4:03 PM Guillem Jover <guillem@debian.org> wrote:
>
> On Tue, 2020-02-04 at 13:14:10 +0000, Steve McIntyre wrote:
> > The glibc folks have taken an interesting approach.
> >
> > * 64-bit ABIs/architectures are already using 64-bit time_t
> > throughout. The design is sane and so we should already be mostly
> > safe here, modulo silly code bugs (we'll always have those!)
> >
> > * 32-bit ABIs/arches are more awkward. glibc will continue *by
> > default* to use 32-bit time_t to keep compatibility with existing
> > code. This will *not* be safe as we approach 2038.
> >
> > * 32-bit ABIs/arches *can* be told to use 64-bit time_t from glibc
> > upwards, but this will of course affect the ABI. Embedded uses of
> > time_t in libraries will change size, etc. This *will* be safe for
> > 2038.
>
> I think there is still work pending in glibc to expose both 32-bit and
> 64-bit interfaces at the same time? (Currently it seems to be either-or.)
Correct. I was hoping this could be part of the next glibc release
(2.32), but if it takes longer than that, it may be necessary to start
the bootstrap with an inofficial patched version to find the bugs
and the rebuild everything against a proper release.
A new development that Steve did not mention is that musl
already has working time64 support in its git snapshots (release
will be soon), and Adelie Linux has a first release candidate
based on that. There is also a list of known issues at
https://wiki.adelielinux.org/wiki/Project:Time64 with things that
were either discover during the time64 bootstrap of Adelie
or that I found using Debian Codesearch. Most of these are
for packages that use low-level system calls directly rather than
going through glibc, either for syscalls that don't have an
abstraction (seccomp, futex, ...) or for implementing a runtime
environment for a language other than C.
> I'd like to use this for example in libbsd, to make a smooth
> transition similar to the one made in glibc, w/o needing to bump the
> SONAME.
This can clearly work for specific libraries, but I fear doing this across
all affected library packages adds so much extra work and time before
completion that there won't be many people left to use it by the time
the work is done.;-)
The problem is that new deployments of 32-bit systems only
become rarer over time, even though armhf is still the most common
platform in embedded deployments today, ahead of arm64.
I expect that out of the armhf systems still running in 2038 (or a
few years earlier, while the problems of future dated timestamps
start to build up), most of them will run software that is already
deployed (and broken) or being build in the next few years with a
chance of being fixed.
> > So, we're all fine? Not so much: for our 32-bit Debian arches, we will
> > need to basically rebuild the world to be 2038-safe. When we had to do
> > something like this in the past, to deal with the libc5->libc6
> > transition, we had an SONAME change in libc to work with. We decided
> > to append the "g" tag to the names of our library binary packages to
> > signal that a library was built against libc6. We can still see some
> > of the effects of this in the archive, many years later
> > (e.g. zlib1g). The problem now is that we will *not* have an soname
> > change here to help identify code compatibility on the 32-bit front.
>
> Well, I guess such a new (conditinally selectable) name could be
> coordinated with glibc upstream? Say bump 32-bit ports to use libc6.1?
> (We already have precedent in some ports that do not use the same
> prevalent SONAME, such as libc6.1, libc0.1 and libc0.1.) But it would
> indeed involve lots of work, with massive amounts of package renames. :/
The glibc developers have expressed in the past that they do not
consider this an ABI break and would continue to provide an extended
but compatible ABI with the same soname.
On the distro scale, I fear the opposite is true as Steve explained.
> > B Decide which 32-bit ports we expect to care about by 2038, and
> > re-bootstrap new versions of those ports *with different
> > names*. This would allow most of our developers to ignore the
> > problem here (as 64-bit arches are not affected) and let a smaller
> > number of people re-bootstrap with new ABIs with 64-bit time_t
> > embedded. There are some downsides here:
>
> (If we are going for this, I'd say it might make sense to consider
> also enabling LFS, although that might be a dangerous change, see
> the lintian tag for the rationale. :)
Absolutely, this is already a done deal, as both musl and glibc do not
allow the combination of 32-bit off_t with 64-bit time_t. In musl,
both are now 64-bit for new binaries anyway, and in glibc setting
a 64-bit time_t implies LFS.
> > We'd need to decide exactly which of our 32-bit ports we would want
> > to do this path with (probably armhf->arhmft?, maybe
> > armel->armelt?, i386->i386t?. mipsel???). Due to the libc6 soname
> > continuity, we will most likely *not* end up with a different
> > visible ABI via the triplet and the runtime linker, so old/new
> > multi-arch will be impossible.
So far, armhf is the only Debian target architecture that I know needs
this, so it seems best to focus the work on that one. Once the porting
work is done and enough bugs are fixed, the other architectures can
decide if they still care. If any new 32-bit architectures (rv32, arc?)
get added, it would probably be sensible to start out with a time64
port. At least rv32 glibc won't support time32 interfaces anyway.
> A new dpkg architecture must use a different triplet, as these are
> required to be bijective. See “lpia” for a previous example of this.
> (This would then make it possible to cross-grade.)
>
> In addition if we are using a new multiarch triplet, and need to
> rebuild the world, are going to be ABI incompatible anyway, we might
> as well use a proper multiarch-qualified ld.so pathname that does
> not collide with anything.
Right, I can see this being an overall win. If there is going to be
a new name for the architecture in dpkg, then using a new
architecture triplet feels like a cleaner solution. The tradeoff
is an increased amount of work for the benefit of multiarch
support that can help ease the transition.
I have no estimate how much extra work is needed to support a
new target triplet, but my feeling is that this is much less than
the work a new soname or even making thousands of libraries
deal with both time32 and time64 interfaces.
Arnd
Reply to: