Hi again, On 2015-06-07 23:22, Cyril Brulebois wrote: > Christian Kastner <deb...@kvr.at> (2015-06-07): >> Sorry for the delay, I was AFK until just now. >> >> I've prepared a quick upload consisting of only Matthias' patch, minus >> the superfluous d/shlibs.local as discussed in Michael's follow-up to >> the patch. >> >> I do still need a sponsor, though. For whomever is willing to act as >> such, a source package can be obtained from the following link, >> >> http://www.kvr.at/debian/pool/main/libc/libcap2/libcap2_2.24-9.dsc >> >> or, alternatively, via the git repo >> >> git://anonscm.debian.org/collab-maint/libcap2.git >> >> using gbp. >> >> Please let me know if there is anything else I can do. > > I've just tried to build your package, to rebuild systemd and d-i > afterwards but it failed with: > | dh_makeshlibs -plibcap2 --add-udeb=libcap2-udeb -- -c4 > | dpkg-gensymbols: warning: some new symbols appeared in the symbols file: > see diff output below > | dpkg-gensymbols: warning: debian/libcap2/DEBIAN/symbols doesn't match > completely debian/libcap2.symbols > | --- debian/libcap2.symbols (libcap2_1:2.24-9_amd64) > | +++ dpkg-gensymbols1MqufS 2015-06-07 23:13:54.633114251 +0200 > | @@ -1,4 +1,5 @@ > | libcap.so.2 libcap2 #MINVER# > | + __cap_lookup_name@Base 1:2.24-9 > | _cap_names@Base 1:2.10 > | _libcap_strdup@Base 1:2.10 > | cap_clear@Base 1:2.10 > | dh_makeshlibs: failing due to earlier errors > | debian/rules:50: recipe for target 'override_dh_makeshlibs' failed > > This doesn't happen with 1:2.24-8. Trying to build it a while ago led to > no warnings, but (re)building it now introduces this new symbol. > Probably due to some toolchain update (that I didn't investigate).
I looked into this and I can reproduce the issue. In one of the Makefiles, there's a test for the presence of gperf(1), and if so, stuff happens, and the above symbol eventually gets added. > Having -9 introduce the -c4 flag makes the warning become a fatal error, > since the default behaviour (level 1 in dpkg-gensymbols, called by > dh_makeshlibs) is warn only. > > It's somewhat fun to see how this function is constructed by the way. ;) Well put :-) > More seriously, I'm not sure it should be exposed in the shared library, > so you may want to unexpose it instead of just adding it to the symbols > file. With regards to the cause listed above, I'd rather just disable this "feature" entirely, and (possibly, if it makes sense) add gperf as a B-D at a later point, and then deal with the symbol as you recommend. Either way resolves the current nondeterminism in the build, which is at the moment what bothers me the most, TBH. Would you like me to prepare a 1:2.24-10 with such a fix ASAP (which would be tomorrow)? Or is the above info enough for you to deal with this issue for the moment? Regards, Christian -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5574beb2.3050...@kvr.at
