In line with the Mass Python 2 Package Removal [0], the following (sub)packages of python-designateclient were marked for removal: * python2-designateclient-tests According to our query, those (sub)packages only provide a Python 2 importable module. If this is not true, please tell us why, so we can fix our query. Please remove them from your package. As said in the change document, if there is no objection in a week, we will remove the package(s) as soon as we get to it. This change might not match your packaging style, so we'd prefer if you did the change. If you need more time, please let us know here. We hope this doesn't come to you as a surprise. If you want to know our motivation for this, please read the change document [0]. [0] https://fedoraproject.org/wiki/Changes/Mass_Python_2_Package_Removal
python2-designateclient is only required by python2-designateclient-tests. Please remove them both and move /usr/bin/designate to python3-designateclient.
I don't probably have and RDO Gerrit account so I'll comment here: %global pyver_bin python%{pyver} %global pyver_sitelib %python%{pyver}_sitelib %global pyver_install %py%{pyver}_install %global pyver_build %py%{pyver}_build This is totally redundant. If you set %__python to %__python3 or %__python2, all of the following works properly: %python_sitelib %python_sitearch %python_version %py_install %py_build $ rpm --define '__python %__python3' --eval '%python_version' 3.7
See for example https://src.fedoraproject.org/rpms/python-ryu/pull-request/13#request_diff
It's not redundant, we are covering for different OS versions. With the proposed fix we are getting py2 packages for those distros that still have py2 (CentOS7) and py3 for those distros that have py3 (Fedora 28)
I've never said your fix is redundant. The macros you define are redundant. You are defining your own "universal" macros, but the "universal" macros already exist. If you set %__python to a specific value, all of the macros get redefined. i.e. instead of: %global pyver 3 %global pyver_bin python%{pyver} %global pyver_sitelib %python%{pyver}_sitelib %global pyver_install %py%{pyver}_install %global pyver_build %py%{pyver}_build You do: %global __python %__python3 And you can use: %__python %python_sitelib %python_sitearch %python_version %py_install %py_build For Python 3. Or you do: %global __python %__python2 To use them for Python 2.
Got it, submitted a follow up patch. Thanks!
Great!
Tried this approach, it's not working as expected. %{python_sitelib} translates to python2 in python3 environments and the build fails. We need the macros. Dropping the patch and marking this as MODIFIED.
> %{python_sitelib} translates to python2 in python3 environments What is a python3 environment? Can you give me a reproducer, because that would be a bug. I cannot reproduce it on Fedora: $ rpm --define '__python %__python3' --eval '%python_sitelib' /usr/lib/python3.7/site-packages
Check out logs in the Fedora gate https://review.rdoproject.org/r/#/c/17220/. I've discussed this with other RDO packagers and the macros are needed. Plus, create a user for review.rdoproject.org. It's easier to review patches that way. Thanks!
I cannot reproduce your build failure on Fedora 30. Sorry. Maybe it's a Fedora 28 bug, I'll cahck that later. However, feel free to keep the macros as they are or investigate (I only pointed it out because I didn't want you to be buried bellow another layer of complexity just because of our request). > Plus, create a user for review.rdoproject.org. It's easier to review patches that way. Don't expect me to create an account on another service when I deal with Fedora packages, the canonical source of a Fedora package is https://src.fedoraproject.org - it supports pull requests and works great for reviewing patches. Please read: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintenance_and_canonicity or https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Spec_Maintenance_and_Canonicity (some content, different location) Either way, is there any expected date when this reaches Fedora? It has been a month since the initial request. Thanks
I cannot reproduce this on Fedora 28 either: <mock-chroot> sh-4.4# LANG=C.utf-8 rpmspec -P python-designateclient_new-5c8eb0f804b26424f0ce5c98c185b30b57528858.spec | grep site-packages/designateclient /usr/lib/python3.6/site-packages/designateclient %exclude /usr/lib/python3.6/site-packages/designateclient/tests /usr/lib/python3.6/site-packages/designateclient/tests Here is a scratchbuild of http://logs.rdoproject.org/20/17220/2/check/legacy-DLRN-rpmbuild-fedora/f1d38d3/buildset/fedora/repos/f0/b7/f0b7eb4d8c90ef516174538025629d8458d4180b_dev/python-designateclient-2.11.0-0.20181102184640.f0b7eb4.fc28.src.rpm rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=30694484 f28: https://koji.fedoraproject.org/koji/taskinfo?taskID=30694486 It fails with openstack-macros not being present. If I remove that dependency, it fails on %py_req_cleanup not being defined. That was smoking gun for me, openstack-macros might have some Python macros that break things. And yes, you redefine Fedor macros in https://github.com/openstack/rpm-packaging/blob/master/openstack/openstack-macros/macros.openstack-singlespec Please don't try to push this into Fedora or you'll break existing packages that work.
This was filled ~2 months ago and is in MODIFIED state for weeks, yet the Fedora package has last commit 3 months ago. What can I do to move this forward? Note that we need this change in Fedora and not RDO/whatever. Thanks.
@Victoria if it's ok for you I'll push a new build with conditionals to remove python2 subpackages aligned with what we are doing with other openstack clients. Note that we are removint python2-osc-lib and need to fix all those which depend on it.
Merged PR submitted by @amoralej. Thanks.
Thank You.