RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1464139 - Some applications listed by gnome-software cannot be installed on big-endian architectures
Summary: Some applications listed by gnome-software cannot be installed on big-endian ...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-software
Version: 7.4
Hardware: ppc64
OS: Linux
high
high
Target Milestone: rc
: ---
Assignee: Richard Hughes
QA Contact: Desktop QE
Petr Bokoc
URL:
Whiteboard:
Depends On:
Blocks: 1477211 1649362
TreeView+ depends on / blocked
 
Reported: 2017-06-22 13:47 UTC by Martin Krajnak
Modified: 2019-07-24 14:48 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
*Application Installer* displays packages even though they can not be installed on big endian architectures When you use the *Application Installer* graphical package installer (the _gnome-software_ package) on a big-endian system such as IBM Power Systems or IBM z Systems, some of the packages listed as available will not be possible to install, and an attempt to do so results in an "installing not available" error message. This is a known issue caused by package metadata currently being generated only for 64-bit AMD and Intel-compatible (little-endian) systems, and assuming all packages are also available on big-endian architectures, which is not the case. There is no workaround to this problem; however, the error message has no consequences other than the package not being installable.
Clone Of:
Environment:
Last Closed: 2019-04-09 12:30:02 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
full log (678.87 KB, text/plain)
2017-06-22 13:47 UTC, Martin Krajnak
no flags Details
erro message screenshot (62.62 KB, image/jpeg)
2017-06-22 13:51 UTC, Martin Krajnak
no flags Details

Description Martin Krajnak 2017-06-22 13:47:00 UTC
Created attachment 1290726 [details]
full log

Description of problem:
There are several applications which are listed by gnome-software but cannot be installed.
I randomly found the following list of affected applications: brasero, bluefish editor, dia diagram editor and codeblocks. The affected architectures are s390x and ppc64.

Version-Release number of selected component (if applicable):
gnome-software-3.22.7-1.el7.ppc64

How reproducible:
always on mentioned architectures.

Steps to Reproduce:
1.run gnome-software 
2.search for brasero
3.click install

Actual results:
Eror message window: installing not available

Expected results:
Should install the application or application should not be listed if it is not available.

Additional info:
output (full log including 3 install fails is uploaded above) from gnome-software --verbose from the moment in which error has occured:

...
13:19:47:0856 As  run 0xaea28680~GsPlugin::provenance-license(gs_plugin_refine)
13:19:49:0772 As  run 0x3ffe4002770~GsPlugin::packagekit(gs_plugin_app_install)
13:19:49:0772 Gs  failed to call gs_plugin_app_install on packagekit: installing not available
13:19:49:0772 Gs  saving error for system/package/rhel-7/desktop/brasero.desktop/*: installing not available
13:19:49:0772 As  run 0x3ffe4002770~GsPlugin::shell-extensions(gs_plugin_app_install)
13:19:49:0772 As  run 0x3ffe4002770~GsPlugin::flatpak(gs_plugin_app_install)
13:19:49:0772 Gs  adding system/package/rhel-7/desktop/brasero.desktop/* as nothing matched hash
13:19:49:0772 Gs  adding system/package/rhel-7/desktop/brasero.desktop/* as nothing matched hash
...

In addition I tried:
[test@ibm-z-40 ~]$ pkcon install brasero
Resolving                     [                         ] (0%)  Package not found: brasero
Command failed: This tool could not find any available package: No packages were found

Comment 1 Martin Krajnak 2017-06-22 13:51:25 UTC
Created attachment 1290729 [details]
erro message screenshot

Comment 3 Richard Hughes 2017-07-03 11:01:23 UTC
This isn't a trivial bug. GNOME Software uses the AppStream data as a way of mapping between package name and application ID. Rather than checking a thousand things at startup, it assumes that "if a desktop file exists" then the component is installed. It also assumes that "if there's an appstream entry, then the component is install-able". This works well on the all the architectures I've tested.

The fly in the ointment is that the metadata is generated against x86_64, as it was *assumed* by me that all architectures would have the same set of applications available to install. Making this assumption means the generator takes ~2 hours to run rather than ~1 day.

I guess there are multiple ways to fix this:

 * start generating per-arch metadata
 * do not include gnome-software on s390x
 * find out (and fix) why some apps are not built on s390x

I'm happy helping with either option 1 or 2.

Comment 5 Kalev Lember 2018-02-16 09:28:08 UTC
This should be mostly fixed upstream with https://gitlab.gnome.org/GNOME/gnome-software/commit/be2b5970a3e1de08d59681b9c15b88d7cc4ce53e that hides apps that are in appstream metadata, but not actually available in repos.

There's still the issue of appstream metadata not being 100% correct as it's generated on different architecture, but that's something to fix another time I think.

Comment 6 Martin Krajnak 2018-07-19 08:39:02 UTC
I've tried to check today, the brasero is not longer listed by gnome-software , overall there are notably smaller amount of applications listed in every category so I think the fix was successful but I am not able to verify this because of bug 1591270

Comment 7 Martin Krajnak 2019-04-09 12:30:02 UTC
(In reply to Martin Krajnak from comment #6)
> I've tried to check today, the brasero is not longer listed by
> gnome-software , overall there are notably smaller amount of applications
> listed in every category so I think the fix was successful but I am not able
> to verify this because of bug 1591270

I am closing this, the amount of apps on s390x is so small that I can verify manually that all them are having rpms.
gnome-software-3.28.2-3.el7.s390x


Note You need to log in before you can comment on or make changes to this bug.