Subject: tar: ftbfs with recent glibc

From: John David Anglin <[email-masked]>
Date: Fri, 16 Dec 2022 20:45:19 +0000

Source: libc6
Version: 2.36-6
Severity: normal

Dear Maintainer,

See the following BZ for tar:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026204

__USE_TIME_BITS64 now needs to be defined on most 32-bit
architectures to build tar even when _FILE_OFFSET_BITS=64
is selected. The folowing error occurs from glibc:
+tar: dir/f2038-01-19T03\:14\:08.9: Cannot stat: Value too large for defined data type

The following two commits changed the handling of file times:

commit dd4131c8322891a0ad7cfb661efa41aecc02b581
Author: Aurelien Jarno <[email-masked]>
Date:   Tue Nov 1 20:43:55 2022 +0100

    linux: Fix fstatat on MIPSn64 (BZ #29730)

    Commit 6e8a0aac2f883 ("time: Fix overflow itimer tests on 32-bit
    systems") changed in_time_t_range to assume a 32-bit time_t. This broke
    fstatat on MIPSn64 that was using it with a 64-bit time_t due to
    difference between stat and stat64. This commit fix that by adding a
    MIPSn64 specific version, which bypasses the EOVERFLOW tests.

    Resolves: BZ #29730

    Reviewed-by: Adhemerval Zanella  <[email-masked]>
    (cherry picked from commit 7457b7eef8dfe8cc48e55b9f9837df6dd397b80d)

commit 7b7dfbb0cbdffebf0233c650627a4861212fbb60
Author: Adhemerval Zanella <[email-masked]>
Date:   Wed Oct 19 19:14:04 2022 -0300

    linux: Fix generic struct_stat for 64 bit time (BZ# 29657)

    The generic Linux struct_stat misses the conditionals to use
    bits/struct_stat_time64_helper.h in the __USE_TIME_BITS64 for
    architecture that uses __TIMESIZE == 32 (currently csky and nios2).

    Since newer ports should not support 32 bit time_t, the generic
    implementation should be used as default.

    For arm, hppa, and sh a copy of default struct_stat is added,
    while for csky and nios a new one based on generic is used, along
    with conditionals to use bits/struct_stat_time64_helper.h.

    The default struct_stat is also replaced with the generic one.

    Checked on aarch64-linux-gnu and arm-linux-gnueabihf.

    (cherry picked from commit 7a6ca82f8007ddbd43e2b8fce806ba7101ee47f5)

I think __USE_TIME_BITS64 should be defined when _FILE_OFFSET_BITS==64
This would avoid the overflow converting tv_sec from 64 to 32 bits.

Regards,
Dave

-- System Information:
Debian Release: bookworm/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 6.0.12 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-- debconf information excluded

---

From: Florian Weimer <[email-masked]>
Date: Fri, 16 Dec 2022 22:24:29 +0100

> This would avoid the overflow converting tv_sec from 64 to 32 bits.

It's an ABI break.  You probably can enable it in the tar build safely
because it's not a library.  But doing it by default across the
distribution is difficult because it changes the meaning of time_t in
header files.

Thanks,
Florian

---

From: John David Anglin <[email-masked]>
Date: Fri, 16 Dec 2022 16:38:01 -0500

> distribution is difficult because it changes the meaning of time_t in
But it seems we already have an ABI break since tar built before the recent glibc changes.

Regards,
Dave

-- 
John David Anglin  [email-masked]

---

From: Florian Weimer <[email-masked]>
Date: Fri, 16 Dec 2022 23:33:43 +0100

> But it seems we already have an ABI break since tar built before the

No, not an ABI break.  A regression.  I suspect the glibc bugfix exposed
that the tar test was failing all along.

Thanks,
Florian

---

From: John David Anglin <[email-masked]>
Date: Fri, 16 Dec 2022 17:42:49 -0500

> that the tar test was failing all along.
If we are sure that the glibc bugfix just exposed the tar problem, then this issue can be closed.

Dave