#include <hallo.h> Christian Kastner <deb...@kvr.at> (2015-06-07): > 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.
Yeah, and that tool is indeed present in the devel chroot I used to build systemd in recently. ;) > 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. I'm obviously biased as in: I'd like to get d-i buildable again ASAP, but I don't feel like this gperf issue has to be tackled right now; it wouldn't be a regression from -8, so I'm happy if it can wait a little. Once the upcoming upload reaches testing, having gperf entirely disabled or properly enabled (build-dep + symbols handling) looks fine. > 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? I've just checked that (baring apt install/purge gperf where needed) I'm able to build libcap2, upgrade the relevant packages, build systemd and get installable udebs (case in point: libudev1-udeb). I wouldn't call the dependencies correct though, as it only depends on libcap2, without any version. We tend to use the -V'libfoo (>= minver)' syntax, which allows to get proper shlibs (version for both libfoo and its udeb), while still letting symbols take precedence for the library. Here's the generated shlibs with your .dsc: libcap 2 libcap2 udeb: libcap 2 libcap2-udeb And with this extra dh_makeshlibs flag: -V'libcap2 (>= 1:2.10) libcap 2 libcap2 (>= 1:2.10) udeb: libcap 2 libcap2-udeb (>= 1:2.10) Let's compare dependencies, yours: Depends: libc6-udeb (>= 2.19), libcap2-udeb and mine: Depends: libc6-udeb (>= 2.19), libcap2-udeb (>= 1:2.10) But I didn't play with other libcap2 reverse dependencies to make sure there's no changes for libraries there. I've also re-checked that d-i still builds correctly (phew!) with this flag, libcap2 and systemd rebuilt. Long story short: the source package you published is good enough to unstuck the dependency issues, but it would probably be a good idea to fix that properly, adding the -Vfoo flag. Disabling gperf support for the time being can either be done right now if someone has a patch handy, or in a later revision. Mraw, KiBi.
signature.asc
Description: Digital signature
