Learn more about these different git repos.
Other Git URLs
I maintain packages such as python3-greenlet, which is a Python3-only fork of the Fedora python-greenlet for EPEL7 since python-greenlet is already part of RHEL but only has the Python2 subpackage.
python3-greenlet
python-greenlet
Since on Fedora python3_pkgversion expands to 3, which is the name of the source package, creating the SRPM on Fedora would fail unless python3_pkgversion is redefined (otherwise the subpackage will have the same name as the main package); on RHEL/EPEL given the long life of the release the Python 3 stack might be updated midlife (e.g. RHEL7's Python 3 stack went from python34 to python36 recently).
fedpkg used to handle this as of last year, but the current version has a regression where it seems the redefinition of python3_pkgbuild is not parsed. rpmbuild -bs would build the package just fine but fedpkg srpm would fail, saying I am creating a subpackage with exactly the same name as the main package.
python3_pkgbuild
rpmbuild -bs
fedpkg srpm
~/src/fedora/pkgs/python3-greenlet epel7* ❯ rpm -qf $(which fedpkg) fedpkg-1.37-2.fc30.noarch ~/src/fedora/pkgs/python3-greenlet epel7* ❯ cat python3-greenlet.spec| grep python3_pkgversion | head -n3 # Allow SRPM to be created on Fedora, where python3_pkgversion == 3 # you need to override python3_pkgversion in ~/.rpmmacros %global python3_pkgversion 36 ~/src/fedora/pkgs/python3-greenlet epel7* ❯ rpmbuild -bs ./python3-greenlet.spec Wrote: /home/michel/rpmbuild/SRPMS/python3-greenlet-0.4.15-1.fc30.src.rpm ~/src/fedora/pkgs/python3-greenlet epel7* ❯ fedpkg srpm error: line 34: %package -n python3-greenlet: package python3-greenlet already exists error: query of specfile /home/michel/src/fedora/pkgs/python3-greenlet/python3-greenlet.spec failed, can't parse Could not execute srpm: Could not get n-v-r-e from /home/michel/src/fedora/pkgs/python3-g reenlet/python3-greenlet.spec ~/src/fedora/pkgs/python3-greenlet epel7* ❯ cat ~/.rpmmacros %python3_pkgversion 36 ~/src/fedora/pkgs/python3-greenlet epel7* ❯ fedpkg srpm Wrote: /home/michel/src/fedora/pkgs/python3-greenlet/python3-greenlet-0.4.15-1.el7.src.rpm
Fedpkg does not parse spec file by itself. It calls rpm to do it. The difference to rpmbuild -bs is that it defines macros so that the call looks as close to what would be default on target as possible. Thus if you call fedpkg in epel7 branch, it will add --define 'dist %{?distprefix}.el7' --define 'rhel 7' --eval '%undefine fedora' --define 'el7 1' --eval '%undefine fc30'.
rpm
fedpkg
epel7
--define 'dist %{?distprefix}.el7' --define 'rhel 7' --eval '%undefine fedora' --define 'el7 1' --eval '%undefine fc30'
I believe this behaviour was always there, and the issue you're running into must have always existed too.
So, the redefinition of python3_pkgversion is indeed skipped, because the condition around it says it's only to be used on Fedora, while you're actually creating srpm for EPEL.
python3_pkgversion
If you change the condition to test something like 0%{?rhel} == 7, the srpm will be built correctly.
0%{?rhel} == 7
Alternatively you could call fedpkg --release master srpm, which would make the call as if it was on Fedora Rawhide, which will trigger your condition and produce an RPM with dist tag of fc31.
fedpkg --release master srpm
fc31
It probably boils down to what you need the srpm for. But generally what you're seeing is not a bug.
Metadata Update from @lsedlar: - Issue close_status updated to: Invalid - Issue status updated to: Closed (was: Open)
Huh, that definitely makes sense. Thanks!
Login to comment on this ticket.