Bug 1547897
| Summary: | Useless error message: not a valid spec file: can't parse specfile | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Richard W.M. Jones <rjones> |
| Component: | dnf-plugins-core | Assignee: | rpm-software-management |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | david.abdurachmanov, dmach, ignatenko, jmracek, jreiser, mblaha, mhatina, mjw, packaging-team-maint, pawel.veselov, pmatilai, pmoravco, rpm-software-management, vmukhame |
| Target Milestone: | --- | Keywords: | Triaged |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-06-28 08:35:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Richard W.M. Jones
2018-02-22 08:51:26 UTC
Please, can you provide this failing spec file? The spec file isn't important. It's only failing because a macro somewhere (it's hard to tell where) isn't being expanded. You can reproduce the bug with any bogus specfile, eg: $ echo -e '\n\n\n\n\n\n' > foo.spec $ sudo dnf builddep foo.spec Last metadata expiration check: 0:03:28 ago on Mon 26 Feb 2018 08:19:08 GMT. Failed to open: 'foo.spec', not a valid spec file: can't parse specfile The spec file parsing is done via rpm.spec("the file"). And this function does not produce any more detailed information on why it failed to parse the spec file.
I'd like to ask rpm team: is there another (more verbose / more benevolent to spec file errors) way how to get build requirements from the spec file in python?
Dnf is overriding rpm default logging level / redirecting it someplace (sorry I forget the details). The log will tell you the details - this is what it looks like by default:
[pmatilai@sopuli ~]$ python -c 'import rpm; s = rpm.spec("foo.spec")'
error: Name field must be present in package: (main package)
error: Version field must be present in package: (main package)
error: Release field must be present in package: (main package)
error: Summary field must be present in package: (main package)
error: License field must be present in package: (main package)
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: can't parse specfile
There was the other similar bug about systemd.spec, which also becomes entirely obvious when the log messages come through:
[pmatilai@sopuli SPECS]$ python -c 'import rpm; s = rpm.spec("systemd.spec")'
error: Unable to open /srv/work/rpmbuild/SOURCES/triggers.systemd: No such file or directory
Traceback (most recent call last):
File "<string>", line 1, in <module>
ValueError: can't parse specfile
Back to dnf.
Thanks Panu. The log is supposed to be in /var/log/dnf.rpm.log. But it looks like builddep plugin is not logging anything there. I'll have to look into that. *** Bug 1560291 has been marked as a duplicate of this bug. *** PR https://github.com/rpm-software-management/dnf-plugins-core/pull/254 to redirect rpm library error to /var/log/dnf.rpm.log The issue is solved by dnf-plugins-core-3.0.1-1 that was released into rawhide. *** Bug 1663619 has been marked as a duplicate of this bug. *** |