Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi, On Mon, Mar 30, 2020 at 6:07 PM Jiri Palecek wrote: > > Yeah and it's (slightly?) wrong in using of the negative assertions. I thought I also changed some when importing xdeb. Which are wrong, please? > Maybe another time. Let's take care of it now! Kind regards Felix Lechner
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi On 30. 03. 20 16:14, Felix Lechner wrote: Thanks for being persistent. It made my work a lot easier. I totally agree with you. I will remove the xdeb check in the near future. That's nice to hear! Thank you. I will only keep the test, which is slightly different from t/tags/checks/binaries/binaries-from-other-arch. It actually builds a cross-binary, even if the arch-dependent build prerequisite is not in d/control (so our Gitlab CI is not burdened all the time). https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex That table was apparently imported from xdeb at some point. Yeah and it's (slightly?) wrong in using of the negative assertions. Maybe another time. Have a nice day Jiri Palecek
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi Jiri, On Mon, Mar 30, 2020 at 5:54 AM Jiri Palecek wrote: > > That's good; however, I'd like to know why is that tag even needed > in lintian, and if removing that altogether wouldn't be the best course > of action. Especially given that lintian already has a tag for the very > same check, but with some multilib issues solved and more: Thanks for being persistent. It made my work a lot easier. I totally agree with you. I will remove the xdeb check in the near future. I will only keep the test, which is slightly different from t/tags/checks/binaries/binaries-from-other-arch. It actually builds a cross-binary, even if the arch-dependent build prerequisite is not in d/control (so our Gitlab CI is not burdened all the time). > https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex That table was apparently imported from xdeb at some point. Kind regards Felix Lechner
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi, On 29. 03. 20 18:53, Felix Lechner wrote: positives. Your issue should be fixed on all architectures (or at least I hope) with this commit: https://salsa.debian.org/lintian/lintian/-/commit/53fd192e6cc0f2cd6028f659ae1c30888bf94872 The issues surrounding multilib and cross building tools remain. Keeping the bug open. That's good; however, I'd like to know why is that tag even needed in lintian, and if removing that altogether wouldn't be the best course of action. Especially given that lintian already has a tag for the very same check, but with some multilib issues solved and more: https://salsa.debian.org/lintian/lintian/-/blob/40a028318ae647034ac35f900c119f922ca1b638/data/binaries/arch-regex https://salsa.debian.org/lintian/lintian/-/blob/master/checks/binaries.pm#L405 Maybe if you're concerned about some particular false negative of|binary-from-other-architecture|, you could work with that. Regards Jiri Palecek
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi Andreas, On Wed, Mar 25, 2020 at 6:27 AM Andreas Beckmann wrote: > > I also get these while testing an i386 .deb on an amd64 host. Thank you for this pointer. It was most helpful for many false positives. Your issue should be fixed on all architectures (or at least I hope) with this commit: https://salsa.debian.org/lintian/lintian/-/commit/53fd192e6cc0f2cd6028f659ae1c30888bf94872 The issues surrounding multilib and cross building tools remain. Keeping the bug open. Kind regards Felix Lechner
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
On 3/25/20 3:11 PM, Felix Lechner wrote: > Hi, > > On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote: >> >> I don't know when that was introduced, but you see some hundred of those in >> the >> gcc-N packages: > > The tag was introduced when the sole Lintian check provided by the > xdeb package became part of Lintian. Given recent changes, it was too > cumbersome to keep filing bug reports [1] and merge requests [2] for > dependent packages. The relevant commit was: > > > https://salsa.debian.org/lintian/lintian/-/commit/25013ff8173883796e00f4bc58a89f2a09839727 > >> E: libx32gcc-9-dev: >> ESC]8;;https://lintian.debian.org/tags/binary-is-wrong-architecture.htmlESC\binary-is-wrong-architectureESC]8;;ESC\ >> usr/lib/gcc/x86_64-linux-gnu/9/x32/crtend.o > > For your package, it is clearly wrong to use the host as an indicator > for the intended binary architecture. Package names are a last resort; > can we use the file path, i.e. /usr/lib/gcc/$triplet/\d+/$target? there are different locations: For native compilers: lib32gcc-8-dev: usr/lib/gcc/$(DEB_HOST_GNU_TYPE)/N/32*.a lib32gcc-s1: usr/lib/$(DEB_HOST_MULTIARCH)/lib*.so.* For cross compilers: usr/ Kind regards > Felix Lechner > > [1] e.g. #939171, #951669 > [2] e.g. > https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/-/merge_requests/10 >
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
On Wed, 25 Mar 2020 07:11:02 -0700 Felix Lechner wrote:
> Hi,
Hello,
>
> On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote:
> >
> > I don't know when that was introduced, but you see some hundred of
those in the
> > gcc-N packages:
>
> The tag was introduced when the sole Lintian check provided by the
> xdeb package became part of Lintian. Given recent changes, it was too
> cumbersome to keep filing bug reports [1] and merge requests [2] for
> dependent packages. The relevant commit was:
>
>
https://salsa.debian.org/lintian/lintian/-/commit/25013ff8173883796e00f4bc58a89f2a09839727
>
This is the problem:
$self->tag('binary-is-wrong-architecture', $file)
if ( $architecture =~ /^arm[el|hf]$/
&& $file->file_info !~ /ARM,(?: EABI5)? version 1 \(SYSV\)/)
|| ( $architecture eq 'i386'
&& $file->file_info !~ /x86-64, version 1 \(SYSV\)/)
If architecture is i386 (OK, mine is), but file info DOESN'T indicate
x86-64 (yes, 386 binaries don't), we tag the package. That can't be
right; I don't want x86-64 files on a 386 system. And I want 386
binaries instead. Please fix that.
As an aside, why is that test even necessary? The next line (... !~
$pattern) should work fine for i386.
Regards
Jiri Palecek
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Hi, On Sat, Mar 21, 2020 at 4:51 AM Matthias Klose wrote: > > I don't know when that was introduced, but you see some hundred of those in > the > gcc-N packages: The tag was introduced when the sole Lintian check provided by the xdeb package became part of Lintian. Given recent changes, it was too cumbersome to keep filing bug reports [1] and merge requests [2] for dependent packages. The relevant commit was: https://salsa.debian.org/lintian/lintian/-/commit/25013ff8173883796e00f4bc58a89f2a09839727 > E: libx32gcc-9-dev: > ESC]8;;https://lintian.debian.org/tags/binary-is-wrong-architecture.htmlESC\binary-is-wrong-architectureESC]8;;ESC\ > usr/lib/gcc/x86_64-linux-gnu/9/x32/crtend.o For your package, it is clearly wrong to use the host as an indicator for the intended binary architecture. Package names are a last resort; can we use the file path, i.e. /usr/lib/gcc/$triplet/\d+/$target? Kind regards Felix Lechner [1] e.g. #939171, #951669 [2] e.g. https://salsa.debian.org/perl-team/modules/packages/pkg-perl-tools/-/merge_requests/10
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Followup-For: Bug #954415 Control: found -1 2.57.0 I also get these while testing an i386 .deb on an amd64 host. This is a regression introduced after the 2.55.0 release. Andreas
Bug#954415: hundreds of wrong binary-is-wrong-architecture warnings
Package: lintian I don't know when that was introduced, but you see some hundred of those in the gcc-N packages: E: libx32gcc-9-dev: ESC]8;;https://lintian.debian.org/tags/binary-is-wrong-architecture.htmlESC\binary-is-wrong-architectureESC]8;;ESC\ usr/lib/gcc/x86_64-linux-gnu/9/x32/crtend.o So either you ignore those for multilib packages, or you deduce the architecture from the package name and check for the architecture. Note however that gcc and glibc have different naming schemas for multilib packages.
