Hi!
On Thu, 2023-10-26 at 19:27:48 +0200, Aurelien Jarno wrote:
control: reassign -1 dpkg
control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus
On 2023-10-25 23:29, Simon McVittie wrote:
On Wed, 25 Oct 2023 at 20:53:57 +0200, Jarek Czekalski wrote:
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.
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.
I agree with the explanation.
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.
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.
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)