* Julien Cristau (jcris...@debian.org) wrote: > It's now through NEW. The next step would be an upload to sid, with > urgency=high, and an unblock request to the release.debian.org > pseudopackage.
Thanks and done as you have seen. I'm guessing it's not worth it, but should we promote libp11 0.4.4-1 as well for version parity? > On 06/06/2017 02:26 AM, Eric Dorland wrote: > > OK, apologies for the delay (and I know we're getting down to the > > wire). I just uploaded libp11-openssl1.1 to experimental and of course > > it's in NEW. If this looks ok let me know what the next steps are if > > we want to try to get it into stretch. > > > > * Julien Cristau (jcris...@debian.org) wrote: > >> On 05/30/2017 07:16 AM, Eric Dorland wrote: > >>> * Julien Cristau (jcris...@debian.org) wrote: > >>>> 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? > >>> > >>> OK, I like this plan. We should get the naming right going forward > >>> though for the libengine-pkcs11-openssl1.1 package. Is that how other > >>> packages are handling naming when they depend on a particular version > >>> of openssl? > >>> > >> I'm not sure, to be honest. I don't know if there are any other similar > >> cases right now. This package name wouldn't survive stretch in any > >> case, I guess? > >> > >>> I should be able to get fixed uploads to unstable in a couple of days. > >>> > >> Nice. Thanks. > >> > >> Cheers, > >> Julien > > > -- Eric Dorland <e...@kuroneko.ca> 43CF 1228 F726 FD5B 474C E962 C256 FBD5 0022 1E93
