| Summary: | Apply a upstream patch to fix load builtin macro parsing error? | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jun Aruga <jaruga> |
| Component: | rpmlint | Assignee: | Tom "spot" Callaway <spotrh> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | fboucher, j, spotrh, tmz, twoerner |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | rpmlint-1.11-17.fc35 rpmlint-1.11-17.eln110 rpmlint-1.11-17.fc34 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-05-11 16:31:10 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: | |
|
Description
Jun Aruga
2021-05-11 11:30:23 UTC
> I am not sure which Fedora version is used in the Zuul CI. I think Fabien (fbo) is a right person to ask about Zuul CI. https://src.fedoraproject.org/user/fbo Could you tell me which Fedora's rpmlint RPM package or upstream rpmlint is used for the rpmlint check in Zuul CI? I built a copr with the upstream change backported to 1.11. Source: https://src.fedoraproject.org/fork/tmz/rpms/rpmlint COPR: https://copr.fedorainfracloud.org/coprs/tmz/rpmlint/ $ rpmlint ruby.spec ruby.spec:20: E: use-of-RPM_SOURCE_DIR ruby.spec:215: W: unversioned-explicit-provides bundled(ccan-build_assert) ruby.spec:216: W: unversioned-explicit-provides bundled(ccan-check_type) ruby.spec:217: W: unversioned-explicit-provides bundled(ccan-container_of) ruby.spec:218: W: unversioned-explicit-provides bundled(ccan-list) 0 packages and 1 specfiles checked; 1 errors, 4 warnings. It might be good to get some additional testing to ensure I didn't introduce any issues. I'll file a PR for review. (In reply to Jun Aruga from comment #1) > > I am not sure which Fedora version is used in the Zuul CI. > > I think Fabien (fbo) is a right person to ask about Zuul CI. > https://src.fedoraproject.org/user/fbo > > Could you tell me which Fedora's rpmlint RPM package or upstream rpmlint is > used for the rpmlint check in Zuul CI? On FZCI we are using Fedora33 container for this job. So using this version rpmlint-1.11-16.fc33.src.rpm. We can try a new version in the Zuul w/o the change published in the Fedora compose. To do that open a PR on https://pagure.io/zuul-distro-jobs/blob/master/f/roles/rpm-lint/tasks/main.yaml to use the copr repo to install rpmlint. Then on the ruby PR add in the initial message of the PR this line: Depends-on: https://pagure.io/zuul-distro-jobs/pull-request/16 (I guess you'll get the 16 :) And hopefully the rpm-linter job should run with the rpmlint from copr. (In reply to Todd Zullinger from comment #2) > I built a copr with the upstream change backported to 1.11. > ... > It might be good to get some additional testing to ensure I didn't introduce > any issues. I'll file a PR for review. Thanks! To be precisely, the error does not happen with `%{?load:%{foo}}` on the current rpms/ruby rawhide, because it hides the error. But this syntax does not work on the latest RPM on rawhide any more. The error happens with `%{load:%{foo}}` when applying the following PR to fix the current build FTBFS. https://src.fedoraproject.org/rpms/ruby/pull-request/86 Here is a minimal reproducer to check the error. https://github.com/junaruga/report-rpmlint-load FEDORA-2021-2cead523fe has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-6b19cf6067 has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report. FEDORA-2021-e9d4b61274 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e9d4b61274 (In reply to Jun Aruga from comment #5) > Thanks! To be precisely, the error does not happen with `%{?load:%{foo}}` on > the current rpms/ruby rawhide, because it hides the error. But this syntax > does not work on the latest RPM on rawhide any more. The error happens with > `%{load:%{foo}}` when applying the following PR to fix the current build > FTBFS. > https://src.fedoraproject.org/rpms/ruby/pull-request/86 > > Here is a minimal reproducer to check the error. > https://github.com/junaruga/report-rpmlint-load Thanks. With rpmlint-1.11-17, that passes: $ rpmlint test.spec 0 packages and 1 specfiles checked; 0 errors, 0 warnings. (In reply to Fabien Boucher from comment #4) > On FZCI we are using Fedora33 container for this job. So using this version > rpmlint-1.11-16.fc33.src.rpm. I'll push an f33 update as well as the f34 update which very Tom kindly merged, built, and pushed. FEDORA-2021-e9d4b61274 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e9d4b61274` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e9d4b61274 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. > I'll push an f33 update as well as the f34 update which very Tom kindly merged, built, and pushed.
Thanks! I appreciate your work!
@fbo Fabien, After merging the PR https://src.fedoraproject.org/rpms/ruby/pull-request/86 to rawhide, I executed the Zuul CI for another PR. Then I see the parsing error by rpmlint is gone. Did you already fix it on Zuul CI, right? https://src.fedoraproject.org/rpms/ruby/pull-request/85#comment-74696 Fabien, I have a suggestion. Could you print the rpmlint RPM version and/or `rpmlint --version` on the Zuul CI? Note the rpmlint 2.0 will come soon on the upstream with breaking changes. It seems the rpmlint 2.0 prints the version in the result. But printing version by `rpmlint --version` is still useful. I tested on the latest master `c25c5eacf8122bdc92ba2f481e42d46803b11906` in the upstream rpmlint: https://github.com/rpm-software-management/rpmlint.git . And I detected new errors/warnings. ``` (venv) $ rpmlint --version 2.0.0 (venv) $ rpmlint --file ruby.rpmlintrc ruby.spec usage: rpmlint [-h] [-V] [-c CONFIG] [-e EXPLAIN [EXPLAIN ...]] [-r RPMLINTRC] [-v] [-p] [-i INSTALLED [INSTALLED ...]] [-t] [-T] [-s | -P] [rpmfile ...] (venv) $ rpmlint -r ruby.rpmlintrc ruby.spec ======================================== rpmlint session starts ======================================== rpmlint: 2.0.0 configuration: /home/jaruga/git/rpmlint/venv/lib64/python3.9/site-packages/rpmlint/configdefaults.toml rpmlintrc: ruby.rpmlintrc checks: 26, packages: 1 ruby.spec: W: no-cleaning-of-buildroot %clean ruby.spec: W: no-buildroot-tag ruby.spec: E: lib-package-without-%mklibname ========= 0 packages and 1 specfiles checked; 1 errors, 2 warnings, 1 badness; has taken 0.1 s ========= ``` It's probably best if we don't get too off-topic here with rpmlint-2.0 discussion. :) But I believe the new error/warnings you saw would be ignored if you passed `-c $PATH_TO_RPMLINT_2.0/configs/Fedora` to rpmlint. FEDORA-2021-e9d4b61274 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report. > It's probably best if we don't get too off-topic here with rpmlint-2.0 discussion. :)
Todd, you are right. This ticket is for the topic "load builtin macro parsing error". Sorry about that. Thanks for the info about ignoring the error/warnings. Let's talk somewhere else if we need to talk off-topic.
Fabien (fbo), we see the following rpmlint errors happening again on Zuul CI. I thought Zuul CI is using the patched version of rpmlint. https://src.fedoraproject.org/rpms/ruby/pull-request/85#comment-75478 ``` ./ruby.spec: E: specfile-error error: ./ruby.spec: line 116: failed to load macro file /tmp/rpmlint.ruby.spec.hie40014/macros.ruby ./ruby.spec: E: specfile-error error: query of specfile ./ruby.spec failed, can't parse ``` |