Thanks Niels,
Initially, I only updated to the backported dws, this was apparently not
enough, see below. As you suggested, I therefore created a script
dh_dwz, with contents "/usr/bin/dh_dwz --no-dwz-multifile $@" and
prepended the script path to my $PATH. This option works at least on
aarch64, and creates a debian package that is roughly factor 3 smaller.
Next, I installed both the newer dws and debhelper on both aarch64 and
armv7l using: sudo apt -t buster-backports install dwz debhelper
I removed my custom dh_dwz, cleaned all cached debhelper files, and
dpkg-buildpackage without problems. So, your backport suggestion works
on aarch64 and armv7l, and creates a debian package that is roughly
factor 3 smaller.
The fact that it worked on my PC is probably since ubuntu already
upgraded to the newer debhelper version 12.10ubuntu1 and dws version
0.13-5 without backports, my debian buster now uses debhelper Version:
13.3.3~bpo10+1 and dwz Version: 0.13-5~bpo10+1.
--
Met vriendelijke groet, kind regards,
Dennis Bijwaard
On 10/07/2021 06:30, Niels Thykier wrote:
Guillem Jover:
[...]
On Fri, 2021-07-09 at 08:52:18 +0000, Dennis Bijwaard wrote:
Package: dpkg-dev
Version: 1.19.7
Severity: normal
Dear all,
[...]
I found a work-around to at least create a package on these machines
using DEB_BUILD_OPTIONS=nostrip, but the package remains quite big. A regular
strip on the binaries does reduce them a bit, this could be an
alternative when dwz fails. Alternatively, it would be great if there
was an option to disable multifile option of dwz via e.g. DEB_BUILD_OPTIONS.
Or is there already an easy way to pass the --no-dwz-multifile option to
dh_dzw when invoked via dpkg-buildpackage?
Below is the trace of the failing dpkg-buildpackage.
Kind regards
Dennis
[...]
Hi Dennis,
From memory, this bug has been fixed in bullseye (the up coming version
of Debian). I urge you to retry with debhelper AND dwz from from
buster-backports[1] (or bullseye), which combined should solve this
issue for you on buster.
In most cases, it should be a "simple" matter of adding backports to
your sources list and updating the version constraints on debhelper in
the Build-Depends field of debian/control (debhelper from backports
depends on the backports version of dwz) plus restarting the build
process - including the part of installing build-dependencies.
If my starting points above are not sufficient guidance, then please
do consider asking for help in the #packaging IRC channel on
irc.debian.org with the details of your concrete situation.
If using backports (or bullseye) is not an option to you, then you can
deploy workarounds such as injecting a dwz in PATH that overrides the
default dwz or use the DH_EXTRA_ADDONS environment to load a custom
dh-addon that passes --no-dwz-multifile to dh_dwz.
There might be concrete challenges in how you need to deploy them. If
you are using a chroot (e.g., sbuild or pbuilder), you would have to
implement it _inside_ the chroot to have any effect (rather than
directly on your host system). Again, I recommend the #packaging
channel from irc.debian.org if my short starting points above are
insufficient.
Thanks,
~Niels
PS: I have recommended the #packaging channel since I assumed you were
building the deb without intention to upload it to the Debian archive.
If you are looking to upload it to the Debian archive, you should ask
in #debian-mentors instead. But if so, please be advised that all
packages for the Debian archive will be introduced via unstable and
people in #debian-mentors will ask you to first ensure that your package
builds in unstable rather than in stable(-backports).
[1]: https://backports.debian.org/
