Description of problem: https://src.fedoraproject.org/rpms/python-pyvmomi/c/400048ef70a6ba7fd5863c09b4413c4f89274349?branch=epel7 removed python2 support. There's no corresponding upstream reference, so even though you wrote "due to failing tests", I still don't know why, exactly. Please bring back the python2 subpackage, I'm still using it. Version-Release number of selected component (if applicable): 6.7.3-2.el7
I think the two failing tests might be a bug in vcrpy, which is years out of date in EPEL-7 (1.5.2). set_tunnel method is present in both python2 httplib and python3 http.client code since 10 years, so something fishy is going on here. You disabled tests with python3 in EPEL-7, so you don't even know if they're failing. Dropping python2 subpackage because of two failing tests seems unfair...
Duplication of bug #1757722. Discussed the python2 support with upstream. See https://github.com/vmware/pyvmomi/issues/837
*** Bug 1757722 has been marked as a duplicate of this bug. ***
> I think the two failing tests might be a bug in vcrpy, which is years out of date in EPEL-7 (1.5.2). This is actually also a bug in rawhide for FTBFS. https://bugzilla.redhat.com/show_bug.cgi?id=1763484
> You disabled tests with python3 in EPEL-7, so you don't even know if they're failing. > Dropping python2 subpackage because of two failing tests seems unfair... DEBUG util.py:686: Executing command: ['/usr/bin/yum-builddep', '--installroot', '/var/lib/mock/epel7-build-18188773-1298191/root/', '/var/lib/mock/epel7-build-18188773-1298191/root//builddir/build/SRPMS/python-pyvmomi-6.7.3-3.el7.src.rpm'] with env {'TERM': 'vt100', 'SHELL': '/bin/bash', 'HOME': '/var/lib/mock/epel7-build-18188773-1298191/rpmconfig', 'HOSTNAME': 'mock', 'PATH': '/usr/bin:/bin:/usr/sbin:/sbin', 'PROMPT_COMMAND': 'printf "\\033]0;<mock-chroot>\\007"', 'PS1': '<mock-chroot> \\s-\\v\\$ ', 'LANG': 'C.UTF-8', 'LC_MESSAGES': 'C.UTF-8', 'LD_PRELOAD': '/var/tmp/tmp.mock.bmkn6olx/$LIB/nosync.so'} and shell False DEBUG util.py:595: Last metadata expiration check: 0:00:10 ago on Thu Nov 14 06:59:59 2019. DEBUG util.py:593: No matching package to install: 'python36-testtools >= 0.9.34' DEBUG util.py:593: No matching package to install: 'python36-vcrpy' DEBUG util.py:593: No matching package to install: 'python36-yarl' DEBUG util.py:593: No matching package to install: 'python36-fixtures' DEBUG util.py:593: No matching package to install: 'python36-tox' DEBUG util.py:593: No matching package to install: 'python34-testtools >= 0.9.34' DEBUG util.py:593: No matching package to install: 'python34-vcrpy' DEBUG util.py:593: No matching package to install: 'python34-yarl' DEBUG util.py:593: No matching package to install: 'python34-fixtures' DEBUG util.py:593: No matching package to install: 'python34-tox' DEBUG util.py:593: Not all dependencies satisfied https://koji.fedoraproject.org/koji/taskinfo?taskID=38986280
If you don't want to maintain the python2 subpackage (I know it works for me and I'm using it) then please add me to co-maintainers (FAS: rathann). I'll maintain it for you. I find it very frustrating that you simply dropped the python2 subpackage because of two failing tests when you're not even testing the python3 subpackage.
According to FAS, you're provenpackager. Please feel free to use the power. :-) But again, I doubt there's much sense to continue with a python2 subpackage. We'd run into version conflicts, e.g. I've already discussed with upstream about python2 and any further releases. Why not stick with EPEL6 then, as downgrade? EPEL7 has somehow a long period left for stable support and I'm not convinced to use downstream forks to heavily insist on py2 enforcements anywhere.
(In reply to Raphael Groner from comment #7) > According to FAS, you're provenpackager. Please feel free to use the power. :-) I am, but I don't want to abuse that power, so I'm asking first. Adding me to co-maintainers would make it official. Anyway, I've added a bugzilla watch on the EPEL component for the time being and I'll bring back the EPEL7 python2 subpackage shortly. Thank you. > But again, I doubt there's much sense to continue with a python2 subpackage. We'd run into version conflicts, e.g. I've already discussed with upstream about python2 and any further releases. I saw the ticket, it was inconclusive. > Why not stick with EPEL6 then, as downgrade? EPEL7 has somehow a long period left for stable support and I'm not convinced to use downstream forks to heavily insist on py2 enforcements anywhere. I'm using this on RHEL7 as part of internal OpenShift-related tooling. Downgrading to RHEL6 is not an option. I have plans for moving my tooling to python3, but that takes time, and I need a working version now.
Dominik, are you also using python2-pyvirtualize? We are thinking of removing that python2 package, because it can't install, but if you planning on maintaining python2-pyvmomi, and are using python2-pyvirtualize, then we can hold off on that.
(In reply to Troy Dawson from comment #9) > Dominik, are you also using python2-pyvirtualize? > We are thinking of removing that python2 package, because it can't install, > but if you planning on maintaining python2-pyvmomi, and are using > python2-pyvirtualize, then we can hold off on that. Maybe take an alternative look into python-vconnector and its further depending packages instead. They seem to provide the better API and show more active development from upstream. Honestly, I doubt I'm going to continue with pyvirtualize anyhow.
(In reply to Dominik 'Rathann' Mierzejewski from comment #8) > (In reply to Raphael Groner from comment #7) > I'm using this on RHEL7 as part of internal OpenShift-related tooling. > Downgrading to RHEL6 is not an option. I have plans for moving my tooling to > python3, but that takes time, and I need a working version now. That smells like need for a separate python2-pyvmomi package then for legacy reasons. It can have a completely separate version model.
python-pyvmomi-6.7.3-4.el7 has been pushed to the Fedora EPEL 7 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-EPEL-2019-92d7ecde76
python-pyvmomi-6.7.3-4.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
python2-pyvmomi went missing again. Anyone knows the reason for that? @updates
IT looks like Raphael removed the python2 package again from EPEL7: https://src.fedoraproject.org/rpms/python-pyvmomi/c/a28fbaa61c302539c30bd8d68de96dadaec2f3e3?branch=epel7 Raphael, please revert.
Or actually, I'll fix it myself, as it's a quick fix.
7.0.1-2 contains python2 package again: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-3aa347a6ab . Please test and give karma.
Thank you, that was fast. :-)
It was agreed in another bug that python2 has no future in case of pyvmomi upstream, so the decision is clear to have a downstream issue here and I refuse to maintain. (In reply to Raphael Groner from comment #11) > (In reply to Dominik 'Rathann' Mierzejewski from comment #8) > > (In reply to Raphael Groner from comment #7) > > > I'm using this on RHEL7 as part of internal OpenShift-related tooling. > > Downgrading to RHEL6 is not an option. I have plans for moving my tooling to > > python3, but that takes time, and I need a working version now. > > That smells like need for a separate python2-pyvmomi package then for legacy > reasons. It can have a completely separate version model.
There's no official support from upstream any more for python2. Good luck then! https://github.com/vmware/pyvmomi/issues/837
(In reply to Raphael Groner from comment #19) > It was agreed in another bug that python2 has no future in case of pyvmomi > upstream, so the decision is clear to have a downstream issue here and I > refuse to maintain. Who agreed and where? It certainly wasn't me. Nobody's asking you to do anything special to maintain the python2 package. Just please stop removing it quietly when it still works fine. If and when a new version stops working with python2, I'll look at introducing a separate legacy python2 package, but that would be a lot of unnecessary work right now.
> Just please stop removing it quietly when it still works fine. No, tests fail and upstream refused to fix in case of python2 execution. Did you read the linked upstream issue? > I'll look at introducing a separate legacy python2 package Indeed same thought here but no interest from my side. Please feel free to start that fork.
I understand your position and I just want to add a "users" perspective. As I have written in bug #1934425 we want to use ansible. Now we cannot use ansible package (base on python 2) because we need pyvmomi and we cannot use ansible-python3 package because we need e.g. python winrm module.
> As I have written in bug #1934425 we want to use ansible. Well, both Ansible (from Red Hat) and VMware are all commercial products. Me as a community member and unpaid Fedora contributor can not help with compatibility issues born from silly management decision. What does user mean. > we need e.g. python winrm module. WinRM is from Microsoft, blame them instead. Why not SSH as alternative?