Bug#787853: lintian: Do not complain about lack of LFS from local implementations
On Wed, Jul 22, 2015 at 02:14:51PM +0200, Niels Thykier wrote:
Hi Sebastian,
Hi Niels,
Thanks for looking into this. :)
I got a few minor comments interleaved below:
np, updated patch attached.
Thanks,
~Niels
Sebastian
From fb8deee8e2fe3b26f68d137dd6c8bfca50a27fbc Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Date: Wed, 22 Jul 2015 13:06:28 +0200
Subject: [PATCH] binaries: limit LFS symbol checks to unresolved symbols
Guillem reported in BTS [0] that inetutils-ftpd is marked as
binary-file-built-without-LFS-support while it has LFS support. The
false-positive comes from a local symbol.
This patch limits the symbol checks to symbols which are unresolved
(i.e. not local, come from an external library) as suggested by Guillem.
Another (additional) limitation could be to limit the version to ^GLIBC_
as all the symbols for the LFS check come from GLIBC.
With this patch the inetutils-ftpd package is no longer marked with
binary-file-built-without-LFS-support while the havp package is still
marked.
[0] https://bugs.debian.org/787853
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
checks/binaries.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/checks/binaries.pm b/checks/binaries.pm
index 4b068dcd5c36..94197b603f29 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -152,9 +152,10 @@ sub run {
my ($foo, $sec, $sym) = @{$symbol};
unless (defined $has_lfs) {
-if ($LFS_SYMBOLS-known($sym)) {
+if ($foo eq 'UND' and $LFS_SYMBOLS-known($sym)) {
# Using a 32bit only interface call, some parts of the
-# binary are built without LFS.
+# binary are built without LFS. If the symbol is defined
+# within the binary then we ignore it
$has_lfs = 0;
}
}
--
2.1.4
Bug#787853: lintian: Do not complain about lack of LFS from local implementations
Control: tags -1 + patch
On 2015-06-05 19:17:07 [+0200], Guillem Jover wrote:
it should not. So I think that, to avoid false-positives, only undefined
symbols should be considered.
Added a patch for this. Another limition could be to look for symbols from
GLIBC. With what you suggested inetutils-ftpd gets off the list.
Thanks,
Guillem
Sebastian
From b5d7e4af568f87d22b62faa2b7f7f3a58837d389 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Date: Wed, 22 Jul 2015 13:06:28 +0200
Subject: [PATCH] binaries: limit LFS symbol checks to unresolved symbols
Guillem reported in BTS [0] that inetutils-ftpd is marked as
binary-file-built-without-LFS-support while it has LFS support. The
false-positive comes from a local symbol.
This patch limits the symbol checks to symbols which are unresolved
(i.e. not local, come from an external libary) as suggested by Guillem.
Another (additional) limitation could be to limit the version to ^GLIBC_
as all the symbols for the LFS check come from GLIBC.
With this patch the inetutils-ftpd package is no longer marked with
binary-file-built-without-LFS-support while havp is still marked.
[0] https://bugs.debian.org/787853
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
checks/binaries.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/checks/binaries.pm b/checks/binaries.pm
index 4b068dcd5c36..c22ed4bd1392 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -152,9 +152,10 @@ sub run {
my ($foo, $sec, $sym) = @{$symbol};
unless (defined $has_lfs) {
-if ($LFS_SYMBOLS-known($sym)) {
+if ($foo =~ /^UND$/ and $LFS_SYMBOLS-known($sym)) {
# Using a 32bit only interface call, some parts of the
-# binary are built without LFS.
+# binary are built without LFS. If the symbol is defined
+# within the binary then we ignore it
$has_lfs = 0;
}
}
--
2.1.4
Bug#787853: lintian: Do not complain about lack of LFS from local implementations
On 2015-07-22 13:20, Sebastian Andrzej Siewior wrote:
Control: tags -1 + patch
On 2015-06-05 19:17:07 [+0200], Guillem Jover wrote:
it should not. So I think that, to avoid false-positives, only undefined
symbols should be considered.
Added a patch for this. Another limition could be to look for symbols from
GLIBC. With what you suggested inetutils-ftpd gets off the list.
Thanks,
Guillem
Sebastian
0001-binaries-limit-LFS-symbol-checks-to-unresolved-symbo.patch
Hi Sebastian,
Thanks for looking into this. :)
I got a few minor comments interleaved below:
From b5d7e4af568f87d22b62faa2b7f7f3a58837d389 Mon Sep 17 00:00:00 2001
From: Sebastian Andrzej Siewior sebast...@breakpoint.cc
Date: Wed, 22 Jul 2015 13:06:28 +0200
Subject: [PATCH] binaries: limit LFS symbol checks to unresolved symbols
Guillem reported in BTS [0] that inetutils-ftpd is marked as
binary-file-built-without-LFS-support while it has LFS support. The
false-positive comes from a local symbol.
This patch limits the symbol checks to symbols which are unresolved
(i.e. not local, come from an external libary) as suggested by Guillem.
^^
s/libary/library/
Another (additional) limitation could be to limit the version to ^GLIBC_
as all the symbols for the LFS check come from GLIBC.
With this patch the inetutils-ftpd package is no longer marked with
binary-file-built-without-LFS-support while havp is still marked.
s/havp/have/
[0] https://bugs.debian.org/787853
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
checks/binaries.pm | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/checks/binaries.pm b/checks/binaries.pm
index 4b068dcd5c36..c22ed4bd1392 100644
--- a/checks/binaries.pm
+++ b/checks/binaries.pm
@@ -152,9 +152,10 @@ sub run {
my ($foo, $sec, $sym) = @{$symbol};
unless (defined $has_lfs) {
-if ($LFS_SYMBOLS-known($sym)) {
+if ($foo =~ /^UND$/ and $LFS_SYMBOLS-known($sym)) {
^^^
Given it is (currently) an exact equals, please use $foo eq 'UND' instead.
[...]
-- 2.1.4
Thanks,
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787853: lintian: Do not complain about lack of LFS from local implementations
On 2015-07-22 14:14, Niels Thykier wrote: [...] Another (additional) limitation could be to limit the version to ^GLIBC_ as all the symbols for the LFS check come from GLIBC. With this patch the inetutils-ftpd package is no longer marked with binary-file-built-without-LFS-support while havp is still marked. s/havp/have/ [...] Silly me, that was a package name and not a typo of have! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787853: lintian: Do not complain about lack of LFS from local implementations
Control: tags -1 pending On 2015-07-22 22:14, Sebastian Andrzej Siewior wrote: On Wed, Jul 22, 2015 at 02:14:51PM +0200, Niels Thykier wrote: Hi Sebastian, Hi Niels, Thanks for looking into this. :) I got a few minor comments interleaved below: np, updated patch attached. Thanks, ~Niels Sebastian Thanks! :) I have applied your patch to master and it will be a part of 2.5.35 (not to be confused with 2.5.34, which was uploaded ~50 minutes ago - sorry for the unfortunate timing here). Once again, thanks for the patch. ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787853: lintian: Do not complain about lack of LFS from local implementations
Package: lintian
Version: 2.5.31
Severity: wishlist
Tags: lfs
Hi!
I was checking the tags for inetutils when I noticed that inetutils-ftpd
is marked as binary-file-built-without-LFS-support, but only that binary
out of all binaries. The build system enables LFS, and the relevant files
include config.h before anything else.
So after that, my suspicion was that lintian might be detecting a tainted
symbol. And I remembered that gnulib provides its local implementation of
FTS, one that is compatible with LFS. objdump confirms that the local
symbols are visible, so it seems to me lintian is tripping on those.
Here's a small test case:
,---
#include stddef.h
#include sys/types.h
#include sys/stat.h
#include fts.h
#ifdef LOCAL_FTS
extern FTS *fts_open(char * const *paths, int flags,
int (*compar)(const FTSENT **, const FTSENT **)) { return NULL; }
extern int fts_close(FTS *fts) { return 0; }
#endif
int main() {
char *paths[] = { NULL };
FTS *fts = fts_open(paths, 0, NULL);
return fts_close(fts);
}
`---
By default (after stripping) it produces this «objdump -T» output:
,---
fts: file format elf32-i386
DYNAMIC SYMBOL TABLE:
DF *UND* GLIBC_2.0 fts_open
DF *UND* GLIBC_2.0 fts_close
w D *UND* __gmon_start__
DF *UND* GLIBC_2.0 __libc_start_main
0804850c gDO .rodata0004 Base_IO_stdin_used
`---
which should trigger the lintian tag. But when defining LOCAL_FTS:
,---
fts: file format elf32-i386
DYNAMIC SYMBOL TABLE:
w D *UND* __gmon_start__
DF *UND* GLIBC_2.0 __libc_start_main
0804840b gDF .text 000a Basefts_open
080484ec gDO .rodata0004 Base_IO_stdin_used
08048415 gDF .text 000a Basefts_close
`---
it should not. So I think that, to avoid false-positives, only undefined
symbols should be considered.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
