Control: reassign -1 python-wsgi-intercept 1.8.1-2 Control: clone -1 -2 Control: reassign -2 python3-httplib2 0.14.0-1 Control: retitle -2 python3-httplib2 >= 1.13.0 breaks python3-wsgi-intercept << 1.9.0 Control: block -2 by -1
On Tue, Feb 11, 2020 at 11:43:03PM +0100, Andreas Beckmann wrote: > I have a little trouble getting what you mean here: > > On Mon, 10 Feb 2020 17:52:33 +0100 =?UTF-8?Q?H=c3=a5vard_Flaget_Aasen?= > <haavard_aa...@yahoo.no> wrote: > > Though they write that the change was indeed in the httplib2 package. > > * the change that introduced the bug > * the change that fixed the bug (is there an embedded copy of httplib2 > somewhere?) > * both ? wsgi-intercept reimplements a bit of httplib2's interface in order to intercept calls to it. Until version 1.9.0, the way it did so violated httplib2's reasonable expectations of its own interface, that is, that httplib2 could reasonably add more keyword arguments to its own classes' __init__ methods. This is a perfectly normal way to extend interfaces in Python, and it only broke because wsgi-intercept was making unwarranted assumptions. https://github.com/cdent/wsgi-intercept/commit/c4d44f5712e85d302db7e80e16156ca9c501bb6b (in part) fixes this by ignoring those extra keyword arguments for the purpose of interception, which indeed seems sensible since details of TLS versions aren't very relevant when you're writing tests that intercept network calls and redirect them to a WSGI application. So, I disagree with Thomas that this is principally a bug in httplib2, and I'm reassigning it back to wsgi-intercept. The main part of the fix should be to upgrade wsgi-intercept to 1.9.0 or newer. However, it would probably be appropriate for python3-httplib2 to declare a Breaks on python3-wsgi-intercept (<< 1.9.0) once a fixed version exists in the archive, so I'm cloning a part of this bug for that. -- Colin Watson [cjwat...@debian.org]