Hello taffit, On Sat, Jan 28, 2023 at 12:10:53PM +0100, David Prévot wrote: > Hi, > > Le Wed, Jan 18, 2023 at 01:24:37AM +0100, Helge Deller a écrit : > > On Sat, 14 Jan 2023 20:38:38 +0100 Andreas Henriksson <andr...@fatal.se> > > wrote: > > > Here's a slightly different patch to implement basically the same thing > > > > Yes, I like this patch better too. > > Unfortunately, even if both patches allow me to build tar on i386, they > also both lead to an FTBFS on amd64.
Thanks for the feedback. I ran short on time when looking at this and tried to cheap out on just setting `-D_TIME_BITS=64` directly which causes problems. I generally have no clue when it comes to gnulib but I've now made an attempt at backporting the `year2038` gnulib module that upstream has enabled. I've pushed this here: https://salsa.debian.org/debian/tar/-/commits/wip/bug1026204 This time I've build-tested both on a sid amd64 chroot and a sid i386 chroot (on top of amd64). Maybe there's a better/cleaner way of doing this backport. I also have no idea if this impacts the output format of tar in any incompatible way, but hopefully it doesn't since upstream seems to now have it enabled by default in git atleast. Hopefully someone finds this useful... I'm not confident enough to actually upload this myself. Reviews welcome. Also note that the debian gnulib package seems to have the year2038 stuff in largefile.m4 already, so maybe it would be better to try to use that instead of the bundled m4 files in tar?!... (That should hopefully also sort out anyones worry about shipping generated (diff) files without source.) Regards, Andreas Henriksson
