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 have
m4/largefile.m4 and m4/year2038.m4 from between 2012-07-02 and 2022-12-25.
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/largefile.m4;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=history;f=m4/year2038.m4;h=2e4427e6fac10550c99748abebf31b61e6afda2b;hb=b9bf95fd0a6ab666b484b1e224321664f051f7fa

https://git.savannah.gnu.org/cgit/gnulib.git/log/m4/largefile.m4?h=stable-202301

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

> 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)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204
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]: https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=7c7c8a519f3892f6f5b30a1c6b22796ab314a45c
> [2]: https://gitlab.com/gnutls/gnutls/-/commit/9622d7201e1d73d217c18802e1d435ba3404adb3

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):
https://wiki.debian.org/ReleaseGoals/64bit-time

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

Wookey
-- 
Principal hats:  Debian, Wookware, ARM
http://wookware.org/