tag: hppa, lfs, patch This bug usually indicates that a 32-bit application uses functions like readdir() which (by default on a 32bit platform) can only handle 32-bit values for inode numbers. You can overcome that issue by recompiling the code while providing "-D_FILE_OFFSET_BITS=64" on the gcc command line.
In this specific case I suggest to add the "future=+lfs" option to debian/rules like this (copy/pasted here - may not apply cleanly but you get the idea): --- debian/rules 2022-12-13 17:30:09.631676544 +0000 +++ debian/rules.org 2022-12-13 17:56:43.086922122 +0000 @@ -14,9 +14,9 @@ # Workaround an issue with PIC/PIE on certain architectures (c.f., #942798) ifneq (,$(filter x32,$(DEB_HOST_ARCH))) + DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie future=+lfs - DEB_BUILD_MAINT_OPTIONS=hardening=+all,-pie else + DEB_BUILD_MAINT_OPTIONS=hardening=+all future=+lfs - DEB_BUILD_MAINT_OPTIONS=hardening=+all endif This option enables large file support (LFS) generally. On 64-bit platforms the aove future-flag is a no-op. By the way, I think you couldn't reproduce the issue on i386, because you probably didn't used a huge hard disc there. The issue only arises sometimes if the searched/read file is above the 32-bit boundary on disc. Dear subversion maintainers: Please add the future option. (I noticed that bug too, because for me "git" package failed to compile, because it uses subversions in it's tests and subversion there ran into this "Value too large" problem.) Helge
