[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: On time64 and Large File Support

From: Wookey
Subject: Re: On time64 and Large File Support
Date: Fri, 3 Mar 2023 14:01:35 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On 2023-03-02 21:50 -0800, Paul Eggert wrote:
> On 3/2/23 19:30, Wookey wrote:

> > Gnulib automatically changing the ABI for packages that use it
> > (and have LFS already enabled) is deeply unhelpful...

> This change to Gnulib was reverted in December[1] and that propagated into
> bleeding-edge GnuTLS last month[2]. So if I understand things correctly the
> next GnuTLS release will go back to the old way of doing things,

OK. gnulib doesn't seem to have releases as such (last release v0.1 9
years ago), and is normally used embedded in the upstream source like
autotools (right?). What is a good test for whether a package/upstream
is affected by this 'gnulib might have turned 64-bit time' issue? Is
there an embedded gnulib version one can check, or does one have to look
at dates of the m4/year2038.m4 and m4/largefile.m4 files in the source?

I've not properly analysed this yet but presumably the problem arises if you 
m4/largefile.m4 and m4/year2038.m4 from between 2012-07-02 and 2022-12-25.;a=history;f=m4/largefile.m4;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa;a=history;f=m4/year2038.m4;h=2e4427e6fac10550c99748abebf31b61e6afda2b;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa

> which will tempt the 32-bit time_t rearguard to fall back into
> "Let's not worry about 2038" mode.

Up to a point. I think enough people are taking notice now that those
who care will be getting at least the core of this transition done
this year. (Althought there will always be ancient bits of
unmaintained software that don't get fixed until it actually breaks in

> However this is just one package. We'll likely see similar issues with other
> packages, independently of whether they use Gnulib, and independently of
> whether the built packages are not supposed to be used after the year 2038.

Yep. I noticed tar changing in debian (which may not involve any
changing external interfaces so is hopefully OK, but I'm not sure the
maintainers really understood what they should be checking before flicking
the switch)
This will be the normal case (upstream see a test failure and just enable
the thing that makes the test work without necessarily understanding that
they are/might-be part of a chain of ABI changes).

> So this incident is a warning siren for the 32-bit time_t community. It's no
> time to relax.
> [1]: 
> [2]: 

I made this wiki page for Debian's transition (which still needs a
proper community discussion to agree a plan - I'm currently trying to
collect the info needed for that discussion to be productive):

I will update it with this gnulib info once I understand it properly.

Principal hats:  Debian, Wookware, ARM

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]