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

[Julien Cristau]

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,
Julien

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
>