Re: Y2038 - best way forward in Debian?

[Adrian Bunk]

On Fri, Feb 14, 2020 at 10:56:47AM -0600, John Goerzen wrote:
> 
> The thing that we have to remember is that an operating system is a
> platform for running software.  This problem is rather thorny, because:
> 
> 1) Some software is provided in only binary form and cannot be
> recompiled
> 
> 2) Some software can be recompiled but makes assumptions about the size
> of variables, may use int instead of time_t, and other assorted
> messiness

Cleanest would be to run such legacy programs inside some virtualization 
that also provides a virtual time long before 2038, using the last 
Debian release with the old architecture.

> 3) Some software is going to break now, due to forward-looking time
> calculations, and for others, it may be fine (or nearly so) even past
> 2038 due to timekeeping being only ancillary to its purpose.  For
> instance, I have some old games that are binary-only and really don't
> care what time it is.
>...

How confident are you that they work fine with negative time_t values?
Functions like time(2) return (time_t)-1 on error.

> John

cu
Adrian

Re: Y2038 - best way forward in Debian?

[Anthony DeRobertis]

On February 14, 2020 7:45:30 PM UTC, Alan Corey  wrote:
>What if we define an epoch to be 50 years and the epoch number becomes
>part of how the computer keeps track of the date.  Something similar
>is done in astronomy I think, star charts always have an epoch.  So
>epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050.   Then we can keep
>a time_t at 32 bits.  Things like strptime() and strftime() and
>ctime() would need changing but since they were valid in epoch 0
>they'd only need to change for epoch 1 and later. 

Everything that handles time would need to change. Just think of the fun of 
"what's one year from today?" when you cross an epic. Far easier to just make 
time_t 64-bit.

And file formats and protocols that currently use time_t would need to be 
adjusted to add a second field for an epoch. Same incompatibility concerns as 
64-bit time_t. 

Not to mention that the Gregorian calendar leap year cycle is 400 years long, 
so if you ignore the epic, you'll have no idea if it's a leap year. Which also 
means that you have no idea how long your 50-year epic is, since they vary, 
they're not all the same number of seconds, or even days.

Ultimately, you'd wind up with a presumably int-sized epoch plus an int sized 
time_t. That's 64 bits still...

Lastly, 64-bit time_t has been tested widely (e.g., on amd64). That's not 
perfect of course since 32-bit archs have smaller basic integer types, but 
likely a lot less work fixing the stray "int"s than adding epochs all over the 
place. 

PS: Debian-devel is likely the wrong place to redesign C/POSIX functions. 

Re: Y2038 - best way forward in Debian?

[Alan Corey]

What if we define an epoch to be 50 years and the epoch number becomes
part of how the computer keeps track of the date.  Something similar
is done in astronomy I think, star charts always have an epoch.  So
epoch 0 was 1970, epoch 1 is 2000, epoch 2 is 2050.   Then we can keep
a time_t at 32 bits.  Things like strptime() and strftime() and
ctime() would need changing but since they were valid in epoch 0
they'd only need to change for epoch 1 and later.  A day will continue
to be 86400 seconds of a 32-bit number but every 50 years the epoch
would change.  Dates can overlap epochs so 2020 could be part of epoch
0 and epoch 1.  The year part of a time_t and struct tm ceases to be
absolute like an hour isn't absolute on a 12-hour clock.  It's
probably been thought of.

On 2/14/20, John Goerzen  wrote:
> On Tue, Feb 04 2020, Steve McIntyre wrote:
>
>> 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*.
>
> The thing that we have to remember is that an operating system is a
> platform for running software.  This problem is rather thorny, because:
>
> 1) Some software is provided in only binary form and cannot be
> recompiled
>
> 2) Some software can be recompiled but makes assumptions about the size
> of variables, may use int instead of time_t, and other assorted
> messiness
>
> 3) Some software is going to break now, due to forward-looking time
> calculations, and for others, it may be fine (or nearly so) even past
> 2038 due to timekeeping being only ancillary to its purpose.  For
> instance, I have some old games that are binary-only and really don't
> care what time it is.
>
> This option #1 sounds like a significant effort (because not only would
> we need two versions of libraries, but also of include files).  But it
> certainly passes the "correctness" test better than your option #2.
>
> John
>
>


-- 
-
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: Y2038 - best way forward in Debian?

[John Goerzen]

On Tue, Feb 04 2020, Steve McIntyre wrote:

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

The thing that we have to remember is that an operating system is a
platform for running software.  This problem is rather thorny, because:

1) Some software is provided in only binary form and cannot be
recompiled

2) Some software can be recompiled but makes assumptions about the size
of variables, may use int instead of time_t, and other assorted
messiness

3) Some software is going to break now, due to forward-looking time
calculations, and for others, it may be fine (or nearly so) even past
2038 due to timekeeping being only ancillary to its purpose.  For
instance, I have some old games that are binary-only and really don't
care what time it is.

This option #1 sounds like a significant effort (because not only would
we need two versions of libraries, but also of include files).  But it
certainly passes the "correctness" test better than your option #2.

John

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Tue, Feb 11, 2020 at 9:10 PM Florian Weimer  wrote:
> * Ansgar:
> > Arnd Bergmann writes:
> >> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
> >>> There's going to be a _TIME_BITS selector, similar to
> >>> _FILE_OFFSET_BITS.
> >>>
> >>> There was a proposal to have only one API before, but I think the
> >>> agreement was that it wouldn't save much complexity.
> >>
> >> It should be easy to force the _TIME_BITS selection by patching the
> >> glibc headers in Debian though if we want.
> >>
> >> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
> >> but leaving the libc default at 32 bits is that anything that users build
> >> themselves or that ignores the buildflags ends up with a broken ABI
> >> when linking against one of the many libraries that expose time_t
> >> in their ABI.
> >
> > It breaks the other way too:
> >
> > If you have an old library with a time_t in some public ABI, but an
> > application using it sets _TIME_BITS=64, the headers suddenly define a
> > different ABI from the one implemented by the compiled library.
> >
> > If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> > breaks reverse dependencies (ignoring special handling like libc does
> > with versioned symbols). So you cannot just change it by default.
> >
> > I don't understand how this can work unless time_t is *never* exposed by
> > any library other than libc.

I think Steve explained this already in the initial email: in approach A,
rebuilding any library that exposes a modified time_t implies an incompatible
library update and updating anything that depends on it to be built with
the time64 interface as well, which quickly gets out of hand when you do this
recursively.

With approach B, there is no attempt at binary compatibility, instead
a new armhf_time64 port would use the same package names and
versions as the existing armhf port, but have an incompatible ABI
for anything exposing time_t based interfaces. Changing the target
triplet then allows a multiarch installation to coexist with armhf, the
same way that you can have armel and armhf coexisting today, with
an incompatible ABI.

> Correct.  We have this problem with off_t today, which is used in some
> header files.  The problem is particularly thorny because like
> off64_t, time64_t will never be a standard type, so some projects
> don't want to use it in headers.  And using time64_t would still be an
> ABI break on i386.

AFAIU time64_t is not even going to be exposed in the glibc headers
in the first place, you just pick which ABI you get when compiling an
application and hope it matches the other libraries.

Arnd

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ansgar:

> Arnd Bergmann writes:
>> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>>> There's going to be a _TIME_BITS selector, similar to
>>> _FILE_OFFSET_BITS.
>>>
>>> There was a proposal to have only one API before, but I think the
>>> agreement was that it wouldn't save much complexity.
>>
>> It should be easy to force the _TIME_BITS selection by patching the
>> glibc headers in Debian though if we want.
>>
>> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
>> but leaving the libc default at 32 bits is that anything that users build
>> themselves or that ignores the buildflags ends up with a broken ABI
>> when linking against one of the many libraries that expose time_t
>> in their ABI.
>
> It breaks the other way too:
>
> If you have an old library with a time_t in some public ABI, but an
> application using it sets _TIME_BITS=64, the headers suddenly define a
> different ABI from the one implemented by the compiled library.
>
> If you rebuild the library with _TIME_BITS=64, it changes ABI too and
> breaks reverse dependencies (ignoring special handling like libc does
> with versioned symbols). So you cannot just change it by default.
>
> I don't understand how this can work unless time_t is *never* exposed by
> any library other than libc.

Correct.  We have this problem with off_t today, which is used in some
header files.  The problem is particularly thorny because like
off64_t, time64_t will never be a standard type, so some projects
don't want to use it in headers.  And using time64_t would still be an
ABI break on i386.

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Tue, Feb 11, 2020 at 12:07 PM Marco d'Itri  wrote:
>
> On Feb 11, Arnd Bergmann  wrote:
>
> > I agree that changing the i386 port is probably a bad idea at the moment,
> > let's see how the armhf port turns out and fix all the bugs first, as this
> > is clearly needed anyway. Once there is a working armhf version with
> > full time64 user space, there can be a separate discussion about what
> > to do with the i386 port (phase out i386 before y2038, migrate all of
> > i386 to time64 quickly, have two separate i386 ports, or something
> > else).
>
> I have still not seen any explanation about why we expect that 32 bit
> ARM systems will still be popular (as non-embedded) ~15 years from now.

I think most installations of Debian on 32-bit ARM are already for embedded
systems, but that doesn't make them less important IMHO. In some deeply
embedded systems, you'd be looking at installing a current version of Debian
(because why not) and then running it for decades beyond the end of support
without updates. While this is often no problem in the absence of attack
vectors, the time32 problem means that a piece of industrial equipment
may be created for a 40 year lifetime today and work flawlessly for the first
18 years before suddenly breaking. The sooner time64 gets supported in
Debian, the more of them have a  chance of surviving.

I did some research last year to see how long these systems tend to
live before they are obsolete, here is a rough summary for each architecture
version:

* ARMv4 based chips were released between ~1997 and 2007, the last
  supported released was Debian Lenny, originally in 2009, with support
  ending in 2012.
* ARMv4T based chips were more popular and came out during the
  same timeframe (1997 to 2007), last supported in Debian Stretch,
  released in 2017 and LTS support ending in 2022.
* ARMv5 was introduced in ~2002 and is still supported, with a few
  new chips still being taped out (Microchip SAM9X60, Allwinner
  F-Series) and being actively deployed in large numbers for several
  years to come. I expect the last Debian release with ARMv5 support
  between 2025 and 2030, with the last users relying on Debian LTS
  powering the hardware off well before 2038.
* ARMv6 was less popular, most chips (i.MX3, S3C64xx, OMAP2)
  from 2005 to 2014 are obsolete or never ran Debian in the first
  place (e.g. AST2500). The main exception is probably Raspbian
  on BCM2835, which surely will be used as long as you can
  fit Debian into 512MB of RAM, plus several years after support
  ends, probably beyond 2038.
* ARMv7 chips came out between 2005 and 2015 but were more
  popular than the above combined. Since Cortex-A5 is now part of
  Arm's DesignStart program, we will see new tapeouts for years to
  come, and some of them are likely to run Debian for longer than the
  existing chips.
* ARMv7VE (first introduced in 2012) is still the most common
  architecture for embedded designs today, we'll probably see new
  Cortex-A7 based chips for another 5 to 10 years, followed by several
  years of new boards based on those chips and a very long time
  before these finally get powered off.
* ARMv8 is surely taking over the lead in the embedded space from
  ARMv7/ARMv7VE over the next few years. Almost all of these
  can run 64-bit code, but when shipping enough of them, the cost
  of the on-board RAM means you are stuck with a single 4Gbit DDR3
  chip (512MB), which in turn means you want to run 32-bit user
  space to lower the memory consumption for the application.
  The next sensible step up from 512MB DDR3 (on a single chip) is
  probably 2GB of LP-DDR4 with 64-bit user space, but it will likely
  take many years before that is actually cheap enough completely
  obsolete DDR3 memory and 32-bit mode with it.

  Arnd

Re: Y2038 - best way forward in Debian?

[Steve McIntyre]

On Tue, Feb 11, 2020 at 12:01:28PM +0100, Marco d'Itri wrote:
>On Feb 11, Arnd Bergmann  wrote:
>
>> I agree that changing the i386 port is probably a bad idea at the moment,
>> let's see how the armhf port turns out and fix all the bugs first, as this
>> is clearly needed anyway. Once there is a working armhf version with
>> full time64 user space, there can be a separate discussion about what
>> to do with the i386 port (phase out i386 before y2038, migrate all of
>> i386 to time64 quickly, have two separate i386 ports, or something
>> else).
>I have still not seen any explanation about why we expect that 32 bit 
>ARM systems will still be popular (as non-embedded) ~15 years from now.

That's a fair question to ask!

We're already seeing quite a number of people embedding small-ish
ARMv7 boards in infrastructure, and AIUI a lot of them are using
Debian as a base already - see the Civil Infrastructure Platform as an
example: https://www.cip-project.org/

As these people are already engaging in ELTS work, I don't expect that
this setup is going to go away any time soon.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
You raise the blade, you make the change... You re-arrange me 'til I'm sane...

Re: Y2038 - best way forward in Debian?

[Marco d'Itri]

On Feb 11, Arnd Bergmann  wrote:

> I agree that changing the i386 port is probably a bad idea at the moment,
> let's see how the armhf port turns out and fix all the bugs first, as this
> is clearly needed anyway. Once there is a working armhf version with
> full time64 user space, there can be a separate discussion about what
> to do with the i386 port (phase out i386 before y2038, migrate all of
> i386 to time64 quickly, have two separate i386 ports, or something
> else).
I have still not seen any explanation about why we expect that 32 bit 
ARM systems will still be popular (as non-embedded) ~15 years from now.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Y2038 - best way forward in Debian?

[Ansgar]

Arnd Bergmann writes:
> On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>> There's going to be a _TIME_BITS selector, similar to
>> _FILE_OFFSET_BITS.
>>
>> There was a proposal to have only one API before, but I think the
>> agreement was that it wouldn't save much complexity.
>
> It should be easy to force the _TIME_BITS selection by patching the
> glibc headers in Debian though if we want.
>
> The problem with setting _TIME_BITS=64 only using dpkg-buildflags
> but leaving the libc default at 32 bits is that anything that users build
> themselves or that ignores the buildflags ends up with a broken ABI
> when linking against one of the many libraries that expose time_t
> in their ABI.

It breaks the other way too:

If you have an old library with a time_t in some public ABI, but an
application using it sets _TIME_BITS=64, the headers suddenly define a
different ABI from the one implemented by the compiled library.

If you rebuild the library with _TIME_BITS=64, it changes ABI too and
breaks reverse dependencies (ignoring special handling like libc does
with versioned symbols). So you cannot just change it by default.

I don't understand how this can work unless time_t is *never* exposed by
any library other than libc.

Ansgar

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Fri, Feb 7, 2020 at 10:21 PM Florian Weimer  wrote:
>
> * Steve McIntyre:
>
> > 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.
>
> XFS is the elephant in the room, though.

XFS is one of the main concerns for 64-bit kernels, but the patches
are likely to get merged in one of the next releases.

For 32-bit, all the ABI issues need to be solved first to have
a working system at all, so let's get that sorted. Obviously all
problems that 64-bit has also need to be solved on 32-bit.

> > glibc is the place that needs to care about most of this.
>
> I'm not so sure.  I really do not want glibc to parse and rewrite
> ioctl arguments and return values, or ancillary socket data.

For a new distro target, it's easy to mandate a minimum kernel
version that has all the ioctls. Users that are stuck on old kernels
for a particular hardware can keep using the existing armhf user
space until that is discontinued.

> >  * 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.
>
> The question is whether anyone wants an i386 port where this has
> happened.
>
> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.  Otherwise they would
> have rebuilt them for x86-64 by now.  Under this worldview, i386 is
> for backwards compatibility with existing software.  Users will want
> to run these old programs in a time namespace with shifted time, too.

I agree that changing the i386 port is probably a bad idea at the moment,
let's see how the armhf port turns out and fix all the bugs first, as this
is clearly needed anyway. Once there is a working armhf version with
full time64 user space, there can be a separate discussion about what
to do with the i386 port (phase out i386 before y2038, migrate all of
i386 to time64 quickly, have two separate i386 ports, or something
else).

  Arnd

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Mon, Feb 10, 2020 at 11:16 PM Florian Weimer  wrote:
>
> * Ben Hutchings:
>
> > On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> >> * Ben Hutchings:
> >>
> >> > 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.
> >>
> >> Is this a Debian-specific decision?
> >
> > I though that was the *upstream* decision, but perhaps that's still not
> > decided after all?
>
> There's going to be a _TIME_BITS selector, similar to
> _FILE_OFFSET_BITS.
>
> There was a proposal to have only one API before, but I think the
> agreement was that it wouldn't save much complexity.

It should be easy to force the _TIME_BITS selection by patching the
glibc headers in Debian though if we want.

The problem with setting _TIME_BITS=64 only using dpkg-buildflags
but leaving the libc default at 32 bits is that anything that users build
themselves or that ignores the buildflags ends up with a broken ABI
when linking against one of the many libraries that expose time_t
in their ABI.

 Arnd

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ben Hutchings:

> On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
>> * Ben Hutchings:
>> 
>> > 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.
>> 
>> Is this a Debian-specific decision?
>
> I though that was the *upstream* decision, but perhaps that's still not
> decided after all?

There's going to be a _TIME_BITS selector, similar to
_FILE_OFFSET_BITS.

There was a proposal to have only one API before, but I think the
agreement was that it wouldn't save much complexity.

Re: Y2038 - best way forward in Debian?

[Ben Hutchings]

On Sun, 2020-02-09 at 11:57 +0100, Florian Weimer wrote:
> * Ben Hutchings:
> 
> > 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.
> 
> Is this a Debian-specific decision?

I though that was the *upstream* decision, but perhaps that's still not
decided after all?

Ben.

> There has been a proposal upstream not to support 32-bit time_t for
> new applications at all, but I don't think we will go in that
> direction.
-- 
Ben Hutchings
The world is coming to an end.  Please log off.




signature.asc
Description: This is a digitally signed message part

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Ben Hutchings:

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

Is this a Debian-specific decision?

There has been a proposal upstream not to support 32-bit time_t for
new applications at all, but I don't think we will go in that
direction.

Re: Y2038 - best way forward in Debian?

[Stefan Monnier]

> My opinion (professional in this case, even) is that i386 users want
> compatibility with their binaries from 1998.

I don't claim to be representative, but at least the above doesn't fit
my case: I use i386 on many of my machines and here are the reasons:

- 2 of those machines use processors that don't support amd64 (a Pentium
  III for one and Core Duo for the other).

- For the other 4, the main reason is probably inertia, and the
  secondary reason is that I've found that I'm more affected by cache
  hit/miss (and swapping) than by speed of in-CPU operations, so i386
  gives me slightly higher performance (in those rare cases where I've
  measured it) because both code and data is more compact.

I suspect that none of my 2 non-amd64 machines will be in use by 2038.
And I see no reason why I'd want to "upgrade" to amd64 on the other
machines, but if that's what it takes to keep them running past 2038,
then that's probably what I'll do.


Stefan

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Sam Hartman:

> Steve, you're presuming that we would not create a new soname for libc6
> on architectures where we want a new time ABI.

That seems to be a reasonable assumption because Debian would have to
use a different soname from upstream.  glibc upstream does not seem
likely to change soname for this at this point.

Re: Y2038 - best way forward in Debian?

[Florian Weimer]

* Steve McIntyre:

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

XFS is the elephant in the room, though.

> glibc is the place that needs to care about most of this.

I'm not so sure.  I really do not want glibc to parse and rewrite
ioctl arguments and return values, or ancillary socket data.

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

With the exception of utmp/utmpx, see __WORDSIZE_TIME64_COMPAT32 in
the headers.  Unfortuantely, this also affects on-disk data
structures.

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

The question is whether anyone wants an i386 port where this has
happened.

My opinion (professional in this case, even) is that i386 users want
compatibility with their binaries from 1998.  Otherwise they would
have rebuilt them for x86-64 by now.  Under this worldview, i386 is
for backwards compatibility with existing software.  Users will want
to run these old programs in a time namespace with shifted time, too.

There is also substantial commercial interest in those old binaries
(which becomes apparent when you break glibc compatibility with them
8-/).

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

Yes, it really has to be B for i386 at least.

The other issue is that the Y2038 work has tentacles everywhere.
Porting to new architectures (whether they are 32-bit or 64-bit) will
require additional changes to those applications which make direct
system calls, in some cases even if they do not even use time_t or
struct timespec with those system calls at all.  For example, new
ports will not define __NR_futex, only __NR_futex_time64.

Re: Y2038 - best way forward in Debian?

[Wouter Verhelst]

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

Why not? This seems like the type of problem that SONAMEs are made for.
What am I missing?

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Y2038 - best way forward in Debian?

[Arnd Bergmann]

On Tue, Feb 4, 2020 at 4:03 PM Guillem Jover  wrote:
>
> On Tue, 2020-02-04 at 13:14:10 +, 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 

Re: Y2038 - best way forward in Debian?

[Sam Hartman]

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.

Re: Y2038 - best way forward in Debian?

[YunQiang Su]

Steve McIntyre  于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 

Re: Y2038 - best way forward in Debian?

[Steve Langasek]

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/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Y2038 - best way forward in Debian?

[Ben Hutchings]

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
Description: This is a digitally signed message part

Re: Y2038 - best way forward in Debian?

[Guillem Jover]

Hi!

On Tue, 2020-02-04 at 13:14:10 +, 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…


(Hmm there seems to be something borked with lintian.d.o, as the
general tag numbers seem extremely low. :)

Thanks,
Guillem

Re: Y2038 - best way forward in Debian?

[Lennart Sorensen]

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

Re: Y2038 - best way forward in Debian?

[Marco d'Itri]

On Feb 04, Steve McIntyre  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
Description: PGP signature

Re: Y2038 - best way forward in Debian?

[Stefan Monnier]

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


-- Stefan

Re: Y2038 - best way forward in Debian?

[Ansgar]

On Tue, 2020-02-04 at 13:14 +, 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