Bug#874078: lintian: improve binary-file-built-without-LFS-support info field
Package: lintian
Version: 2.5.52
Severity: normal
Tags: patch lfs
Dear Maintainers,
CONTEXT:
Mpgrafic-0.3.15-1 is flagged with the binary-file-built-without-LFS-support
lintian
flag despite my attempts to follow the lintian recommendations, after having
searched for LFS info in obvious places:
https://lintian.debian.org/full/debian-astro-maintainers@lists.alioth.debian.org.html#mpgrafic
Discussion at this other lintian bug looks like it will solve the mpgrafic
LFS bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=871956
PROBLEM:
Version 2.5.52 of the binary-file-built-without-LFS-support section of
binaries.desc has two problems that make applying LFS support
corrections difficult for someone (such as me) who is not yet familiar
with LFS, AC_SYS_LARGEFILES and their portability:
(i) It says in one sentence that we must "ensure _FILE_OFFSET_BITS is
defined and set to 64", but in the following sentence that
"this can be done by using the AC_SYS_LARGEFILE macro with autoconf".
However, AC_SYS_LARGEFILE does not seem to define _FILE_OFFSET_BITS
on amd64, since it does not seem to be needed.
In other words, these two sentences are contradictory. Either lintian
should request everyone to hardwire everything with _FILE_OFFSET_BITS and
recommend *not* using AC_SYS_LARGEFILE, or it needs to indicate that
_FILE_OFFSET_BITS is not needed on all systems and that AC_SYS_LARGEFILE
can decide on which systems _FILE_OFFSET_BITS is needed.
(ii) I have not been able to find good documentation to give more
hints on functions that may need to be modified, or even better, on
functions that only need to be modified for some architectures
(pwrite, pread in the case of mpgrafic). So a brief comment in the
lintian info field could help improve the probability of people
responding to the warning rather than ignoring it.
I'm setting this as a normal level bug, because the aim of lintian
is not only to warn package maintainers, but also to help them
fix problems.
PATCH:
My proposed updated second paragraph is here:
To support large files, code review might be needed to make sure that
those files are not slurped into memory or mmap(2)ed, and that correct
64-bit data types are used (ex: off_t instead of ssize_t), etc. Once
that has been done ensure, if needed, that <tt>_FILE_OFFSET_BITS</tt>
is defined and
set to 64 before the relevant files are included. This can be done
conditionally by
using the <tt>AC_SYS_LARGEFILE</tt> macro with autoconf, or by appending
the output of <tt>getconf LFS_CFLAGS</tt> and <tt>getconf LFS_LDFLAGS</tt>
to <tt>CFLAGS</tt> and <tt>LDFLAGS</tt> respectively. Functions such
as pwrite and pread should be replaced by pwrite64 and pread64 in
cases where <tt>_FILE_OFFSET_BITS</tt> is defined and set to 64.
I'm also attaching it as a patch file.
Cheers
Boud
-- System Information:
Debian Release: buster/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
--- checks/binaries.desc.orig 2017-06-17 17:38:57.000000000 +0200
+++ checks/binaries.desc 2017-09-02 21:57:08.929153000 +0200
@@ -439,11 +439,15 @@
To support large files, code review might be needed to make sure that
those files are not slurped into memory or mmap(2)ed, and that correct
64-bit data types are used (ex: off_t instead of ssize_t), etc. Once
- that has been done ensure <tt>_FILE_OFFSET_BITS</tt> is defined and
- set to 64 before the relevant files are included. This can be done by
+ that has been done ensure, if needed, that <tt>_FILE_OFFSET_BITS</tt>
+ is defined and
+ set to 64 before the relevant files are included. This can be done
+ conditionally by
using the <tt>AC_SYS_LARGEFILE</tt> macro with autoconf, or by appending
the output of <tt>getconf LFS_CFLAGS</tt> and <tt>getconf LFS_LDFLAGS</tt>
- to <tt>CFLAGS</tt> and <tt>LDFLAGS</tt> respectively.
+ to <tt>CFLAGS</tt> and <tt>LDFLAGS</tt> respectively. Functions such
+ as pwrite and pread should be replaced by pwrite64 and pread64 in
+ cases where <tt>_FILE_OFFSET_BITS</tt> is defined and set to 64.
.
Take into account that even if this tag is not emitted, that does not
mean the binary is LFS-safe (ie. no OOM conditions, file truncation
Reply to: