Bug 1765611
Summary: | Can't install brltty.i686 on RHEL 8.1 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Michal Bocek <mbocek> |
Component: | brltty | Assignee: | aegorenk |
Status: | CLOSED ERRATA | QA Contact: | Ondrej Mejzlik <omejzlik> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.1 | CC: | aegorenk, jskarvad, mreznik, omejzlik, psklenar |
Target Milestone: | rc | Keywords: | Patch, TestCaseNotNeeded, Triaged, Upgrades |
Target Release: | 8.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2021-05-18 15:24:15 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: | 1854905 | ||
Bug Blocks: | 1771008, 1894575 |
Comment 1
Michal Bocek
2019-10-25 15:16:33 UTC
*** Bug 1666723 has been marked as a duplicate of this bug. *** I'd like to point out that this issue is not just about failing TPS tests but mainly, and that is the reason I filed this bug, this bug causes the upgrade from RHEL 7 to RHEL 8 to fail as I point out in https://bugzilla.redhat.com/show_bug.cgi?id=1765611#c1. There are these options: 1) You resolve this bug by going through the "major redesign" of brltty 2) We remove the brltty actor [1] from LEAPP and instruct Leapp to remove brltty during the upgrade to prevent the failure 3) (least favourable) you update the actor in a way that it detects that the brltty.i686 is installed and inhibits the upgrade Michal Reznik, in https://github.com/oamg/leapp-repository/pull/372#pullrequestreview-306832595 we've identified 6 packages that block the upgrade. Out of them, three are still not fixed. It's this one, then gnome-online-accounts-devel [2] and geocode-glib-devel [3]. Please create Jira tasks under which we'll track the progress. My recommendation would be to remove all these packages during the upgrade until they are fixed. [1] https://github.com/oamg/leapp-repository/pull/196 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1765627 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1765629 (In reply to Michal Bocek from comment #18) > I'd like to point out that this issue is not just about failing TPS tests > but mainly, and that is the reason I filed this bug, this bug causes the > upgrade from RHEL 7 to RHEL 8 to fail as I point out in > https://bugzilla.redhat.com/show_bug.cgi?id=1765611#c1. > There are these options: > 1) You resolve this bug by going through the "major redesign" of brltty > 2) We remove the brltty actor [1] from LEAPP and instruct Leapp to remove > brltty during the upgrade to prevent the failure > 3) (least favourable) you update the actor in a way that it detects that the > brltty.i686 is installed and inhibits the upgrade > > Michal Reznik, in > https://github.com/oamg/leapp-repository/pull/372#pullrequestreview- > 306832595 we've identified 6 packages that block the upgrade. Out of them, > three are still not fixed. It's this one, then gnome-online-accounts-devel > [2] and geocode-glib-devel [3]. > Please create Jira tasks under which we'll track the progress. My > recommendation would be to remove all these packages during the upgrade > until they are fixed. > > [1] https://github.com/oamg/leapp-repository/pull/196 > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1765627 > [3] https://bugzilla.redhat.com/show_bug.cgi?id=1765629 I think there is no point of changing brltty configuration files, documentation and the way how it handles drivers just to support co-existence of 32bit an 64bit. Especially if the 32 bit is phasing out. Now, after the update, it should be possible to install 32 bit version of brltty. If you want both version of brltty packages installed - i.e. 32 bit and 64 bit, it's not supported. Also please note brltty itself is not library, so it doesn't qualify for multilib. For me the most clean solution is 3). If customer is upgrading to unsupported configuration, just inhibit the upgrade and let admin to cope with the situation. I don't think we should drop the actor just because of this possible 32 bit/64 bit conflict. 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 (brltty 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-2021:1765 |