Bug 1658292 - yum-builddep uninformative error message
Summary: yum-builddep uninformative error message
Status: CLOSED DUPLICATE of bug 1724668
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: dnf-plugins-core
Version: 8.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: 8.0
Assignee: Marek Blaha
QA Contact: Karel Srot
: Engineering1659984 (view as bug list)
Depends On: Red Hat1681085
TreeView+ depends on / blocked
Reported: 2018-12-11 17:08 UTC by Michal Kolar
Modified: 2019-07-17 07:10 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-07-17 07:10:56 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

Comment 1 Panu Matilainen 2018-12-12 11:18:08 UTC
From the gdb spec:
> Source8: _gdb.spec.Patch.include
> Source9: _gdb.spec.patch.include
> %include %{SOURCE8}

This means that the %include'd file needs to be in your %_sourcedir, which typically is %{_topdir}/SOURCES which typically is ~/rpmbuild/SOURCES. So when you define %_topdir to something temporary when installing the src.rpm, a consequent spec parse is not going to find that file unless you use the same %_topdir define there as well, or set it in your ~/.rpmmacros.

When parsing a spec for querying only, we ignore missing sources and patches already, and we technically we could certainly do the same for %include too. But the critical difference here is that the %include'd file is a part of the spec and generally there's no telling how important part it is. 

In this case there are two %include's, one of them is in %prep and that one we ignore already, but the other is in the spec preamble that could contain anything, and just can't be ignored - for all we know it might contain the build-requires.
This is not a bug but an annoying an unfortunate side-effect of using %include, and I don't see how we could do anything about it :-/

Comment 2 Michal Kolar 2018-12-12 12:14:51 UTC
That make sense. It does not work again if I delete ~/rpmbuild.  Thanks Panu for clarifying.

You can consider more descriptive message to user.

Comment 3 Panu Matilainen 2018-12-12 12:31:42 UTC
(In reply to Michal Kolar from comment #2)
> You can consider more descriptive message to user.

That's a fair point though. Reopening for this purpose, because yum/dnf is important information here.
Compare these two:

> [root@sopuli ~]# rpmspec -q ~pmatilai/rhel/gdb/gdb.spec 
> warning: Macro expanded in comment on line 35: %{tarname}.tar.xz
> error: Unable to open /root/rpmbuild/SOURCES/_gdb.spec.patch.include: No such file or directory
> error: query of specfile /home/pmatilai/rhel/gdb/gdb.spec failed, can't parse

> [root@sopuli ~]# dnf builddep ~pmatilai/rhel/gdb/gdb.spec 
> Last metadata expiration check: 0:02:34 ago on Wed 12 Dec 2018 02:27:42 PM EET.
> Failed to open: '/home/pmatilai/rhel/gdb/gdb.spec', not a valid spec file: can't parse specfile
>Error: Some packages could not be found.

Comment 4 Panu Matilainen 2018-12-17 12:10:22 UTC
*** EngineeringBug 1659984 has been marked as a duplicate of this bug. ***

Comment 6 Jaroslav Mracek 2019-03-28 17:34:07 UTC
I believe that DNF reports already everything what we get from rpm. See code:

            spec = rpm.spec(spec_fn)
        except ValueError as ex:
            msg = _("Failed to open: '%s', not a valid spec file: %s") % (spec_fn, ex)

Please could you enhance the error message in RPM or privede a tip how to use rpm API more efficiently?

Comment 7 Panu Matilainen 2019-03-29 06:54:56 UTC
Sigh. Guys, I've explained this half a dozen times now in several places to several people who always seem completely unaware of any previous efforts. 

In short, the details of the error are in the rpm log, which dnf redirects someplace out of sight. If you take the code in comment #6 out of dnf context, this the output that you'll get:

[pmatilai@sopuli systemd]$ ~/ps.py systemd.spec 
error: Unable to open /home/pmatilai/rpmbuild/SOURCES/triggers.systemd: No such file or directory
Failed to open: 'systemd.spec', not a valid spec file: can't parse specfile

Note the error: line which actually tells you *why* it wasn't able to parse it, this is what is missing in dnf output and that is the difference shown in comment #3.

See this related upstream ticket on this matter for details: https://github.com/rpm-software-management/dnf-plugins-core/pull/320 where I provided some ideas how to better deal with it, and coordinate your efforts. Please.

Comment 8 Marek Blaha 2019-03-29 08:31:37 UTC
There exists a related Fedora bug https://bugzilla.redhat.com/show_bug.cgi?id=1663619 
I'll improve the PR for better user's experience.

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