control: reassign -1 dpkg control: retitle -1 dpkg: stat fails on 32-bit systems when access time is bogus
Hi, On 2023-10-25 23:29, Simon McVittie wrote: > Control: reassign -1 libc6 > > 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 > > 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: > > > 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. > > 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. 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. > 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. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
