[pkg-opensc-maint] Bug#846548: marked as pending

[Eric Dorland]

* Julien Cristau (jcristau at 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 (jcristau at debian.org) wrote:
> >> On 05/30/2017 07:16 AM, Eric Dorland wrote:
> >>> * Julien Cristau (jcristau at debian.org) wrote:
> >>>> On 05/29/2017 03:15 AM, Eric Dorland wrote:
> >>>>> * Julien Cristau (jcristau at 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 <eric at kuroneko.ca>
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93