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/
Attachment:
signature.asc
Description: PGP signature
