On Wed, Jan 11, 2017 at 03:05:45PM +0100, Fabian Grünbichler wrote: > AFAIK the situation regarding OpenSSL in Sid/Stretch is rather > complicated - upstream / the OpenSSL maintainers / .. are pushing for a > transition to 1.1.0 (currently 1.1.0c), but there was quite a backlash > from various maintainers because of the ABI breakage and not-yet-updated > upstreams. Now there are two -dev packages, libssl-dev (previously > 1.0.X, now 1.1.0c) and libssl1.0-dev and a boatload of bug reports and > patches for various packages to transition to 1.1.0 in a backwards > compatible way. Whether the move to 1.1.0 for Stretch will really happen > was unclear the last time I checked, but that was some time in December > (or maybe even November?). You can check the debian-devel archives if > you are in the mood for reading long back and forth threads ;) Hehe, ok, thanks for the details, I think I'll skip the mailing list archives ;) > > Anyhow, the spice client packages in Debian Stretch are still compiled > against libssl1.0-dev (which is 1.0.2j-4), the ones in Debian Sid are > compiled against libssl-dev (which is 1.1.0c-2). > > > > > I assume you are getting the same results if you use --spice-ca-file > > instead of .spicec/spice_truststore.pem? > > By any chance, would it be possible for you to try the latest version of > > these patches rather than what they have in debian, as they are a bit > > different at this point? > > > > Compiling the current spice-gtk master with v2 of this patch set > > - against libssl-dev on Sid works as expected > - against libssl1.0-dev on Sid works as expected (which matches with > your result) > > Compiling the current spice-gtk master without the patch set > - against libssl-dev on Sid does not work (hence the patch set ;)) > - against libssl1.0-dev on Sid works as expected > > Replacing the old patch in Debian Sid's source package with v2 of this > patch set and rebuilding also works as expected. I'll open a bug report > on the Debian side to get the current patch set included in the Debian > package, unless there are any objections (or an upcoming v3) from your > side? I think the current iteration should be fine, especially with the additional testing you just did ;) Thanks for the investigation and getting to the bottom of it! Christophe
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel