On Fri, Mar 06, 2020 at 07:46:26AM +0100, Eduard Bloch wrote:
So, wouldn't a restart of the i386 architecture under a different name
give an excelent opportunity to get rid of many of such workarounds?
In theory, sure...but I don't see that there's any actual demand for a
new/clean i386
* Eduard Bloch:
> I vaguelly remember that glibc keeps collecting workarounds for replaced
> APIs all the time, adjusting binary compatibility with manually
> redirected symbols. Glibc folks might correct me, though.
>
> So, wouldn't a restart of the i386 architecture under a different name
>
Hallo,
* Steve McIntyre [Tue, Feb 04 2020, 01:14:10PM]:
> * 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
Arnd Bergmann wrote:
>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
On Tue, 2020-02-18 at 12:25 +0100, Marco d'Itri wrote:
> On Feb 17, Wouter Verhelst wrote:
>
> > - Figure out a way for 32-bit binary-only programs to keep working when
> > they touch a time_t beyond 2038.
> I am sure that around 2035 "time namespaces" or something similar will
> be
Simon Richter writes:
> On Tue, Feb 18, 2020 at 12:25:48PM +0100, Marco d'Itri wrote:
>> I am sure that around 2035 "time namespaces" or something similar will
>> be implemented to solve this.
> Hopefully a bit earlier. I have a few pieces of software that only build in
> virtual machines with
Hi,
On Tue, Feb 18, 2020 at 12:25:48PM +0100, Marco d'Itri wrote:
> > - Figure out a way for 32-bit binary-only programs to keep working when
> > they touch a time_t beyond 2038.
> I am sure that around 2035 "time namespaces" or something similar will
> be implemented to solve this.
On Feb 17, Wouter Verhelst wrote:
> - Figure out a way for 32-bit binary-only programs to keep working when
> they touch a time_t beyond 2038.
I am sure that around 2035 "time namespaces" or something similar will
be implemented to solve this.
--
ciao,
Marco
signature.asc
Description: PGP
On Mon, Feb 17, 2020 at 09:03:22AM +0100, Wouter Verhelst wrote:
>On Sat, Feb 15, 2020 at 11:41:32PM +, Steve McIntyre wrote:
>> Hey John,
>>
>> John Goarzen wrote:
>> >On Tue, Feb 04 2020, Steve McIntyre wrote:
>> >
>> >The thing that we have to remember is that an operating system is a
>>
On Sat, Feb 15, 2020 at 11:41:32PM +, Steve McIntyre wrote:
> Hey John,
>
> John Goarzen wrote:
> >On Tue, Feb 04 2020, Steve McIntyre 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:
>
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)
anth...@derobert.net wrote:
...
>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
Hey John,
John Goarzen wrote:
>On Tue, Feb 04 2020, Steve McIntyre 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
Adam Borowski wrote:
>On Wed, Feb 12, 2020 at 06:10:53PM +, Steve McIntyre wrote:
>>
>> /me ponders - this could be a fun task for a GSoC/outreachy student to
>> hack on, maybe?
>
>Prior art:
>
>* my unfinished https://github.com/kilobyte/crossgrade -- does a lot of
> error checking and
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
Steve McIntyre 于2020年2月14日周五 上午12:20写道：
>
> YunQiang Su wrote:
> >Ansgar 于2020年2月13日周四 下午5:29写道：
> >>
> >> For arm* and mips*, we mostly seem to be talking about special-purpose
> >> systems where just switching to a new architecture/port doesn't seem to
> >> be that much as a problem as for
On Thu, Feb 13, 2020 at 04:08:22PM +0100, Andrej Shadura wrote:
On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote:
just redefine time_t to 64bit may also cause a problem:
a bad designed and old network protocol which aims only target 32bit
system,
a binary data packet, may
On Thu, Feb 13, 2020 at 10:29:35AM +0100, Ansgar wrote:
For arm* and mips*, we mostly seem to be talking about special-purpose
systems where just switching to a new architecture/port doesn't seem to
be that much as a problem as for i386. I think rebuilding the world and
breaking ABI might thus
On Wed, Feb 12, 2020 at 06:10:53PM +, Steve McIntyre wrote:
> Russ Allbery wrote:
> >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
On Thu, Feb 13, 2020 at 05:40:29PM +0800, YunQiang Su wrote:
> just redefine time_t to 64bit may also cause a problem:
>a bad designed and old network protocol which aims only target 32bit
> system,
>a binary data packet, may contain time_t:
> struct {
> int a;
>
Andrej Shadura wrote:
>On Thu, 13 Feb 2020, 10:40 YunQiang Su, wrote:
>>
>> just redefine time_t to 64bit may also cause a problem:
>>a bad designed and old network protocol which aims only target 32bit
>> system,
>>a binary data packet, may contain time_t:
>> struct {
>>
YunQiang Su wrote:
>Ansgar 于2020年2月13日周四 下午5:29写道：
>>
>> For arm* and mips*, we mostly seem to be talking about special-purpose
>> systems where just switching to a new architecture/port doesn't seem to
>> be that much as a problem as for i386. I think rebuilding the world and
>> breaking ABI
Florian Weimer wrote:
>* Steve McIntyre:
>
>>>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.
>>
>> Hmmm.
* Steve McIntyre:
>>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.
>
> Hmmm. Moving ld.so is *hard* - we were
Ansgar 于2020年2月13日周四 下午5:29写道：
>
> Steve McIntyre writes:
> > wzss...@gmail.com wrote:
> >>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
Steve McIntyre writes:
> wzss...@gmail.com wrote:
>>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
On Wed, Feb 12, 2020 at 11:15 PM Steve McIntyre wrote:
> Simon McVittie wrote:
> >On Tue, 04 Feb 2020 at 13:14:10 +, 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
> >>
Hey Simon,
Simon McVittie wrote:
>On Tue, 04 Feb 2020 at 13:14:10 +, 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.
>
>Is
[ Skimming through this - Arnd already responded ... ]
Guillem Jover wrote:
>On Tue, 2020-02-04 at 13:14:10 +, 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
>>
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
Simon McVittie wrote:
>On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
>> Why not? This seems like the type of problem that SONAMEs are made for.
>> What am I missing?
>
>SONAMEs are set by the upstream developer in their build system (building
>the same source code produces the same
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.
>
>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
wzss...@gmail.com wrote:
>Steve McIntyre äº2020å¹´2æ4æ¥å¨äº ä¸å9:15åéï¼
...
>> 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,
Steve McIntyre wrote:
>Russ Allbery wrote:
>>
>>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
Russ Allbery wrote:
>Ansgar 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
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 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
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,
> >
* 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
* Michael Stone:
> On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
>>On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
>>> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
>>> > Why not? This seems like the type of problem that SONAMEs are made for.
>>>
* 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
Wouter Verhelst, le ven. 07 févr. 2020 14:46:19 +0200, a ecrit:
> On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> > On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > > Why not? This seems like the type of problem that SONAMEs are made for.
> > > What am I missing?
On Fri, Feb 07, 2020 at 02:46:19PM +0200, Wouter Verhelst wrote:
On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> Why not? This seems like the type of problem that SONAMEs are made for.
> What am I missing?
SONAMEs
On Fri, Feb 07, 2020 at 10:31:16AM +, Simon McVittie wrote:
> On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> > Why not? This seems like the type of problem that SONAMEs are made for.
> > What am I missing?
>
> SONAMEs are set by the upstream developer in their build system
On Tue, 04 Feb 2020 at 13:14:10 +, 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.
Is a list of affected/unaffected packages
On Fri, 07 Feb 2020 at 09:28:24 +0200, Wouter Verhelst wrote:
> Why not? This seems like the type of problem that SONAMEs are made for.
> What am I missing?
SONAMEs are set by the upstream developer in their build system (building
the same source code produces the same SONAME), and are
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
On Wed, 2020-02-05 at 15:35:28 +0100, Ansgar wrote:
> 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
On Wed, 2020-02-05 at 09:55 -0500, Sam Hartman wrote:
> > > > > > "Ansgar" == Ansgar 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
> "Ansgar" == Ansgar 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
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
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
Russ Allbery writes:
> Ansgar 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
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
Ansgar 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
Hi Colin,
On Tue, Feb 04, 2020 at 06:48:43PM +, 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.
>
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
On Tue, Feb 04, 2020 at 06:13:12PM +0100, Marco d'Itri wrote:
> On Feb 04, Guillem Jover 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
On Feb 04, Guillem Jover 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
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*
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 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
Hi Steve,
many thanks for this heads-up report!
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.
for being able to reproducibly rebuild more Debian
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
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
On Tue, Feb 04, 2020 at 01:14:10PM +, 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
Description: PGP signature
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
79 matches
Mail list logo
