Hi Niels, On Tue, Jan 10, 2017 at 09:36:57PM +0100, Niels Thykier wrote: > Package: zurl > Version: 7.51.0-1 > Severity: grave > Tags: sid stretch > > Hi, > > Please use ssl1.0 for stretch. > > We have requested the curl also reverts to ssl1.0 (please see > #850880). Since zurl is using a curl function exposing SSL_CTX, it > will have to use the same version libssl as curl itself.
This leads to an unfortunate situation: zurl/1.7.1-2 in testing is _not_ affected by this bug, as it's linked against openssl 1.0 and also build-depends on libssl1.0-dev. But still, it's currently broken by curl 7.51.0-1, which went to testing even tough it should have been blocked by #844018, a bug predicting exactly this very issue. zurl/1.7.1-3 would fix that, so it should go ASAP to testing, to minimize user impact. Without the 10-day-policy, it would already have entered testing. Now what shall I do? I understand that the proper solution would be the one you suggest. But that would add another 10-day-delay, and would only help in case curl in testing _also_ was updated by then. Which I doubt, as #844018 is open since 2 months without any action. IMHO, the best solution for our users would be waiting until zurl/1.7.1-3 entered testing (fixing the immediate impact), and then uploading a fixed version zurl/1.7.1-4, which also conflicts with libcurl3 at version 7.51.0-1. That would make both the fixed version of curl and zurl move from sid to testing at the same time, making the update seamless for our users. Am I missing something? Is this a good way to handle the situation? Would it be possible to speed up the propagation of zurl/1.7.1-3 to testing so I can upload zurl/1.7.1-4? Jan
