Y2038 - best way forward in Debian?

classic Classic list List threaded Threaded
80 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Y2038 - best way forward in Debian?

Steve McIntyre
Hey folks,

Apologies - I should have sent this mail quite a while back. :-/

Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
the 2038 problem in the Linux world. I've spoken about this before,
e.g. at DebConf17. He's been pushing a lot of updates throughout the
Linux kernel, and has also been analysing code elsewhere. He's very
interested in how to update complete systems like Debian too, and we
spoke about this some time ago.

The kernel is *basically* fixed now. Internally, data structures
should now be safe. There are a small number places where 32-bit time
is still a thing, but it's in hand. A number of syscalls, ioctls,
etc. have needed updates for the user-kernel interface level. glibc is
the place that needs to care about most of this.

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.

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.

Arnd scanned the library packages in the Debian archive and identified
that about one third of our library packages would need rebuilding
(and tracking) to make a (recursive) transition. We can see two
different possible routes to follow:

 A Follow a similar path to last time (rename library packages). This
   will allow us to do partial upgrades, but the cost is that a vast
   number of packages will need work to make this happen,
   *potentially* building library packages twice to allow us to
   continue both 32-bit and 64-bit time_t support forwards for a
   while. This effort will be *needed* only for the sake of our 32-bit
   ports, but would affect *everybody*.

 *** OR ***

 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:

   * we would end up with two versions of some ports for a short time
     - probably one release of overlap

   * users would *not* be able to simply upgrade from one to the
     other, due to lack of binary compatibility

   We *would* be able to run old and new ABIs on top of the same (new
   enough) kernel (e.g. for buildds), so a lump of this would just be
   simply building the new world and filing bugs where needed.

   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, which way should we go? My own personal gut feel matches Arnd's,
which would be route B. Some of us already have fair experience with
bootstrapping new arches, and we could almost just crank the handle
for most of this work.

What do people think here? Which do you think is the better path? Feel
free to point out things you think I may have missed. We should get
started on this soon - the longer we leave it, the more likely it is
that we'll see 2038 bugs biting people.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Andrey Rahmatullin-3
On Tue, Feb 04, 2020 at 01:14:10PM +0000, Steve McIntyre wrote:
>  B Decide which 32-bit ports we expect to care about by 2038, and
... and consider options taking into account the size of the result list.

--
WBR, wRAR

signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ansgar Burchardt-5
In reply to this post by Steve McIntyre
On Tue, 2020-02-04 at 13:14 +0000, Steve McIntyre wrote:
> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.

At least for i386, I expect it to be used mostly for legacy
applications (and legacy installations).  So breaking ABI by switching
to a "new" architecture or by just changing major libraries like libc6
probably diminishes its value so much that there would no longer be any
use for it: one could just switch to amd64 instead of i386t.

So maybe just recommend people to move to 64-bit architectures and put
32-bit applications in a time namespace so they believe they are still
in 2001 ;-)  32-bit architectures will probably still be useful in
embedded contexts for a long time and there it might be easier to just
change the ABI, but for a general-purpose distribution we start seeing
more and more problems and I don't really see us supporting them as a
full architecture in 10+ years.

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Michael Stone-2
On Tue, Feb 04, 2020 at 03:17:50PM +0100, Ansgar wrote:
>At least for i386, I expect it to be used mostly for legacy
>applications (and legacy installations).  So breaking ABI by switching
>to a "new" architecture or by just changing major libraries like libc6
>probably diminishes its value so much that there would no longer be any
>use for it: one could just switch to amd64 instead of i386t.

Yes, for x86 in particular I don't see any reason to try to rebuild
x86-2038 vs x32 for whatever niche might be filled by a 32 bit ILP.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Holger Levsen-2
In reply to this post by Steve McIntyre
Hi Steve,

many thanks for this heads-up report!

On Tue, Feb 04, 2020 at 01:14:10PM +0000, Steve McIntyre wrote:
> 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.

for being able to reproducibly rebuild more Debian packages in
bullseye, this would be good anyway and on all archs.

(everything built before December 2016 for example)


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Marco d'Itri
In reply to this post by Steve McIntyre
On Feb 04, Steve McIntyre <[hidden email]> wrote:

>    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
I agree with Ansgar here: there is no point in rebuilding i386.
The porters for the other architectures who believe that there is value
in such a port should explain why they believe that in ~10 years from
now there will still be NEW 32 bit hardware that will run Debian.

The real questions should be: what is the latest reasonable year to
eventually start these new ports? 2038 is far away, and maybe enough
procrastination will solve this...

--
ciao,
Marco

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Lennart Sorensen
In reply to this post by Steve McIntyre
On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:

> >  * 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.
>
> And that's chosen at build time (i.e. when compiling glibc)?
> Why not provide different entry points for time-manipulating functions,
> so a single build can support both applications using 32bit time and
> applications using 64bit time?
>
> E.g.
>
>     struct time32_t ...
>     struct time64_t ...
>
>     double difftime32 (time32_t time1, time32_t time0);
>     double difftime64 (time64_t time1, time64_t time0);
>
> and in the time.h have
>
>     #if TOO_OLD_TO_LIVE_PAST_2038
>     typedef time32_t time_t;
>     ...
>     #else
>     typedef time64_t time_t;
>     ...
>     #endif

I agree.  Why should this be any different than 64 bit file support?
Transparent on 64 bit architectures, and 32bit code gets to pick the
one it wants to support at compile time while glibc supports both,
and eventually just about everything switches.  You can even eventually
add warnings when any program calls the 32 bit version of the functions.

--
Len Sorensen

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Guillem Jover
In reply to this post by Steve McIntyre
Hi!

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.)

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.

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

> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
>  A Follow a similar path to last time (rename library packages).

>  *** OR ***

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

>    * users would *not* be able to simply upgrade from one to the
>      other, due to lack of binary compatibility

I think this conclusion stems from an incorrect premise. See below.

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

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.

I also think we have a C option, which would be something like:

  C Do a transition equivalent to the LFS one, by either switching
    libraries opportunistically to 64-bit time_t on their next SONAME
    bumps, or by updating them to provide 64-bit variants of their
    interfaces along their 32-bit ones, as done in glibc. Of course
    the main problem here is that the LFS "transition" is not one we
    should be very proud of, as it's been dragging on for a very long
    time, and it's not even close to be finished…

    <https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html>
    (Hmm there seems to be something borked with lintian.d.o, as the
    general tag numbers seem extremely low. :)

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Marco d'Itri
On Feb 04, Guillem Jover <[hidden email]> wrote:

> 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. :/
This may be a good time to mention that SONAMEs like libc6.1 are not
supported by libtool, so in libxcrypt I had to conditionally patch the
generated libtool executable for the architectures that did this.

--
ciao,
Marco

signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Colin Watson
On Tue, Feb 04, 2020 at 06:13:12PM +0100, Marco d'Itri wrote:

> On Feb 04, Guillem Jover <[hidden email]> wrote:
> > 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. :/
>
> This may be a good time to mention that SONAMEs like libc6.1 are not
> supported by libtool, so in libxcrypt I had to conditionally patch the
> generated libtool executable for the architectures that did this.

What exactly went wrong?  libpipeline uses libtool and I've never had to
patch it for libc6.1.

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ben Hutchings-3
In reply to this post by Lennart Sorensen
On Tue, 2020-02-04 at 11:03 -0500, Lennart Sorensen wrote:

> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > >  * 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.
> >
> > And that's chosen at build time (i.e. when compiling glibc)?
> > Why not provide different entry points for time-manipulating functions,
> > so a single build can support both applications using 32bit time and
> > applications using 64bit time?
If I recall correctly, glibc *will* provide both entry points, so there
is no ABI break.  But the size of time_t (etc.) exposed through libc-
dev is fixed at glibc build time.

You should expect that all proposals have already been made and
discussed on the glibc-alpha mailing list over the past few years.

> > E.g.
> >
> >     struct time32_t ...
> >     struct time64_t ...
> >
> >     double difftime32 (time32_t time1, time32_t time0);
> >     double difftime64 (time64_t time1, time64_t time0);
> >
> > and in the time.h have
> >
> >     #if TOO_OLD_TO_LIVE_PAST_2038
> >     typedef time32_t time_t;
> >     ...
> >     #else
> >     typedef time64_t time_t;
> >     ...
> >     #endif
>
> I agree.  Why should this be any different than 64 bit file support?
> Transparent on 64 bit architectures, and 32bit code gets to pick the
> one it wants to support at compile time while glibc supports both,
> and eventually just about everything switches.  You can even eventually
> add warnings when any program calls the 32 bit version of the functions.
LFS is a great example of how *not* to do it.  23 years on, we still
have open bugs for programs that should opt in but didn't.  Not every
program needs to handle > 2 GiB files, but there are now filesystems
with 64-bit inode numbers and they break every non-LFS program that
calls stat().

Similarly, every program that uses wall-clock time will fail as we
approach 2038, and the failure mode is likely to be even worse than
with LFS as few programs will check for errors from time APIs.

Ben.

--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
                                                          - John Lennon


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Russ Allbery-2
In reply to this post by Ansgar Burchardt-5
Ansgar <[hidden email]> writes:

> So maybe just recommend people to move to 64-bit architectures and put
> 32-bit applications in a time namespace so they believe they are still
> in 2001 ;-) 32-bit architectures will probably still be useful in
> embedded contexts for a long time and there it might be easier to just
> change the ABI, but for a general-purpose distribution we start seeing
> more and more problems and I don't really see us supporting them as a
> full architecture in 10+ years.

If we go down this path, can we make cross-grading a supported feature for
the next stable release?  I'm sure I'm not the only one who is stuck with
continuously-upgraded i386 hosts who has been wanting to switch but has
been waiting until cross-grading is a little bit less scary.

--
Russ Allbery ([hidden email])              <https://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Simon Richter
In reply to this post by Colin Watson
Hi Colin,

On Tue, Feb 04, 2020 at 06:48:43PM +0000, Colin Watson wrote:

> > This may be a good time to mention that SONAMEs like libc6.1 are not
> > supported by libtool, so in libxcrypt I had to conditionally patch the
> > generated libtool executable for the architectures that did this.

> What exactly went wrong?  libpipeline uses libtool and I've never had to
> patch it for libc6.1.

Libtool computes the version number in the SONAME of the newly generated
library, so it must be a single integer. There is no way to force it to use
anything else.

That is not a problem for using libtool to link against a library that by
some other method got a SONAME that doesn't follow the conventions.

   Simon

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Steve Langasek
In reply to this post by Lennart Sorensen
On Tue, Feb 04, 2020 at 11:03:03AM -0500, Lennart Sorensen wrote:
> On Tue, Feb 04, 2020 at 09:38:46AM -0500, Stefan Monnier wrote:
> > >  * 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.

> > And that's chosen at build time (i.e. when compiling glibc)?
> > Why not provide different entry points for time-manipulating functions,
> > so a single build can support both applications using 32bit time and
> > applications using 64bit time?

> > E.g.

> >     struct time32_t ...
> >     struct time64_t ...

> >     double difftime32 (time32_t time1, time32_t time0);
> >     double difftime64 (time64_t time1, time64_t time0);

> > and in the time.h have

> >     #if TOO_OLD_TO_LIVE_PAST_2038
> >     typedef time32_t time_t;
> >     ...
> >     #else
> >     typedef time64_t time_t;
> >     ...
> >     #endif

> I agree.  Why should this be any different than 64 bit file support?
> Transparent on 64 bit architectures, and 32bit code gets to pick the
> one it wants to support at compile time while glibc supports both,
> and eventually just about everything switches.  You can even eventually
> add warnings when any program calls the 32 bit version of the functions.

In practice, despite LFS_CFLAGS having been a priority for Debian as far
back as 2003, I think it was no more than 5 years ago that I was still
finding libraries in the archive that were incompatible with LFS because
they were leaking 32-bit types into their own ABIs.  I think the lesson to
be learned from 64-bit file support is that this was NOT managed effectively
as a transition.

--
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/
[hidden email]                                     [hidden email]

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ansgar Burchardt-5
In reply to this post by Russ Allbery-2
Russ Allbery writes:

> Ansgar <[hidden email]> writes:
>
>> So maybe just recommend people to move to 64-bit architectures and put
>> 32-bit applications in a time namespace so they believe they are still
>> in 2001 ;-) 32-bit architectures will probably still be useful in
>> embedded contexts for a long time and there it might be easier to just
>> change the ABI, but for a general-purpose distribution we start seeing
>> more and more problems and I don't really see us supporting them as a
>> full architecture in 10+ years.
>
> If we go down this path, can we make cross-grading a supported feature for
> the next stable release?  I'm sure I'm not the only one who is stuck with
> continuously-upgraded i386 hosts who has been wanting to switch but has
> been waiting until cross-grading is a little bit less scary.

I think the window of opportunity to support this is already over: most
people have already migrated to amd64, there is no real incentive for
these to spend effort on adding support for cross-grading (besides
academic interest, but I for example find adding support for one-time
migrations of legacy systems not that rewarding).

So you would need to recruit people still running i386 hosts, but for
each individual it might be easier to just wait for still existing i386
systems to be decommissioned or just reinstall. (I would likely
recommend reinstalling ancient systems for various reasons anyway.)

For just avoiding the Y2038 problem, i386 might sort itself out already
without additional intervention. From recent popcon reports I get:

| Release        |  i386 |  amd64 | i386/amd64 (%) |
|----------------+-------+--------+----------------|
| 1.41 (etch)    |   323 |     66 |           4.89 |
| 1.46 (lenny)   |   958 |    440 |           2.18 |
| 1.49 (squeeze) |  1753 |   2553 |           0.69 |
| 1.56 (wheezy)  |  3573 |   9455 |           0.38 |
| 1.61 (jessie)  |  4687 |  26977 |           0.17 |
| 1.64 (stretch) |  4932 |  62619 |           0.08 |
| 1.67 (buster)  |  3978 |  66169 |           0.06 |
| 1.69 (t/u)     |   360 |  10445 |           0.03 |
|----------------+-------+--------+----------------|
| Overall        | 20728 | 180079 |           0.12 |
#+TBLFM: $4=$2/$3;%.2f

I'll assume the composition of installations within a release didn't
change over time.

This shows exponential decay for i386 installations (which is expected)
with a factor of ~0.5 for each release.  If we consider 10 years in the
future or 5 releases, one would expect i386 usage to have gone down to
about 0.03 of the current value, that is about 0.002 of installations.

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

YunQiang Su
In reply to this post by Steve McIntyre
Steve McIntyre <[hidden email]> 于2020年2月4日周二 下午9:15写道:

>
> Hey folks,
>
> Apologies - I should have sent this mail quite a while back. :-/
>
> Arnd Bergmann (in CC) has been helping to drive a lot of work to solve
> the 2038 problem in the Linux world. I've spoken about this before,
> e.g. at DebConf17. He's been pushing a lot of updates throughout the
> Linux kernel, and has also been analysing code elsewhere. He's very
> interested in how to update complete systems like Debian too, and we
> spoke about this some time ago.
>
> The kernel is *basically* fixed now. Internally, data structures
> should now be safe. There are a small number places where 32-bit time
> is still a thing, but it's in hand. A number of syscalls, ioctls,
> etc. have needed updates for the user-kernel interface level. glibc is
> the place that needs to care about most of this.
>
> 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.
>
> 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.
>
> Arnd scanned the library packages in the Debian archive and identified
> that about one third of our library packages would need rebuilding
> (and tracking) to make a (recursive) transition. We can see two
> different possible routes to follow:
>
>  A Follow a similar path to last time (rename library packages). This
>    will allow us to do partial upgrades, but the cost is that a vast
>    number of packages will need work to make this happen,
>    *potentially* building library packages twice to allow us to
>    continue both 32-bit and 64-bit time_t support forwards for a
>    while. This effort will be *needed* only for the sake of our 32-bit
>    ports, but would affect *everybody*.
>
>  *** OR ***
>
>  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:
>
>    * we would end up with two versions of some ports for a short time
>      - probably one release of overlap
>
>    * users would *not* be able to simply upgrade from one to the
>      other, due to lack of binary compatibility
>
>    We *would* be able to run old and new ABIs on top of the same (new
>    enough) kernel (e.g. for buildds), so a lump of this would just be
>    simply building the new world and filing bugs where needed.
>
>    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, which way should we go? My own personal gut feel matches Arnd's,
> which would be route B. Some of us already have fair experience with
> bootstrapping new arches, and we could almost just crank the handle
> for most of this work.
>

Is there the option C?

Draft:
  1. define time64_t
  2. for data_struct which act as a part of ABI, define a new data_struct64
  3. for function which act as part of ABI, define a new version func64.
  4. patch all packages to use time64_t instead of time_t step by step.
  5. set a time as deadline (2030?), and then treat all packages
haven't finished
      the migration as rc-buggy.

 Since we have enough time, we can patch all packages in that period.

> What do people think here? Which do you think is the better path? Feel
> free to point out things you think I may have missed. We should get
> started on this soon - the longer we leave it, the more likely it is
> that we'll see 2038 bugs biting people.
>
> --
> Steve McIntyre, Cambridge, UK.                                [hidden email]
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
>  anywhere. Duct tape is magic and should be worshipped."
>    -― Andy Weir, "The Martian"
>


--
YunQiang Su

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Sam Hartman-3
In reply to this post by Steve McIntyre
Steve, you're presuming that we would not create a new soname for libc6
on architectures where we want a new time ABI.

That             s not at all obvious to me.
It seems in the same level of drastic as the other options you are
considering.
So taking it off the table without discussion or consideration doesn't
seem like a good call.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ansgar Burchardt-5
On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
> Steve, you're presuming that we would not create a new soname for
> libc6 on architectures where we want a new time ABI.

Isn't the libc ABI for some reason part of Debian's architecture name?
uclibc-linux-amd64, musl-linux-i386, i386 are distict architectures
after all.  So an incompatible newglibc-linux-i386 would be different
from i386 as well?

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Sam Hartman-3
>>>>> "Ansgar" == Ansgar  <[hidden email]> writes:

    Ansgar> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
    >> Steve, you're presuming that we would not create a new soname for
    >> libc6 on architectures where we want a new time ABI.

    Ansgar> Isn't the libc ABI for some reason part of Debian's
    Ansgar> architecture name?  uclibc-linux-amd64, musl-linux-i386,
    Ansgar> i386 are distict architectures after all.  So an
    Ansgar> incompatible newglibc-linux-i386 would be different from
    Ansgar> i386 as well?

Not if they are coinstallable.
As an example libc5 and libc6 were both on the i386 architecture.

Reply | Threaded
Open this post in threaded view
|

Re: Y2038 - best way forward in Debian?

Ansgar Burchardt-5
On Wed, 2020-02-05 at 09:55 -0500, Sam Hartman wrote:

> > > > > > "Ansgar" == Ansgar  <[hidden email]> writes:
>
>     Ansgar> On Wed, 2020-02-05 at 08:33 -0500, Sam Hartman wrote:
>     >> Steve, you're presuming that we would not create a new soname
> for
>     >> libc6 on architectures where we want a new time ABI.
>
>     Ansgar> Isn't the libc ABI for some reason part of Debian's
>     Ansgar> architecture name?  uclibc-linux-amd64, musl-linux-i386,
>     Ansgar> i386 are distict architectures after all.  So an
>     Ansgar> incompatible newglibc-linux-i386 would be different from
>     Ansgar> i386 as well?
>
> Not if they are coinstallable.
> As an example libc5 and libc6 were both on the i386 architecture.

Why wouldn't musl-linux-i386 be coinstallable with glibc-linux-i386?
Debian's musl package (on amd64) is coinstallable with libc6; we just
don't build anything[1] against alternative libraries.

One practical problem is that you don't want to end up linking two
different C libraries (or really: any core libraries).

I don't really see much difference between libc6 vs libc7 or libc6 vs
libmusl (besides applications that require glibc and might not work
with musl, but that is a separate issue).

This might also mean that musl-linux-i386 shouldn't be a different
architecture than i386.  If they are different, then maybe libstdc++6-
libc6-linux-i386 and libc++-libc6-linux-i386 would need to be different
architectures too?

Ansgar

  [1]: Yes, very few exceptions might exist.

1234