Control: tags -1 moreinfo
On Tue, 15 Jan 2019 15:43:31 +0000 Luca Boccassi <bl...@debian.org> wrote:
> Package: debhelper
> Version: 12
> Severity: normal
> Control: found -1 10.10.6
>
> Dear Maintainer,
>
> While changing build environment from Debian 9 to Debian 10, a package
> that does cross compilation now fails to run dh_strip.
> The debhelper compat level has not changed, it stayed at level 8.
>
Hi,
I am sorry to hear it breaks for you.
> The log says:
>
> DEB_HOST_GNU_TYPE=x86_64-w64-mingw32 dh_strip -Xi686-w64-mingw32
> Subroutine install_dir redefined at /usr/bin/dh_strip line 14.
> dh_strip: package objcopy is not in control info
> Use of uninitialized value $command in concatenation (.) or string at
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 2217.
> dh_strip: package strip is not in control info
> Use of uninitialized value $command in concatenation (.) or string at
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 2217.
> dh_strip: package objdump is not in control info
> Use of uninitialized value $command in concatenation (.) or string at
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 2217.
> dh_strip: Compatibility levels before 9 are deprecated (level 8 in use)
> x86_64-w64-mingw32- --strip-debug --remove-section=.comment
> --remove-section=.note
> debian/lzo-mingw-w64-x86-64-dev/usr/x86_64-w64-mingw32/lib/liblzo2.a
> Can't exec "x86_64-w64-mingw32-": No such file or directory at
> /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 475.
>
Please attach the full build log from this. In particularly, is this
from a clean *Debian* unstable or testing with "no funny monkey
business" (e.g. diverts or non-standard PATH with dh_strip being shadowed)?
I have seen some very weird cases where e.g. Ubuntu diverted and forked
part of debhelper. Unsurprisingly, it would occasionally break in
"funny" and weird ways. I would very much like to confirm quickly
whether we are dealing with stuff like that or a debhelper bug.
If needed by, try inserting the following into the build process (before
it fails):
grep cross_command $(which dh_strip)
I have a feeling it will say:
... cross_command("objcopy");
... cross_command("strip");
Rather than:
... cross_command($package, "objcopy");
... cross_command($package, "strip");
>
> The package (which builds 2 binary packages) is doing:
>
> override_dh_strip:
> DEB_HOST_GNU_TYPE=x86_64-w64-mingw32 dh_strip -Xi686-w64-mingw32
> DEB_HOST_GNU_TYPE=i686-w64-mingw32 dh_strip -Xx86_64-w64-mingw32
>
> I believe what's happening is that dh_strip now calls cross_command
> from the foreach $packages loop, but the "package" variable is empty
> and thus it calls cross_command( , "objcopy") which then, I think, perl
> squashes as package="objcopy", which then causes package_cross_type to
> print that error about control info, and then given $command is empty
> it just returns "-".
>
No, perl does not squash it like that when you have explicit variables.
I.e. cross_command if called like:
cross_command($package, '...');
will always put '...' in the second parameter of cross_command. Most
likely, the dh_strip on your build system does not match the version of
Dh_Lib.pm.
Not to mention that $package would then also be empty on a native build
and would have broken most of the Debian builds (indirectly via tmpdir
then being "debian/" rather than "debian/$package").
> Any suggestion? Adding -p does not seem to help, the same error happens
> (eg: ... dh_strip -pfoo ... dh_strip -pbar ...)
>
> --
> Kind regards,
> Luca Boccassi
Please try the checks I described above. At the moment, I strongly
suspect the build environment being the source of the error.
Thanks,
~Niels
