Bug 1634549

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.