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)
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
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
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
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
* 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
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
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
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
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
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,
> >
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
* 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.
>>
>>
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
* 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
> 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
* 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
* 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
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
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
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
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
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
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
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
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*
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
> * 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
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
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
30 matches
Mail list logo
