Bug 1331898

Patching or scratch build for python-docker-py-1.8.0 failed.

Created attachment 1152445 [details]
Rebase-helper rebase-helper-debug.log log file.
See for details and report the eventual error to rebase-helper https://github.com/phracek/rebase-helper/issues.

Patches were not touched. All were applied properly

ttomecek's python-docker-py-1.8.1-1.fc25 completed http://koji.fedoraproject.org/koji/buildinfo?buildID=759600

Can we not get this in F24/F23? docker-compose is blocked on it again.

Unfortunately it seems that python-3.4 on f23 has function match_hostname which is not able to match IP addresses in SSL certificates correctly:

```
___ MatchHostnameTest.test_match_ip_address_success ___
tests/unit/ssladapter_test.py:63: in test_match_ip_address_success
    assert match_hostname(self.cert, '127.0.0.1') is None
/usr/lib64/python3.4/ssl.py:285: in match_hostname
    % (hostname, ', '.join(map(repr, dnsnames))))
E   ssl.CertificateError: hostname '127.0.0.1' doesn't match either of 'localhost', '*.gensokyo.jp'
```

This is the only test failure (I had to patch docker-py's code slightly).


There's a PyPI package which backports the function for python 2 but the python 3 version of the package is not available on f23:

```
f23-container$ dnf search backports
Last metadata expiration check performed 0:23:02 ago on Wed May  4 08:53:06 2016.
=== N/S Matched: backports ===
rubygem-backports-doc.noarch : Documentation for rubygem-backports
rubygem-backports.noarch : Backports of Ruby features for older Ruby
python-backports.x86_64 : Namespace for backported Python features
python-backports-lzma.x86_64 : Backport of Python 3.3's lzma module
python2-backports_abc.noarch : A backport of recent additions to the 'collections.abc' module
python3-backports_abc.noarch : A backport of recent additions to the 'collections.abc' module
python-backports-ssl_match_hostname.noarch : The ssl.match_hostname() function from Python 3
python-contextlib2.noarch : Backports and enhancements for the contextlib module
python3-contextlib2.noarch : Backports and enhancements for the contextlib module
```

Question for python-maint team: how would you solve this situation? is it worth to provide update of python3-backports-ssl_match_hostname for f23 just for sake of having latest docker-compose in f23? Alternatively, we could do a copr repo with all needed packages.

The limitation around IP matching addresses was removed in Python 3.5, though not entirely cleanly – see [Python bug 23239]. Anyway, things should work fine on Fedora 24. (Is that the case?)

Michael, how important is it to have the fix in f23? It's possible to package python3-backports-ssl_match_hostname for f23 only; let's do it if you think it's worth the effort.


[Python bug 23239]: https://bugs.python.org/issue23239

(In reply to Petr Viktorin from comment #7)
> The limitation around IP matching addresses was removed in Python 3.5,
> though not entirely cleanly – see [Python bug 23239]. Anyway, things should
> work fine on Fedora 24. (Is that the case?)
> 
> Michael, how important is it to have the fix in f23? It's possible to
> package python3-backports-ssl_match_hostname for f23 only; let's do it if
> you think it's worth the effort.
> 
> 
> [Python bug 23239]: https://bugs.python.org/issue23239

Predicting the future is hard!

I think we can live without docker-compose 1.7.x in F23 as long as we can get it into F24. From what I understand, everything will be fine on F24 (though 1.8.0 was pushed to updates-testing for F24, I haven't seen 1.8.1 come through, nor 1.8.0 go to stable). Either way we need 1.8.x and upstream forgot to tell us about it. (See https://github.com/docker/compose/issues/3342)

There's no point putting a lot of work into this for F23 at this point; compose 1.7.x needs docker 1.10.x, and that has not yet reached stable for F23 (and at the rate things are going, I'm not sure it ever will). But it will be good to have it for F24. How much work is it going to be to package python3-backports-ssl_match_hostname for F23?

I'd like to avoid the hassle (and potential bugs) of creating a (sub-)package for a single release, and Obsoleting it in python3-f24 at the same time to keep the upgrade path clear. So let's try with f24 only; if there's need it can be added for 23.

(In reply to Petr Viktorin from comment #9)
> I'd like to avoid the hassle (and potential bugs) of creating a
> (sub-)package for a single release, and Obsoleting it in python3-f24 at the
> same time to keep the upgrade path clear. So let's try with f24 only; if
> there's need it can be added for 23.

Works for me.

python-docker-py-1.8.1-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-eda70d41d5

The reason I haven't pushed 1.8.0 to stable on f24 was that I knew there are some issues in that release and there's gonna be a 1.8.1 release.

Here's a new update: https://bodhi.fedoraproject.org/updates/FEDORA-2016-eda70d41d5

python-docker-py-1.8.1-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-eda70d41d5

python-docker-py-1.8.1-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.