Bug 1671012 - Unable to use fedpkg due to "Unknown tag: %python_provide"
Summary: Unable to use fedpkg due to "Unknown tag: %python_provide"
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: fedpkg
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondřej Nosek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-01-30 14:41 UTC by Susi Lehtola
Modified: 2021-09-09 17:45 UTC (History)
6 users (show)

Fixed In Version: fedpkg-1.41-1.fc33
Clone Of:
Environment:
Last Closed: 2021-09-09 17:45:07 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Susi Lehtola 2019-01-30 14:41:09 UTC
I'm trying to build a new version of libxc for rawhide, but fedpkg fails both locally

$ fedpkg local
error: line 94: Unknown tag: %python_provide: ERROR: python3-libxc not recognized.
error: query of specfile /home/susi/fedora/libxc/master/libxc.spec failed, can't parse

as well as remotely

$ fedpkg scratch-build
error: line 94: Unknown tag: %python_provide: ERROR: python3-libxc not recognized.
error: query of specfile /home/susi/fedora/libxc/master/libxc.spec failed, can't parse

Comment 1 Ondřej Nosek 2019-01-30 17:01:53 UTC
I tried to make scratch build (including rawhide target) or local build. It was in branches master, f29, epel7. 
Of course, I can not verity all variants, because it would take too much time for some builds.

DistGit repo here: https://src.fedoraproject.org/rpms/libxc.git
fedpkg local
fedpkg scratch-build
fedpkg scratch-build --target rawhide

What version of fedpkg do you use? I tested it mostly on fedpkg-1.35-2 on Fedora29 OS. As you probably running your builds your own unpushed changes ... is it possible, there is a problem with spec file itself?

Comment 2 Susi Lehtola 2019-01-30 17:43:05 UTC
As implied by the Product and Version fields above, this is a CentOS 7 system.

$ cat /etc/redhat-release 
CentOS Linux release 7.6.1810 (Core) 

$ rpm -q fedpkg
fedpkg-1.35-1.el7.noarch

Comment 3 Ondřej Nosek 2019-01-30 23:15:55 UTC
How I tested this time:


docker run -t -i centos:7 bash
cat /etc/redhat-release
#	CentOS Linux release 7.6.1810 (Core)
yum install wget
wget http://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
rpm -ivh epel-release-latest-7.noarch.rpm
yum repolist
yum install fedpkg
rpm -q fedpkg
#	fedpkg-1.35-1.el7.noarch
cd ~
git clone https://src.fedoraproject.org/rpms/libxc.git
cd libxc
fedora-packager-setup  # WARNING: it will revoke your current certificate 
export KRB5CCNAME=/tmp/ticket  # workaround
kinit myname
fedpkg scratch-build --target=rawhide


... and build goes well so far. And I haven't faced "Unknown tag" issue. What changes do you have in dist-git? Or are you switched in specific branch?

Comment 4 Susi Lehtola 2019-01-31 09:00:40 UTC
$ git status
# On branch master
nothing to commit, working directory clean
$ fedpkg build
error: line 94: Unknown tag: %python_provide: ERROR: python3-libxc not recognized.
error: query of specfile /home/fedora/libxc/master/libxc.spec failed, can't parse

The system is fully up to date.

It's quite weird that even fedora-packager-setup works for you: it fails on the EPEL7 system, see #1671255.

Comment 5 Lubomír Sedlář 2019-01-31 14:04:12 UTC
Do you have python-rpm-macros package installed? That should define the %python_provide macro.

However I think the macro is rejecting the package name. For EPEL 7 it should not be python3-foo, but python%{python3_pkgversion}-foo. Currently %python3_pkgversion expands to 34. You may want to adjust dependencies as well (for example there is no python3-numpy, but there is python34-numpy and python36-numpy).
https://fedoraproject.org/wiki/PackagingDrafts:Python3EPEL

Comment 6 Ondřej Nosek 2019-01-31 14:08:40 UTC
Hmm, that's weird. For me, its building well:
https://koji.fedoraproject.org/koji/taskinfo?taskID=32365814
This is rawhide build. Currently in progress and it seems it is going to finish successfully.
I haven't seen any errors you have noted here :-/.
I installed neither python3-foo nor python34-numpy. Lubomir, these are needed for fedpkg local, right?

Comment 7 Susi Lehtola 2019-01-31 17:09:20 UTC
python-rpm-macros package was not installed, but installing it made no difference.

The problem is that fedpkg is trying to parse the %python_provide for rawhide, which does not work on EPEL7.

Comment 8 Susi Lehtola 2019-01-31 17:10:29 UTC
It sounds like since fedpkg is checking for macros, it should provide these macros in the branches that lack them...

Comment 9 Lubomír Sedlář 2019-02-01 07:41:40 UTC
It's actually RPM that is parsing the spec file and failing.

Let's take a step back: what are you trying to achieve? Local build and scratch build are significantly different things.

Please also share output of the command with -v -d arguments (e.g. fedpkg -v -d scratch-build). The traceback could help.

Comment 10 Susi Lehtola 2019-02-01 08:39:46 UTC
I am trying to build the package in koji. It is also generally useful to be able to do mock builds.

$ fedpkg -v -d scratch-build
Creating repo object from /home/fedora/libxc/master
Initiating a koji session to https://koji.fedoraproject.org/kojihub
Logging into https://koji.fedoraproject.org/kojihub with Kerberos authentication.
Errors occoured while running following command to get N-V-R-E:
rpm --define '_sourcedir /home/fedora/libxc/master' --define '_specdir /home/fedora/libxc/master' --define '_builddir /home/fedora/libxc/master' --define '_srcrpmdir /home/fedora/libxc/master' --define '_rpmdir /home/fedora/libxc/master' --define 'dist .fc30' --define 'fedora 30' --eval '%undefine rhel' --define 'fc30 1' --eval '%undefine el7' -q --qf "??%{NAME} %{EPOCH} %{VERSION} %{RELEASE}??" --specfile "/home/fedora/libxc/master/libxc.spec"
error: line 94: Unknown tag: %python_provide: ERROR: python3-libxc not recognized.
error: query of specfile /home/fedora/libxc/master/libxc.spec failed, can't parse

Could not get n-v-r-e from /home/fedora/libxc/master/libxc.spec
Note: You can skip NVR construction & NVR check with --skip-nvr-check. See help for more info.
Logout kojisession
Could not execute scratch_build: Cannot continue without properly constructed NVR.
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 9, in <module>
    load_entry_point('fedpkg==1.35', 'console_scripts', 'fedpkg')()
  File "/usr/lib/python2.7/site-packages/fedpkg/__main__.py", line 94, in main
    sys.exit(client.args.command())
  File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 2282, in scratch_build
    return self.build()
  File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 1611, in build
    task_id = self._build(sets=sets)
  File "/usr/lib/python2.7/site-packages/fedpkg/cli.py", line 1088, in _build
    return super(fedpkgClient, self)._build(sets)
  File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 1668, in _build
    fail_fast=self.args.fail_fast)
  File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 2263, in build
    raise rpkgError('Cannot continue without properly constructed NVR.')
pyrpkg.errors.rpkgError: Cannot continue without properly constructed NVR.

Comment 11 Lubomír Sedlář 2019-02-01 09:13:17 UTC
For the scratch-build case it should work for you if you add --skip-nvr-check argument. Fedpkg wants to get NVR of the build from spec file so that it check it does not exist yet (to fail fast), and also to include in some messages it prints to stdout.

Comment 12 Susi Lehtola 2019-02-01 10:50:12 UTC
Great, that works!

Maybe that could be added as a suggestion to the error in EPEL?

Comment 13 Susi Lehtola 2019-02-11 12:26:27 UTC
The --skip-nvr-check flag only works with 
 fedpkg build

not with
 fedpkg scratch-build

or
 fedpkg srpm

Could the flag be added to these other use cases as well?

Comment 14 Fedora Admin XMLRPC Client 2020-03-23 16:40:15 UTC
This package has changed maintainer in the Fedora.
Reassigning to the new maintainer of this component.

Comment 15 Fedora Update System 2021-08-25 10:26:39 UTC
FEDORA-EPEL-2021-4b1bb0ee48 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-4b1bb0ee48

Comment 16 Fedora Update System 2021-08-25 10:29:58 UTC
FEDORA-2021-20e5f8a6b8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8

Comment 17 Fedora Update System 2021-08-25 20:50:45 UTC
FEDORA-2021-20e5f8a6b8 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-20e5f8a6b8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 18 Fedora Update System 2021-09-01 12:48:39 UTC
FEDORA-2021-20e5f8a6b8 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8

Comment 19 Fedora Update System 2021-09-01 20:21:04 UTC
FEDORA-2021-20e5f8a6b8 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-20e5f8a6b8`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-20e5f8a6b8

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 20 Fedora Update System 2021-09-09 17:45:07 UTC
FEDORA-2021-20e5f8a6b8 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.