Hi! Our Large File Support on some 32-bit architectures is a bit poor, and this has been going on for a while now:
<https://lintian.debian.org/tags/binary-file-built-without-LFS-support.html> (Although this includes some false-positives as reported in #787853.) In addition, the problem is actually worse than it seems, because even programs that might not need nor usually have to read and handle large files, might still fail, if they have to operate on files with large metadata values, like inode numbers for example. A simple stat(2) on a file might fail on a filesystem with large inode numbers, even if the file is otherwise not large. (I've filed #792167 to clarify the above in the lintian tag description.) If you've got one such package please consider enabling LFS, and if you maintain a shared library that might need to bump its SONAME soon, for example due to the gcc-5 transition, please use the opportunity to also try to enable LFS at the same time. Shared libraries might not break the ABI when enabling LFS, but doing so when bumping the SONAME means even if they would break the ABI, it will be fine. This still will not guarantee that LFS works, as an underlying shared library might still not have LFS enabled, or any of the other problems listed in the lintian tag might remain, but it's better than nothing I guess. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150712173723.ga29...@gaara.hadrons.org