Package: debian-installer
Version: 20140802
Severity: serious
Justification: FTBFS
Hi,
I've noticed what $Subject says through the daily builds. Looking at
last successful build and today's (failing) one, a few things pops up:
| -Unpacking libdebian-installer4-udeb (0.94) ...
| +Unpacking libdebian-installer4-udeb (0.95) ...
→ addition of ppc64el support, not likely to be an issue
| -Unpacking zlib1g-udeb (1:1.2.8.dfsg-1) ...
| +Unpacking zlib1g-udeb (1:1.2.8.dfsg-2) ...
→ irrelevant changes AFAICT
In the library reduction passes:
| -1052 symbols, 637 unresolved
| +1051 symbols, 636 unresolved
[…]
| -reducing libgcc_s.so.1
| -No pic file found for /lib/arm-linux-gnueabihf//libgcc_s.so.1 ; copying
[…]
| -Object: ./tmp/network-console/tree/lib/libgcc_s.so.1-so-stripped
[…]
| +1170 symbols, 38 unresolved
| +Traceback (most recent call last):
| + File "/usr/bin/mklibs", line 560, in <module>
| + raise Exception("No library provides non-weak %s" % name)
| +Exception: No library provides non-weak __aeabi_unwind_cpp_pr0
libgcc_s.so.1 comes from a gcc package, and there's been a gcc-4.9
package in unstable for 2 days, which might match. But then I don't
see any difference in package contents or symbols list for the
libgcc1 packages between 1:4.9.1-5 and 1:4.9.1-7. I'm afraid I'm
running out of the time to dig deeper into what's mklibs is after
(possibly a _pic.a but I don't see any for libgcc_s). Having both
a glibc and a gcc-4.9 upload in the said time window could explain
this regression, as a wild guess.
Could somebody from debian-arm@ (x-d-cc) check what's going on
precisely and possibly forward the failure to the right place if
d-i isn't the buggy package here?
Thanks for your time.
Mraw,
KiBi.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/20140818223422.17543.37141.report...@wodi.home.mraw.org
