Control: tags -1 unreproducible moreinfo Tino Mettler: > Package: debhelper > Version: 10.2.2 > Severity: normal > > Dear Maintainer, > > I tried to use the xca-dbgsym package and discovered that it contained the > wrong symbols. The package uses a simple rules file that invokes all > default dh_* steps. > > I analysed it in a chroot and came to the following conclusion: > > 1. the build ID of the xca binary (the only binary in the package) is > 736a4c65440b1dcfa898ca95a236c273dba8f06f > > 2. dh_strip created > /usr/lib/debug/.build-id/04/a18d979aaa63ae0f23ecf5578b59b4369c29eb.debug > > 3. there is a binary called xca_db_stat in the build which is not contained > in the binary package, but this binary has the build ID > 04a18d979aaa63ae0f23ecf5578b59b4369c29eb > > It looks like dh_strip uses the wrong binary for extracting the debug > symbols. > > [...]
Hi Tino, I just tried to reproduce this bug without success (amd64 using debhelper/10.2.3, dpkg-buildpackage -b). Admittedly, I stopped at the dh_strip call and ran dh_strip manually (so I could add -v and see what it was doing). I end up with *two* dbgsyms - one from xca and one from xca_db_stat. Both of which are in debian/xca/usr/bin/ at the time when dh_strip is called. AFAICT, dh_strip is doing the right thing on xca and I see no relevant changes in debhelper 10.2.2 -> 10.2.3 that can explain why 10.2.3 "should have fixed" this bug. If you can still reproduce the issue, please provide the output of dh_strip -v [other arguments you use]. Keep in mind that dh_strip is a "destructive" operation, so you cannot just run it post build with -v. Thanks, ~Niels
