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 :-/

That make sense. It does not work again if I delete ~/rpmbuild.  Thanks Panu for clarifying.

You can consider more descriptive message to user.

(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.

*** EngineeringBug 1659984 has been marked as a duplicate of this bug. ***

I believe that DNF reports already everything what we get from rpm. See code:

```
        try:
            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?

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.

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.

PR: https://github.com/rpm-software-management/dnf-plugins-core/pull/320