Re: On time64 and Large File Support

2022-11-14 Thread Sam James
> On 12 Nov 2022, at 21:31, Paul Eggert wrote: > > On 2022-11-12 12:23, Wookey wrote: >> we can't just have everyone who enabled LFS sometime in the >> last 20 years suddenly being forced into the time_t change (can we?) > > We've done it in the past. > > AC_SYS_LARGEFILE originally was in Gn

Re: On time64 and Large File Support

2022-11-12 Thread Russ Allbery
Wookey writes: > Now, I'm not yet sure if just having autoconf 2.72 will actually break > things. AIUI, these changes only apply where LFS > (-D_FILE_OFFSET_BITS=64) is turned on, so in Debian at least, where that > is not the default on 32bit arches, maybe this is OK. But probably quite > a lot

Re: On time64 and Large File Support

2022-11-12 Thread Paul Eggert
On 2022-11-12 12:23, Wookey wrote: we can't just have everyone who enabled LFS sometime in the last 20 years suddenly being forced into the time_t change (can we?) We've done it in the past. AC_SYS_LARGEFILE originally was in Gnulib, before it migrated to Autoconf. Originally it affected only

Re: On time64 and Large File Support

2022-11-12 Thread Wookey
On 2022-11-12 11:15 -0800, Paul Eggert wrote: > On 2022-11-12 10:50, Bruno Haible wrote: > > I'm saying > > "tiny" because we are still 15 years away, and new releases of the (not > > many) affected packages are likely to come in the next 1-2 years. > > Not so "tiny", I'm afraid. My department is

Re: On time64 and Large File Support

2022-11-12 Thread Paul Eggert
On 2022-11-12 10:50, Bruno Haible wrote: I'm saying "tiny" because we are still 15 years away, and new releases of the (not many) affected packages are likely to come in the next 1-2 years. Not so "tiny", I'm afraid. My department is still running a server with libraries and executables that a

Re: On time64 and Large File Support

2022-11-12 Thread Bruno Haible
Paul Eggert wrote: > On 2022-11-12 06:16, Zack Weinberg wrote: > > I am going to go ahead and do this if nobody raises a concrete objection > > within the next 24 hours. > > I object to a simple reversion, as this will cause problems downstream > with Gnulib-using applications, several of which h

Re: On time64 and Large File Support

2022-11-12 Thread Paul Eggert
On 2022-11-11 18:20, Zack Weinberg wrote: I don’t think Paul considered the new behavior of AC_SYS_LARGEFILE to be overriding the glibc maintainers. Rather, I think he was only thinking about applications, not libraries, and only about source distribution. No, I was thinking about libraries as

Re: On time64 and Large File Support

2022-11-12 Thread Paul Eggert
On 2022-11-12 06:16, Zack Weinberg wrote: I am going to go ahead and do this if nobody raises a concrete objection within the next 24 hours. I object to a simple reversion, as this will cause problems downstream with Gnulib-using applications, several of which have already been released assum

Re: On time64 and Large File Support

2022-11-12 Thread Zack Weinberg
Sam James writes: >> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha >> wrote: >> I am honestly not sure what to do about this in the long term, but for >> the proposed “this weekend, just bugfixes” Autoconf 2.72, I do think it >> makes sense to back out change #2, only — that is, AC_SYS

Re: On time64 and Large File Support

2022-11-11 Thread Sam James
> On 12 Nov 2022, at 02:20, Zack Weinberg via Libc-alpha > wrote: > > Sam James writes: >>> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >>> We need to support legacy binaries on i386. Few libraries are >>> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >>> to LF

Re: On time64 and Large File Support

2022-11-11 Thread Zack Weinberg
Sam James writes: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> We need to support legacy binaries on i386. Few libraries are >> explicitly dual-ABI. Whether it's safe to switch libraries above glibc >> to LFS or time64 needs to be evaluated on a per-library basis. For most >> distribu

Re: On time64 and Large File Support

2022-11-11 Thread Paul Eggert
On 2022-11-11 03:38, Florian Weimer wrote: But that said, these binaries are broken anyway in 2038? No, I expect users to run them in time-shifted VMs or containers. That's reasonable for systems where accurate timestamps are not important and where time_t width mismatches would just get in t

Re: On time64 and Large File Support

2022-11-11 Thread Florian Weimer
* Sam James: >> On 11 Nov 2022, at 09:19, Florian Weimer wrote: >> >> * Sam James: >> >>> In Gentoo, we've been planning out what we should do for time64 on >>> glibc [0] and concluded that we need some support in glibc for a newer >>> option. I'll outline why below. >>> >>> Proposal: glibc ga

Re: On time64 and Large File Support

2022-11-11 Thread Sam James
> On 11 Nov 2022, at 09:19, Florian Weimer wrote: > > * Sam James: > >> In Gentoo, we've been planning out what we should do for time64 on >> glibc [0] and concluded that we need some support in glibc for a newer >> option. I'll outline why below. >> >> Proposal: glibc gains two new build-tim