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.

Cloning this to RHEL 7 as well where the exact same reasons apply for rebasing.


+++ This bug was initially created as a clone of Bug #1748276 +++

We should update the flatpak in RHEL8 (1.0.6) to the current stable series 1.4.x

The major changes since the 1.2.x is the improved I/O use for system-installed applications, and the new format for pre-configured remotes.

--- Additional comment from Kalev Lember on 2019-09-19 11:05:12 UTC ---

It would be good to bump this up to RHEL 8.1.1. The new flatpak version has important fixes that are needed for new flatpak runtimes that are getting deployed to flathub just now.

--- Additional comment from Alexander Larsson on 2019-09-19 11:11:47 UTC ---

One important feature we want (that landed in 1.4.2) is the support for extra_data for runtime extensions (previously it was for apps only). The main usecase for this is the openh264 extension which contains the cisco-blessed openh264 decoder. We need that to use extra_data for legal (patent grant) reasons.

We're actually interested in using this particular extension for the fedora runtime too, so that e.g. a fedora-based firefox flatpak can support h264 videos.

After some more irc discussion with alex and mclasen, there's a fair bit of urgency for getting the fixes out. Here's a new plan:

1) Do a Z stream update for both RHEL 7 and 8, shipping flatpak 1.0.9 (Alex Larsson is doing a 1.0.9 release just for RHEL with targeted backports). I've updated the ticket title to reflect this.

If it's necessary (if 1.0.x version updates aren't at all allowed in Z stream), we can just "fake" the 1.0.9 version (there's a server side check that makes sure the client is at least version 1.0.9) and backport the patches. I'd much prefer doing an update to 1.0.9 in Z though to make things easier and less error prone.

2) Rebase to 1.4.x for RHEL 8.1.1

As per IRC discussion with jwb and others, we'd prefer updating to new 1.0.9 version in Z stream instead of doing patch backports. The reason for this is that flathub has a client version check, which checks that the flatpak client is at least version 1.0.9. We could somehow fake the version with patch backports, but it would be much, much cleaner to just update to 1.0.9 (especially since it's just important fixes backported, no ABI changes and no new features).