Hi Adrian,
2016-10-22 0:05 GMT+02:00 Adrian Bunk <b...@stusta.de>: > On Sun, Sep 11, 2016 at 03:50:14PM +0200, Balint Reczey wrote: >> Source: deets >> Version: 0.2.1-4 >> Severity: important >> User: bal...@balintreczey.hu >> Usertags: pie-bindnow-20160906 >> Justification: FTBFS on amd64 with extra hardening >> >> Hi, >> >> During a rebuild of all packages in sid, your package failed to build on >> amd64 with patched GCC and dpkg. >> >> The rebuild tested if packages are ready for a transition >> enabling PIE and bindnow for amd64. >> >> For more information about the changes to sid's dpkg and GCC please >> visit: >> https://wiki.debian.org/Hardening/PIEByDefaultTransition >> >> Relevant part (hopefully): >> ... >> gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time -D_FORTIFY_SOURCE=2 >> -I/usr/include/lua5.1 -DDEETS_LUADIR=\" >> /usr/share/deets\" -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. >> -fstack-protector-strong -Wformat -Wer >> ror=format-security -c -o luau-luau.o `test -f 'luau.c' || echo '../'`luau.c >> ../luau.c: In function 'dpkg_status': >> ../luau.c:88:7: error: 'stat_notinstalled' undeclared (first use in this >> function) >> case stat_notinstalled: >>... > > This works for me in unstable, can you reproduce it? I can still reproduce it with the patch set I originally intended to use, in which pie is set by GCC and bindnow is set by dpkg. The patched binary packages are available from here: deb https://people.debian.org/~rbalint/ppa/pie-bindnow pie-bindnow-unstable/ I have updated the patches to revert setting bindnow from GCC. I still prefer this approach, as I wrote in my previous email: https://lists.debian.org/debian-release/2016/10/msg00356.html I think in the current situation the bug is valid, but not an RC one - however I would be surprised if Stretch were released with GCC setting bindnow instead of dpkg. Cheers, Balint > > I have already reproduced that #586572 would cause this kind og build > failure. > > Your log says: > checking for dpkg_set_progname in -ldpkg... no > checking for pkg_status_name in -ldpkg... no > > My log says: > checking for dpkg_set_progname in -ldpkg... yes > checking for pkg_status_name in -ldpkg... yes > > The part I do not understand is why it works for me since I would > have expected that to fail... > >> Thanks, >> Balint > > cu > Adrian > > -- > > "Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. > "Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed >
