block 689093 by 696390 thanks On Thu, Dec 20, 2012 at 12:37:42AM +0100, Kurt Roeckx wrote: > On Wed, Dec 19, 2012 at 01:16:16PM +0000, Colin Watson wrote: > > This test (which I ran against current unstable) behaves *much* better. > > Out of 413 packages, 402 built cleanly. Two packages (eucalyptus and > > freebsd-utils) were skipped because my test was on i386 and they don't > > build there. chromium-browser failed to unpack for some odd reason, > > unrelated to OpenSSL. Of the remaining eight failures: > > Can you also verify that for those 402 that it has at least 1 > binary package depending on libssl1?
Thanks for suggesting this. Some don't: 389-ds-base aeskulap apcupsd asio autofs chntpw cmtk dicomscope eagle fwbuilder gambas3 gnome-commander gst-plugins-bad1.0 guymager handlersocket havp htcheck ifstat inspircd isc-dhcp iscsitarget kde4libs kdesvn libapache-mod-log-sql libfprint libgwenhywfar libyahoo2 mcabber mysql++ ntp openclonk opensaml2 openswan pam-mysql postgis postgresql-8.4 pygresql qpid-cpp qt4-x11 quassel quota racket rhash shibboleth-sp2 ssldump subcommander telepathy-rakia valknut vdr-plugin-live vidalia vmtk wzdftpd I ran 'grep-aptavail -XFSource:Package "$x" | grep libssl1' on each of these. Most are false positives in that they don't have any libssl dependencies in unstable either: I guess they're indirect dependencies, redundant build-dependencies, or build-dependencies for build tools that don't actually end up in the package. rhash has a Recommends instead of a Depends. Looking through the logs manually as an extra sanity-check, the following packages don't appear to even try to link against libssl or libcrypto directly, and none of them observably fail to detect OpenSSL (some don't seem to try at all; some try but then use something else such as GnuTLS instead; a few seem to use the headers but rely on something else for indirect linkage; some obscure their link lines so it's hard to tell but seems harmless): aeskulap apcupsd autofs chntpw cmtk eagle fwbuilder gambas3 gnome-commander gst-plugins-bad1.0 guymager handlersocket havp htcheck ifstat inspircd isc-dhcp iscsitarget kde4libs kdesvn libapache-mod-log-sql mcabber mysql++ openclonk opensaml2 openswan pam-mysql postgis postgresql-8.4 pygresql quassel quota racket shibboleth-sp2 subcommander telepathy-rakia valknut vdr-plugin-live vidalia vmtk wzdftpd The following use -lssl or -lcrypto in link lines but don't end up with dependencies on libssl1.0.0 (so presumably indirect linkage or unshipped binaries): 389-ds-base asio dicomscope libfprint libyahoo2 qpid-cpp qt4-x11 uses the OpenSSL headers, apparently successfully, but relies on run-time linking. libgwenhywfar and ssldump already fail to detect OpenSSL, but those are due to buggy library tests and have nothing to do with headers. The one case that's a real problem is ntp, which does indeed misbuild because it fails to detect OpenSSL headers. I've filed a bug for this with a patch (#696390). -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
