Hi, Thanks for the pointers. But I think I'm not able to fix it even if I tried to diagnose the debug information.
ATM I asked several people and it is likely that the dwz error stems from toolchain support problem. Now the build log on non-release archivectures are also available, and it seems that nearly all these non-release architectures (kind of) suffer from similar prblem. Temporarily overriding dh_dwz to noop it is an eligible solution to me. Another solution could be simply downgrading dh compat back to 11. On Sat, Jan 12, 2019 at 04:10:02PM +0000, Rebecca N. Palmer wrote: > I suspect this is caused by bumping debhelper compat (while often a good > idea, this is intentionally *not* risk-free, which is why it requires > explicit action), but I haven't actually tried fixing it by reverting this. > > codesearch finds that message in dwz: > https://sources.debian.org/src/dwz/0.12-3/dwz.c/?hl=1016#L1016 > > dwz was added to the standard dh sequence in compat 12: > https://sources.debian.org/src/debhelper/12/debhelper.pod/#L860 > > As it seems to relate to debug information, it might be a good idea to test > whether that works: > # apt-get install libsleef3-dbgsym > $ gdb --args <executable (not script) that uses libsleef3> > (gdb) break <somewhere in the sleef source, in file.c:123 format> > (gdb) run > [wait for "hit Breakpoint", or if it's a program that spends most of its > time in sleef, press Ctrl+C] > (gdb) bt full > [should show source line numbers and parameter values, i.e. like #909379 not > #914021]