Bug 1915764
| Summary: | There are file conflicts in python3-gobject-base multilib packages | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Petr Zatko <pzatko> |
| Component: | pygobject3 | Assignee: | Tomas Popela <tpopela> |
| Status: | CLOSED ERRATA | QA Contact: | Tomas Pelka <tpelka> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 9.0 | CC: | dking, lbalhar, mhroncok, pviktori, tpelka, tpopela, walters |
| Target Milestone: | alpha | Keywords: | Reopened, Triaged |
| Target Release: | 9.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | pygobject3-3.40.1-6.el9 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-11-15 11:20:11 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: | |||
| Bug Depends On: | 2051483 | ||
| Bug Blocks: | 1898842 | ||
|
Description
Petr Zatko
2021-01-13 12:05:59 UTC
Petr, can you please retest this bug? Hi, retested with RHEL-9.0.0-20210208.6.Alpha with the file conflict still present: python3-gobject-base-3.38.0-3.el9.i686.rpm python3-gobject-base-3.38.0-3.el9.x86_64.rpm warning: /root/tmp.qrj0bdvbMV/rpms/python3-gobject-base-3.38.0-3.el9.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY file /usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc conflicts between attempted installs of python3-gobject-base-3.38.0-3.el9.i686 and python3-gobject-base-3.38.0-3.el9.x86_64 file /usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc conflicts between attempted installs of python3-gobject-base-3.38.0-3.el9.i686 and python3-gobject-base-3.38.0-3.el9.x86_64 Tomas, adding diffs of the files, hope it helps.
╰─> diff i686/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc x86_64/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc
Binary files i686/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc and x86_64/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc differ
╰─> diff i686.GLib.cpython-39.pyc.hex x86_64.GLib.cpython-39.pyc.hex
510c510
< 00001fd0: 0029 0272 6400 0000 fa01 7bfa 0129 fa01 .).rd.....{..)..
---
> 00001fd0: 0029 0272 6400 0000 da01 7bfa 0129 da01 .).rd.....{..)..
╰─> diff i686/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc x86_64/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc
Binary files i686/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc and x86_64/usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc differ
╰─> diff i686.GLib.cpython-39.opt-1.pyc.hex x86_64.GLib.cpython-39.opt-1.pyc.hex 1 ↵
510c510
< 00001fd0: 0029 0272 6400 0000 fa01 7bfa 0129 fa01 .).rd.....{..)..
---
> 00001fd0: 0029 0272 6400 0000 da01 7bfa 0129 da01 .).rd.....{..)..
Lumír, marshalparser should fix this, right? What's the best way to run it in Fedora right now? Yes, marshalparser should fix it. You can use it like this: - define %py_reproducible_pyc_path as a path you want .pyc files to be fixed in - BuildRequire: /usr/bin/marshalparser And the redhat-rpm-config/brp-fix-pyc-reproducibility script should fix the pyc files and remove the differences. Let me know if I can help you more. Hi, it seems that this issue is no longer present in the compose since our test did not detect it during RHEL-9.0.0-20210613.4 testing. (In reply to Petr Zatko from comment #6) > Hi, it seems that this issue is no longer present in the compose since our > test did not detect it during RHEL-9.0.0-20210613.4 testing. Oh, nice. Thank you Petr for the heads-up! Let me close the bug and we can reopen it if you will see it again. Tome, we have hit the issue with python3-gobject-base again: Version-Release number of selected component (if applicable): RHEL-9.0.0-20211211.3 python3-gobject-base-3.40.1-5.el9.i686 python3-gobject-base-3.40.1-5.el9.x86_64 Actual results: python3-gobject-base-3.40.1-5.el9.i686.rpm python3-gobject-base-3.40.1-5.el9.x86_64.rpm warning: /root/tmp.wW0M9zGnl5/rpms/python3-gobject-base-3.40.1-5.el9.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY file /usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.opt-1.pyc conflicts between attempted installs of python3-gobject-base-3.40.1-5.el9.i686 and python3-gobject-base-3.40.1-5.el9.x86_64 file /usr/lib/python3.9/site-packages/gi/overrides/__pycache__/GLib.cpython-39.pyc conflicts between attempted installs of python3-gobject-base-3.40.1-5.el9.i686 and python3-gobject-base-3.40.1-5.el9.x86_64 (In reply to Lumír Balhar from comment #5) > Yes, marshalparser should fix it. You can use it like this: > - define %py_reproducible_pyc_path as a path you want .pyc files to be fixed > in > - BuildRequire: /usr/bin/marshalparser > > And the redhat-rpm-config/brp-fix-pyc-reproducibility script should fix the > pyc files and remove the differences. > > Let me know if I can help you more. Is this supposed to work Lumir? Even with CRB and BUILDROOT enabled on current RHEL 9: [test@ibm-p8-kvm-03-guest-02 ~]$ sudo dnf install /usr/bin/marshalparser No match for argument: /usr/bin/marshalparser Error: Unable to find a match: /usr/bin/marshalparser Marshalparser is not included in Centos stream 9 / RHEL 9 because, at the time of package selection, nothing depended on it. We had plenty of time to add the package there but this bug has been closed without the proper solution proposed in comment#5. The byte-compilation process isn't deterministic which is probably the reason why the problem disappeared itself. We have to investigate the possibilities to add the package to RHEL 9. Not sure if this is possible to accomplish for 9.0. As a temporary solution, it might be possible to bundle marshalparser as an additional source of the package, however, brp-fix-pyc-reproducibility has the path hardcoded, so you would need to modify that script during build time. Something like:
cp %{_rpmconfigdir}/redhat/brp-fix-pyc-reproducibility .
sed -i s|/usr/bin/marshalparser/|$PWD/marshalparser_local|' brp-fix-pyc-reproducibility
%global __brp_fix_pyc_reproducibility %{_builddir}/%{buildsubdir}/brp-fix-pyc-reproducibility
It goes without saying that this is utterly untested. And horrible.
Thank you Lumir and Miro! Let's rather leave it as it is (aka broken) until some official way of fixing it will be implemented. I don't think that we have to fix this for 9.0.0. (In reply to Miro Hrončok from comment #14) > Fedora fix: https://src.fedoraproject.org/rpms/pygobject3/pull-request/4 The Fedora maintainers seem to have missed my PR completely. CCing them here. Marshalparser should be available in RHEL 9 soon, see https://bugzilla.redhat.com/show_bug.cgi?id=2051483 and https://errata.devel.redhat.com/advisory/94662 After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (pygobject3 bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:8352 |