Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I tried to upgrade system (apt-get upgrade), but it failed in dpkg: Unpacking initscripts (3.06-4) over (2.96-7+deb11u1) ... dpkg: error processing archive /var/cache/apt/archives/initscripts_3.06-4_all.deb (--unpack): unable to stat './var/log' (which was about to be installed): Value too large for defined data type stat /var/log File: /var/log Size: 4096 Blocks: 8 IO Block: 4096 directory Device: 8,1 Inode: 2752691 Links: 12 Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2040-05-10 23:31:40.285032309 +0200 Modify: 2023-10-25 16:03:42.313742411 +0200 Change: 2023-10-25 16:03:42.313742411 +0200 Birth: 2017-02-27 09:46:56.739719147 +0100 This date (2040) causes dpkg to fail. The workaround is correcting it by touch /var/log. Running system with bogus date (2040). * What exactly did you do (or not do) that was effective (or ineffective)? touch /var/log * What was the outcome of this action? dpkg started working * What outcome did you expect instead? dpkg should work with strange date or give a better message. Maybe just documentation (for stat) should be fixed and suggest problems with dates. Current outcome is as follows: apt-get suddenly fails with a cryptic message (initially it was "unable to stat '.'" instead of /var/log). It may be extremely difficult to diagnose the issue. *** End of the template - remove these template lines ***
Control: reassign -1 libc6
This is nothing to do with GLib (libglib2.0-0), but I assume you meant
glibc (libc6)? Quoting the rest of the bug report below for glibc
maintainers:
It is not possible for 32-bit stat() to work correctly on 32-bit systems
with dates beyond 2038, because the timestamp will not fit in the data
type used. The only solution would be for the program in question (in
this case, dpkg) to be compiled with support for 64-bit timestamps.
Your bug report seems to be from an upgrade from Debian 11 to Debian 12,
and Debian 11's glibc version did not support APIs that provide 64-bit
timestamps on 32-bit systems, so Debian 11's dpkg cannot support that
either.
Debian 12's glibc does, but that will only help you after fully upgrading
to Debian 12, at which point you will have Debian 12 versions of glibc
and dpkg.
Unfortunately, I don't think there's necessarily anything that can be done
here, beyond the general move towards supporting 64-bit timestamps
distribution-wide that is already in progress.
smcv
control: reassign -1 dpkg control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus Hi, I agree with the explanation. Yes, and that also means there is nothing that can be done on the glibc side as the API is already provided started with Debian 12. The other alternative is to add support at the dpkg level, just like it is already the case for some packages like coreutils. I am therefore reassigning the bug to dpkg, but I fully understand if it get tagged as wontfix until 64-bit timestamps are supported at the distribution-wide level. Regards Aurelien
Hi!
Right, I think this would be ideal, otherwise the entire port becomes
pretty useless if dpkg itself cannot even be used. There are several
things to take into account though:
- autoconf with the AC_SYS_YEAR2038 macro has not been released yet,
so I'll need to implement a replacement for that, which I guess I
might need to do anyway otherwise that would involve requiring a
too recent autoconf version.
- This could wait for the time64 transition, but then this will
leave the i386 port broken (as is supposed to be intended by
that transition), which means this report could not be solved,
but that seems less than ideal as I've mentioned before, because
that means the port is dead at that point. So…
- Building dpkg with time64 support *everywhere* could be a problem
when the shared libraries it uses or it might use in the future are
not also built with time64 support (the default for i386 based on
the proposed time64 plan in Debian). I've done a brief check over
all currently potentially used libraries and their public
interfaces:
+ libmd → ok (no types involving time)
+ libselinux → ok
+ libz → ok
+ libbz2 → ok
+ liblzma → ok
+ libzstd → ok
+ libps → Hurd library, might be a problem, need to check further
+ libsocket → Solaris library (not relevant in Debian)
+ libkvm → BSD library (not relevant in Debian, several BSDs
force-switched to time64 anyway)
+ libcurses → seems ok on a quick skim
And prospective ones:
+ libaudit → ok
+ libacl → ok
+ libcap → ok
- If none of these libraries get built with time64 on all 32-bit
arches (including i386), then dpkg might still fail due to
internal failures in those libraries.
So I guess once the first part is done I _could_ build dpkg with time64
on *all* 32-bit arches that support it (including i386), although if
(like it looks like) the ABIs for the listed shared libraries are not
affected by time64, then it might be way better to also build these
libraries everywhere with time64 anyway, because that should not affect
backwards compat for its current users, and if new symbols get added
with time types then those would not affect old binary programs that
people are concerned about, and would still make it safe to use the
libraries.
Thanks,
Guillem
Hi! Bug #1054552 in package dpkg reported by you has been fixed in the dpkg/dpkg.git Git repository. You can see the changelog below, and you can check the diff of the fix at: https://git.dpkg.org/cgit/dpkg/dpkg.git/diff/?id=028ceee7c --- build: Add AC_SYS_YEAR2038 support to configure Use the macro if autoconf supports it, otherwise fallback to the previous AC_SYS_LARGEFILE macro which is a subset. Closes: #1054552