On 05/29/2017 03:15 AM, Eric Dorland wrote: > * Julien Cristau (jcris...@debian.org) wrote: >> On Mon, May 22, 2017 at 03:42:57 +0000, Eric Dorland wrote: >> >>> tag 846548 pending >>> thanks >>> >>> Hello, >>> >>> Bug #846548 reported by you has been fixed in the Git repository. You can >>> see the changelog below, and you can check the diff of the fix at: >>> >>> https://anonscm.debian.org/cgit/pkg-opensc/libp11.git/commit/?id=e8d6da0 >>> >> So, erm. This seems like it would break using libengine-pkcs11-openssl >> in an application using libssl1.0.2. As a SONAME bump it also seems >> rather inappropriate during the freeze. > > That's a good point. I was trying to provide an alternative to the > broken NMU that was going to be uploaded, but yes this will break > applications built against libssl1.0.2. It does fix using this with > the openssl tool however. > Right.
>> I'm very interested in having this fixed in stretch so I can get the >> secure-boot stuff working on ftp-master, but this doesn't look like the >> way to go. Not to mention that you'd have to justify the bump from >> 0.4.3 to 0.4.4. >> >> Can you explain your plans here? > > As you suggested in your followup, the way forward would appear to be > to upload a new libp11 source package that builds against > libssl1.0.2. I can also backport all of the changes to 0.4.3 and > upload to testing-proposed-updates. Does that sound reasonable? > Having read through the 0.4.4 changes I think I'd be ok with getting that in if you're confident. I guess the other question is should libp11-dev come from the openssl1.1-using package or the openssl1.0.2-using one. At this late stage I guess it's safer to stay with 1.0.2, and have the libp11-openssl1.1 package (or however it's called) only provide a libengine-pkcs11-openssl1.1 binary? Cheers, Julien
