Bug 1293687 - rpmspec --query causes error if patch section contains an URI
rpmspec --query causes error if patch section contains an URI
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
: FutureFeature, Reopened
: 1311349 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2015-12-22 12:12 EST by Ali Akcaagac
Modified: 2016-02-24 03:24 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-20 02:14:05 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Bugzilla 1281464 None None None 2015-12-22 12:12 EST

  None (edit)
Description Ali Akcaagac 2015-12-22 12:12:48 EST
Today I hit a rare condition with a spec file that gives an error when issuing:

rpmspec --query xfce-polkit.spec


The file that causes the error is found here:


The patch0 section here contains an URI, that directs to an external patch on a different platform / server (git).

Unfortunately issuing above query command returns an error because (what I believe) of rpmspec not being able to deal with that.

We do have an own build farm here that builds (and rebuilds) different parts of Fedora, so we can customize the stuff for our needs and requirements.

We have an own build tools and build scripts that heavily depends on external tools such as rpm-build and rpmspec --qery (or --parse).

The stuff runs well for the past couple of years, until this new issue has shown up.

We usually grab the *.spec files first, so we can process them with the rpmspec --query util, which returns the - to be build - resulting packages (incl. NEVRA). The output is being processed elsewhere and we continue building the stuff with rpm-build as needed.

Now the indepth problem:

We do deal with plenty of spec files that way. Say for example:

rpmspec --query exo.spec
rpmspec --query Thunar.spec
rpmspec --query xfce-polkit.spec

and so on...

We rpmspec these files before we do anything else with them. So during that time we only have the *.spec files. No patches! Nothing!

Plenty of these spec files do have references to external patches (but they are referenced inside the spec files as normal plain filenames). We now hit a special condition inside xfce-polkit.spec where the patch has been referenced as URI. And here rpmspec fails (... and expects the patch in the SOURCE folders). But running rpmspec on the other spec files are not going to error and thus don't expect anything else.

After some RPM.org studying I found out that the the patch section allows the URI reference for patch files and thus using URI within patch section is ok.


Search for "the patch tag"

QUOTE: "RPM processes patch tags the same way it does source tags. Therefore, it's acceptable to use a Uniform Resource Locator (URL) on a patch line, too."

Now it would be nice, if rpmspec would deal the same way with external URI references than with local files within the patch section.

Or simply said:

We want to continue issuing

rpmspec --query some.spec

and not being bothered with errors of missing patch files in some source directory. Otherwise we would expect the same errors to show up with any spec file that has 1 or more patch sections embedded (but referenced as files). Even downloaded or not.

Comment 1 Raphael Groner 2015-12-23 05:21:50 EST
Why not use?

$ spectool -g xfce-polkit.spec

In case of rpmbuild folder structure:

$ spectool -g -R xfce-polkit.spec

I'll close as invalid, please reopen if you think there's still an issue.
Comment 2 Ali Akcaagac 2015-12-23 08:07:30 EST
Please do not close this bugreport!

a) we use rpmspec AND NOT spectool (we depend on rpmspec and we like to be bare)
b) rpmspec is part of rpm and the split package rpm-build (iirc)
c) is it well valid to report an issue if we believe there is one and in this case I would like to clarify why rpmspec --query returns an error when processing a spec file that contains an URI within the patch section and why it doesn't return an error if the patch section only contains a reference to a file.

The last point placed at the bottom:

d) ... and this is the main concern why issues like this happen. Some use spectool, others use rpmspec and again others use some other implementation or tools (also available under fedora). And this is (or may) cause issues with existing spec files if they rely on specific *own* implementations of these tools. Now we consider rpmspec to be *the real deal*. The thing that we (that means: we as in us and our own infrastructure) can trust. We rely on tools that handle the spec files correctly.
Comment 3 Raphael Groner 2015-12-23 08:21:57 EST
ok, so this is RFE
Comment 4 Ali Akcaagac 2015-12-23 08:28:18 EST
Actually we believe this to be a bug.

Grab xfce-polkit.spec and exo.spec from Fedora GIT and query both of them.

rpmspec --query xfce-polkit.spec
rpmspec --query exo.spec

Both spec files deal with patches.

The one spec file causes rpmspec --query to return an error, the other not. Most likely also affecting the return codes to the caller (e.g. inside a bash script).

The expected behavior should be (from how I understand it):

rpmspec should either report error on both spec files or report no error on both spec files. In both cases we only deal with the bare spec file. No patches or other files in any other rpmbuild directory (SOURCE, RPMs, SPEC, ...).

This *looks* like a rpmspec specific issue.
Comment 5 Ľuboš Kardoš 2016-01-18 11:07:52 EST
When "rpmspec --query" is executed, first a spec file is parsed and during this process macros in the spec file are expanded. This error is from the %uncompress macro which is used in the %autosetup macro which is used in %prep section of xfce-polkit.spec. 

To what %uncompress is expanded depends on type of file given as the first argument. But when the file is not available, this macro fails, which causes error message in output of rpmspec tool.
Comment 6 Ali Akcaagac 2016-01-18 13:31:42 EST
... and that does mean what exactly ?
Comment 7 Ľuboš Kardoš 2016-01-20 02:14:05 EST
It should be fixed in rpm-4.13.0-0.rc1.18.fc24
Comment 8 Ľuboš Kardoš 2016-02-24 03:24:47 EST
*** Bug 1311349 has been marked as a duplicate of this bug. ***

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