Doing just about anything in anything that uses urllib3 (which is a ton of things) causes this DeprecationWarning: /usr/lib/python3.10/site-packages/urllib3/connection.py:512: DeprecationWarning: ssl.match_hostname() is deprecated match_hostname(cert, asserted_hostname) I tested with 1.26.7 (just released), but it still has the issue. There's also another deprecation warning I see in some cases: /usr/lib/python3.10/site-packages/urllib3/util/retry.py:38: DeprecationWarning: Using 'Retry.DEFAULT_METHOD_WHITELIST' is deprecated and will be removed in v2.0. Use 'Retry.DEFAULT_ALLOWED_METHODS' instead I added a comment to an upstream issue on this - https://github.com/urllib3/urllib3/issues/2200#issuecomment-931759912 .
oh, that second one is probably a deprecation warning in the app I'm running, ignore that. But the other one is in urllib3 itself.
Note that the upstream's response indicates they will resolve this by bundling.
well, sorta, but then the commit from the main branch that they reference - https://github.com/urllib3/urllib3/pull/2198/files - doesn't seem to do that, exactly. or if it does, it just moved it from one place where it already was (`_implementation.py`), to another. I had actually run across that commit already in looking into this issue, but wasn't entirely clear on exactly what was going on there.
We currently remove urllib3/packages/ssl_match_hostname/_implementation.py in %install.
so upstream has resolved this now: https://github.com/urllib3/urllib3/pull/2448 Miro, do you think we can just backport this, or what else would you prefer to do?
If we are OK with the idea of bundling, I'd do so, yes.
Looking into it more, this is clearly a piece of code that Python upstream no longer wishes to maintain and urrlib3 upstream does. Hence, I think forcibly unbundling it would be the wrong thing to do. We just need to update the license from plain MIT to MIT and Python.
yeah, that was my take too, the deprecationwarning is literally Python telling us they don't want us to use it any more.
So, uh, I came back to this today, and I think all that work we got upstream to do was unnecessary. Upstream was already set to vendor it on Python 3.10+. All we had to do was stop explicitly unbundling it downstream. Oh well, let's not tell them. :D I'm sending a build that drops our unbundling stuff, but doesn't backport the upstream PR as it doesn't apply immediately and doesn't seem to be necessary. Just removing the unbundling makes the deprecation warnings go away in my tests.
FEDORA-2022-104704f78a has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-104704f78a
FEDORA-2022-104704f78a has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-104704f78a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-104704f78a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-104704f78a has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.