Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1802930
Summary: | unwanted output in quiet mode | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Remi Collet <fedora> |
Component: | mock | Assignee: | Copr Team <copr-team> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 31 | CC: | jdisnard, jkeating, mebrown, msuchy, philip.wyett, praiskup, williams |
Target Milestone: | --- | ||
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: | 2020-08-04 15:10:43 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
Remi Collet
2020-02-14 06:24:05 UTC
Or should I use something like config_opts['package_manager'] = 'dnf' config_opts['bootstrap_package_manager'] = 'yum' If works pretty well for RHEL-6 and RHEL-7 x86_64, cannot have it working for i386 ... INFO: Mock Version: 2.0 Start: yum install There was a problem importing one of the Python modules required to run yum. The error leading to this problem was: libelf.so.1: cannot open shared object file: No such file or directory ... 1) I think that warning should be print even in quiet mode. Just my opinion. 2) This warning means that you have package_manager set to 'yum' but your /usr/bin/yum is just symlink to /usr/bin/dnf-3 (via yum-dnf package), so you are in fact using dnf, despite your configuration. It may or not be an issue for you. So, what is the proper configuration to manage yum system (RHEL 6 or 7) from a dnf system (Fedora or RHEL 8) and to avoid this warning. And BTW, provided configuration are broken $ mock -r epel-6-x86_64 ... ... No matches found for the following disable plugin patterns: local, spacewalk BaseOS 1.9 MB/s | 8.6 MB 00:04 updates 2.0 MB/s | 14 MB 00:06 epel 2.8 MB/s | 12 MB 00:04 sclo 667 kB/s | 723 kB 00:01 sclo-rh 1.5 MB/s | 8.3 MB 00:05 No match for argument: dnf No match for argument: dnf-plugins-core Error: Unable to find a match: dnf dnf-plugins-core ... > 1) I think that warning should be print even in quiet mode. Just my opinion.
At least it should be removed in bootstrap case, where it is expected
RHEL-6 i386 issue solved on my side using config_opts['yum_install_command'] = 'install elfutils-libelf yum yum-utils' no idea why... BTW, to summarize, mock seems OK everywhere (provided config, and local ones), excepted this unwanted warning during the bootstrap phase (the reason of this bug report) Please review https://github.com/rpm-software-management/mock/pull/477 (In reply to Remi Collet from comment #5) > > 1) I think that warning should be print even in quiet mode. Just my opinion. > > At least it should be removed in bootstrap case, where it is expected I tend to disagree. Mock should use real 'yum' if it is available even for installing bootstrap chroot, it would be simply cleaner. But in your case, mock is "tricked" since yum isn't available -> and the warning is there to inform you that /bin/yum isn't really Yum. Do you need yum.rpm, or is that some leftover? (In reply to Remi Collet from comment #4) > So, what is the proper configuration to manage yum system (RHEL 6 or 7) from > a dnf system (Fedora or RHEL 8) and to avoid this warning. > > And BTW, provided configuration are broken > > $ mock -r epel-6-x86_64 ... > > ... > No matches found for the following disable plugin patterns: local, spacewalk > BaseOS > 1.9 MB/s | 8.6 MB 00:04 > updates > 2.0 MB/s | 14 MB 00:06 > epel > 2.8 MB/s | 12 MB 00:04 > sclo > 667 kB/s | 723 kB 00:01 > sclo-rh > 1.5 MB/s | 8.3 MB 00:05 > No match for argument: dnf > No match for argument: dnf-plugins-core > Error: Unable to find a match: dnf dnf-plugins-core > ... Not reproducible. You seem to have some non-standard configuration so mock thinks that dnf should be installed into el6/el7 bootstrap chroot. (In reply to Remi Collet from comment #4) > So, what is the proper configuration to manage yum system (RHEL 6 or 7) from > a dnf system (Fedora or RHEL 8) and to avoid this warning. Use the default configuration, and perhaps uninstall yum which triggers the additional warning (it wouldn't be printed if yum was real yum). Perhaps we should hide the warning when `dnf_warning=False`? Or maybe the PR/477 (ehnanced, flip "warning" to "debug" with bootstrap=True). I'm not sure. Maybe the warning indeed isn't that important. PR merged FEDORA-2020-e331425193 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-e331425193 FEDORA-EPEL-2020-5a84e15907 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 FEDORA-EPEL-2020-88ef4b4d66 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 mock-2.1-1.fc32, mock-core-configs-32.4-1.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d32d395e18 mock-2.1-1.el8, mock-core-configs-32.4-1.el8 has been pushed to the Fedora EPEL 8 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 mock-2.1-1.fc30, mock-core-configs-32.4-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-e331425193 mock-2.1-1.fc31, mock-core-configs-32.4-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-d952a70712 mock-2.1-1.el7, mock-core-configs-32.4-1.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component. mock-2.1-1.fc32, mock-core-configs-32.4-1.fc32 has been pushed to the Fedora 32 stable repository. If problems still persist, please make note of it in this bug report. mock-2.1-1.fc31, mock-core-configs-32.4-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. FEDORA-EPEL-2020-88ef4b4d66 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 FEDORA-EPEL-2020-5a84e15907 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 FEDORA-2020-e331425193 has been pushed to the Fedora 30 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-5a84e15907 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-88ef4b4d66 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-5a84e15907 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 FEDORA-EPEL-2020-88ef4b4d66 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 FEDORA-EPEL-2020-5a84e15907 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-5a84e15907 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-88ef4b4d66 has been pushed to the Fedora EPEL 7 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-88ef4b4d66 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. FEDORA-EPEL-2020-5a84e15907 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report. FEDORA-EPEL-2020-88ef4b4d66 has been pushed to the Fedora EPEL 7 stable repository. If problem still persists, please make note of it in this bug report. |