[Bug]: F: Failed to parse /var/lib/flatpak/appstream/gnome/x86_64/active/appstream.xml.gz file: Error on line 1906 char 29: <p> already set '

[blade1989]

Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a bug that matches the one I want to file, without success.
• If this is an issue with a particular app, I have tried filing it in the appropriate issue tracker for the app (e.g. under https://github.com/flathub/) and determined that it is an issue with Flatpak itself.
• This issue is not a report of a security vulnerability (see here if you need to report a security issue).

Flatpak version

1.12.7

What Linux distribution are you using?

Ubuntu

Linux distribution version

22.04.2 LTS

What architecture are you using?

x86_64

How to reproduce

Search for packages:

flatpak search firefox

Expected Behavior

Output of the package found or not found

Actual Behavior

flatpak search firefox
F: Failed to parse /var/lib/flatpak/appstream/gnome/x86_64/active/appstream.xml.gz file: Error on line 1906 char 29: <p> already set '
      Organic Maps is a free Android & iOS offline maps app for travelers,
      tourists, hikers, and cyclists.
      It uses crowd-sourced OpenStreetMap data and is developed with love by
      ' and tried to replace with ' ('
No matches found

Additional Information

Line 1906:

      <em>MapsWithMe</em> (<em>MapsMe</em>) founders and our community.

Lines surrounding line 1906:

      <p>
      Organic Maps is a free Android &amp; iOS offline maps app for travelers,
      tourists, hikers, and cyclists.
      It uses crowd-sourced OpenStreetMap data and is developed with love by
      <em>MapsWithMe</em> (<em>MapsMe</em>) founders and our community.
      No ads, no tracking, no data collection, no crapware.
      Your donations and positive reviews motivate and inspire us, thanks ❤️!
    </p>

[barthalion]

👋 @hughsie @ximion, this seems to be caused by Flathub's/flatpak-builder's switch to libappstream. Any idea if there's an easy fix for this? It's easily reproducible in a Docker container.

[ximion]

@barthalion I can't manage to reproduce this locally, which container base did you use? I've also been staring at the XML for minutes now and I can't seem to find any issues with it (it also validates just fine), so I think I need that whole file for some wider context.

[TCROC]

I am also getting this error on Pop OS (an Ubuntu derivative). Several users are also reporting the same thing here:

https://www.reddit.com/r/flatpak/comments/1423zv4/failure_to_parse_appstreamxmlgz_when_running/

[ximion]

Why am I not getting it? Do I need to enable a different Flathub repo than the main one? I'm on Debian 12, Flatpak 1.14.4
Would be nice to get my hands on that full XML file.

[ximion]

Aha, when switching to Flatpak 1.10.8 and Debian 11, I can reproduce this issue.
The XML is fine though, so I think this might be libappstream-glib on the older Flatpak versions that didn't switch to libappstream getting confused about the inline emphasis <em/> element.

Immediate solution for affected distributions would be to upgrade either Flatpak or appstream-glib:
Flatpak >= 1.13.1 and/or appstream-glib >= 0.8.0

I guess there is no way to deliver different metadata to older Flatpak versions, right?

[ximion]

I guess there is no way to deliver different metadata to older Flatpak versions, right?

I am asking because if we can't do that, then possibly the only solutions we have is to erase all inline markup from the metadata in a postprocessing step on the server. That means we would basically ban people from making proper use of it within Flatpak for many more years, until the older Flatpak/appstream-glib combinations are so dead that we are confident that nobody uses them anymore (this especially sucks because it will not only be limited to the current XML style elements, but also future ones that appstream-glib won't handle gracefully but libappstream would. And there's quite some demand for those...).

Alternatively, we could also ship a critical bugfix update to older Flatpak versions, give distributions some time to apply it, and then ignore everyone who hasn't shipped the bugfix to their users. Or, of course, try to play some server-side tricks, but given how Flatpak works I doubt we have many options there.

[barthalion]

:(

Immediate solution for affected distributions would be to upgrade either Flatpak or appstream-glib:
Flatpak >= 1.13.1 and/or appstream-glib >= 0.8.0

Stable distributions just won't. Ubuntu 22.04 comes with flatpak 1.12.7 and appstream-glib 0.7.18.

I guess there is no way to deliver different metadata to older Flatpak versions, right?

I think we would need to introduce a new appstream3/ branch, and then always generate the data for the current appstream2/ branch in appstream-glib compatible way.

Or, of course, try to play some server-side tricks, but given how Flatpak works I doubt we have many options there.

Unfortunately, it uses ostree to fetch it. So it becomes somewhat too complicated.

[ramcq]

Let's at least try and explore the process of running a SRU (stable release update) for 22.04 with a backported/targeted patch to make the older appstream-glib permissive to the new markup. It's a relatively small number of people to talk to and see what they think before we need to manage a giant transition and many years delay across the whole Flatpak ecosystem. I've pinged some folks on the #debian-gnome IRC channel.

In the meantime, is there any backport/PPA that brings a newer flatpak+appstream combo to 22.04 & derivs we can point to?

[Ansa211]

In the meantime, what's the recommended workaround for impatient users? I'm considering building the newest tagged version of flatpak from the code in this repo, following the instructions in CONTRIBUTING.md, but a backport/PPA as mentioned by @ramcq would of course be much more pleasant.

[ramcq]

In the meantime, what's the recommended workaround for impatient users? I'm considering building the newest tagged version of flatpak from the code in this repo, following the instructions in CONTRIBUTING.md, but a backport/PPA as mentioned by @ramcq would of course be much more pleasant.

The good news is that https://launchpad.net/~flatpak/+archive/ubuntu/stable?field.series_filter=jammy has Flatpak 1.14 for 22.04. The bad news is that 22.04 seems to have libappstream 0.15.2 and the Flatpak 1.14 release notes explicitly say that 0.15.3 should be used because of the fix for ximion/appstream#384. Perhaps @smcv or another kind soul would be able to update libappstream in this PPA so that we can direct 22.04 users to it. Maybe give it a try in the meantime and let us know if it helps even without that...

[ramcq]

Let's at least try and explore the process of running a SRU (stable release update) for 22.04 with a backported/targeted patch to make the older appstream-glib permissive to the new markup. It's a relatively small number of people to talk to and see what they think before we need to manage a giant transition and many years delay across the whole Flatpak ecosystem. I've pinged some folks on the #debian-gnome IRC channel.

To make this request more concrete/specific, it's a backport of hughsie/appstream-glib#403 plus hughsie/appstream-glib#446 (four commits total) which I believe will unblock older flatpak+appstream-glib using the updated metadata.

[Ansa211]

The good news is that https://launchpad.net/~flatpak/+archive/ubuntu/stable?field.series_filter=jammy has Flatpak 1.14 for 22.04. The bad news is that 22.04 seems to have libappstream 0.15.2 and the Flatpak 1.14 release notes explicitly say that 0.15.3 should be used because of the fix for ximion/appstream#384. Perhaps @smcv or another kind soul would be able to update libappstream in this PPA so that we can direct 22.04 users to it. Maybe give it a try in the meantime and let us know if it helps even without that...

I've been able to add the ppa, upgrade flatpak and now flatpak search runs.
As you mention, the release notes warn that

Libappstream should be updated to at least 0.15.3 to avoid critical warning messages when using the "flatpak search" command (ximion/appstream#384)

In line with the release notes, flatpak search produces more than 3100 lines like this one:

(flatpak search:90810): GLib-CRITICAL **: 11:07:21.441: g_once_init_leave: assertion 'g_atomic_pointer_get (value_location) == 0' failed

However, on my terminal, the actual output comes nicely at the end, so this is not a huge nuisance.

[ramcq]

Thanks for testing! That's a little unfortunate but we can recommend the PPA as an improvement at least. :)

[smcv]

Sorry, I don't use Ubuntu myself, other than for testing. Given that, the Flatpak PPA already soaks up more of my time than I can justify, so I am not willing to include backports of things like libappstream that are more likely to have an impact outside the immediate Flatpak ecosystem. If a PPA version of libappstream causes regressions in other components like Ubuntu Software, I will not be able to put in the necessary time to diagnose and fix those regressions.

If an Ubuntu developer can take over responsibility for the Flatpak PPA then that would be very welcome. If they do that, it's up to them to decide whether they are able to support a libappstream backport. It's intentionally set up as a "team" PPA on Launchpad instead of a personal repository, to avoid making me a mandatory single point of failure like Alex was for the older PPA.

I don't think PPAs should be a vehicle for fixing bugs: PPAs should be for feature enhancements and similar larger changes, and long-term-support distributions should take responsibility for doing bugfix-only updates to their supported packages where the risk/benefit ratio is good enough. https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/2006110 is a request for the Ubuntu developers to update their libappstream to a version that doesn't have the bug mentioned here (among other fixes). If people who have influence in Ubuntu can bring that to the attention of whoever is most appropriate, that would be very useful.

Let's at least try and explore the process of running a SRU (stable release update) for 22.04 with a backported/targeted patch to make the older appstream-glib permissive to the new markup

That would need a similar SRU bug report on Launchpad, but for appstream-glib rather than libappstream.

I'll try to propose an equivalent stable-update for the older appstream-glib in Debian 11. (But Debian 11 will be a considerably less interesting target to support after the Debian 12 release this Saturday!) The version in Debian 11 happens to be the same upstream release that's in Ubuntu 22.04, so that would be a good basis for an Ubuntu 22.04 SRU.

Debian 11 is still on Flatpak 1.10.x, and will stay on that branch forever because that's how LTS distributions' update policies work. If there was a targeted 1.10.x bugfix update for Flatpak to resolve this, then I'd look at getting that included that in Debian 11.8, but it seems like the correct place to resolve this particular problem is actually appstream-glib and not Flatpak, so there will probably not be any narrowly-targeted Flatpak change that can resolve this.

There is an official backport of Debian 12's Flatpak 1.14.x into Debian 11 (also maintained by me, in bullseye-backports) which should coincidentally avoid this failure mode by using libappstream instead of appstream-glib. I would recommend that official backport for anyone who is making heavy use of Flatpak on Debian, although more for its other features than anything else.

[ramcq]

Thanks @smcv, a Debian 11 SRU would be a great template for a corresponding Ubuntu 22.04 SRU and @seb128 has offered to sponsor into Ubuntu if we have a "this package / patch" baseline to start from. I believe the necessary libappstream-glib changes are identified in #5434 (comment) - let me know if I can help supply coffee, words of wisdom or moral support. :)

[ramcq]

I don't think PPAs should be a vehicle for fixing bugs: PPAs should be for feature enhancements and similar larger changes, and long-term-support distributions should take responsibility for doing bugfix-only updates to their supported packages where the risk/benefit ratio is good enough. https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/2006110 is a request for the Ubuntu developers to update their libappstream to a version that doesn't have the bug mentioned here (among other fixes). If people who have influence in Ubuntu can bring that to the attention of whoever is most appropriate, that would be very useful.

True; PPAs to work around or fix bugs are sadpanda. However this SRU, to my eyes, fails to make a compelling case as to why
"new version fix bugs!" for unspecified crashes/badness is worth the risk of changing anything, so it's unsurprising it's not been touched. The first comment from @ximion (despite best intentions) being "oh yeah and if you upgrade, unrelated bad shit will happen too!" is sure to not help either. The job of a SRM is to say no unless proven otherwise and the criteria for whether something is a critical bug worthy of an update is detailed on the Ubuntu wiki. @tintou is there something more specific you could add to this SRU to make the case to upgrade (even within the 0.15.x series) more compelling? What issue were you facing that motivated you to file it, with what frequency and severity? Ugly as it is, the errors spew from flatpak search doesn't necessarily count as a critical bug as the functionality does work.

[tintou]

This is the answer I had on #ubuntu-devel:

hi, you will need to subscribe ubuntu-sponsors and attach a debdiff? while even kinetic has a lower version it would require this SRU update first

But I'm lacking time to do this

[ramcq]

But I'm lacking time to do this

Sure, I mean - what was the specific problem or problems with 0.15.2 that motivated you to ask for an update? :)

[tintou]

I think (I haven't written why) that it was because ximion/appstream@b2649eb was hitting us at elementary but that's not something that is useful for an SRU as it only is a compile-time issue.

[ximion]

@smcv

I'll try to propose an equivalent stable-update for the older appstream-glib in Debian 11. (But Debian 11 will be a considerably less interesting target to support after the Debian 12 release this Saturday!)

Indeed, do you think creating backports for Flatpak/appstream to then-oldstable even makes sense?

@ramcq

The first comment from @ximion (despite best intentions) being "oh yeah and if you upgrade, unrelated bad shit will happen too!" is sure to not help either.

True, that was a warning for "if you go higher than that version" though - 0.15.6 should actually be a pretty safe upgrade.

TBH, all that's needed to fix this bug for now is to ensure these patches are applied to appstream-glib:

To make this request more concrete/specific, it's a backport of hughsie/appstream-glib#403 plus hughsie/appstream-glib#446 (four commits total) which I believe will unblock older flatpak+appstream-glib using the updated metadata.

It would be nice to have to upgrade Flatpak and AppStream packages to newer versions too, and that would also solve this bug, but that's not essential.
For AppStream versions <= 0.15.2, applying this patch would also be nice for Flatpak users: ximion/appstream@9003b09

I think all of these patches should be in the realm of acceptable SRU for Ubuntu. The version upgrades might be a tougher call to make, but Ubuntu upgraded to new minor releases before, so maybe there's a chance. That would really be extra work though, that's non-essential to fix this bug.

[ximion]

@smcv I am not using Ubuntu either, but I believe I could make that call (and do the work) of updating AppStream in that PPA, if you think that is a good idea. I've worked on Ubuntu's AppStream support with Canonical in the bast, so I believe I can ensure that such an update wouldn't break anything else (keeping the update minimal would also help).

So, if you think that sounds good, I could either send you a package to upload to the PPA, or you could allow Launchpad user ximion upload access to the PPA :-)

EDIT: Actually, this is even easier than I thought! The AppStream PPA, that I sometimes use for testing, has 0.15.4 for a long time already: https://launchpad.net/~ximion/+archive/ubuntu/appstream?field.series_filter=jammy
So that update is definitely already tested, and all I'd have to do is to avoid the Meson update (that should be doable).
Would allow for some fast band-aid for users until the issue is properly fixed with a SRU in Ubuntu.

[ramcq]

@smcv

I'll try to propose an equivalent stable-update for the older appstream-glib in Debian 11. (But Debian 11 will be a considerably less interesting target to support after the Debian 12 release this Saturday!)

Indeed, do you think creating backports for Flatpak/appstream to then-oldstable even makes sense?

Yes, it makes it very easy to copy into Ubuntu. 😁

TBH, all that's needed to fix this bug for now is to ensure these patches are applied to appstream-glib:

To make this request more concrete/specific, it's a backport of hughsie/appstream-glib#403 plus hughsie/appstream-glib#446 (four commits total) which I believe will unblock older flatpak+appstream-glib using the updated metadata.

👍

It would be nice to have to upgrade Flatpak and AppStream packages to newer versions too, and that would also solve this bug, but that's not essential. For AppStream versions <= 0.15.2, applying this patch would also be nice for Flatpak users: ximion/appstream@9003b09

I think all of these patches should be in the realm of acceptable SRU for Ubuntu. The version upgrades might be a tougher call to make, but Ubuntu upgraded to new minor releases before, so maybe there's a chance. That would really be extra work though, that's non-essential to fix this bug.

Given that jammy (0.15.2) and kinetic (0.15.5) have both got unmodified Debian imports of libappstream, and 0.15.6 was packaged for Debian, if you wanted to run debdiff or 0.15.2 -> 0.15.6 and 0.15.5 -> 0.15.6 and attach both to the Launchpad ticket @tintou opened, we can nudge Ubuntu folks for sponsorship. This is a relatively "low risk" upgrade as you point out - and Ubuntu has a polished incremental SRU roll-out machine so they might be amenable to doing it.

[smcv]

Indeed, do you think creating backports for Flatpak/appstream to then-oldstable even makes sense?

There are two very different things that could be described as "backports" and I'm not sure which one you mean.

For Debian 11 stable updates (the equivalent of Ubuntu's SRU process), I don't think anyone is proposing upgrading flatpak or appstream for this issue, because any change that is in-scope for a Debian 11 stable update wouldn't help. What I am proposing is upgrading appstream-glib (and only appstream-glib) with a targeted fix for this. Maintaining appstream-glib is not part of my job, so this will have to get in the queue with the other things I'm responsible for.

For the official Debian 11 backports repository bullseye-backports, which is like a very large PPA, it doesn't matter what I think: the policy says that after we've backported one version from Debian 12 into Debian 11 backports, we're expected to continue to backport all subsequent versions from Debian 12, until Debian 11 reaches EOL. Obviously since the Debian 12 freeze, the changes that are happening to the flatpak package in Debian 12 are small (bugfix-only), and therefore the changes that need to go into bullseye-backports are also small.

[ximion]

For the official Debian 11 backports repository bullseye-backports

Yes, I meant the literal backports repository - backporting a whole new version into Debian 11 as a stable update would be crazy, the release team would never agree to that (and it would be hard to maintain as well).

I could look into an appstream-glib targeted fix for Debian 11, but I am extremely stretched for time right now as well (even though addressing this issue does have a high priority for me), and with Debian 12 being available so soon, this doesn't have the highest priority for me either.

[ximion]

@tintou

I think (I haven't written why) that it was because ximion/appstream@b2649eb was hitting us at elementary but that's not something that is useful for an SRU as it only is a compile-time issue.

Yeah, that is really not very pragmatic GLib behavior, annoyingly, and it has bitten us so many times... I can hopefully implement a much better workaround for AppStream 1.0, as that release allows for API breaks and a bit more flexibility.

[ximion]

Given that jammy (0.15.2) and kinetic (0.15.5) have both got unmodified Debian imports of libappstream, and 0.15.6 was packaged for Debian, if you wanted to run debdiff or 0.15.2 -> 0.15.6 and 0.15.5 -> 0.15.6 and attach both to the Launchpad ticket @tintou opened, we can nudge Ubuntu folks for sponsorship. This is a relatively "low risk" upgrade as you point out - and Ubuntu has a polished incremental SRU roll-out machine so they might be amenable to doing it.

I went with the most conservative option, fixing only the issues which affect this bug. Hopefully this will translate into a faster review process and a quick update.

For appstream, I attached a patch to @tintou's report, so it should now be easy to test: https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/2006110
For appstream-glib I've created a new SRU request, to fix the root cause of this bug properly: https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/2023215

This should resolve the issue, no matter if you use the PPA or the version of Flatpak in Jammy - for Ubuntu, at least...

[harisanker10]

I tried https://launchpad.net/~flatpak/+archive/ubuntu/stable?field.series_filter=jammy and I'm on Flatpak 1.14.4 now. It kind of fixes the issue as (flatpak search:6689): GLib-CRITICAL **: 21:47:15.139: g_once_init_leave: assertion 'g_atomic_pointer_get (value_location) == 0' failed is shown multiple times before showing the actual search results.

[ximion]

@smcv Can you (or me, if I get permission) upload the AppStream version from https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/2006110 (well, a lower one, of course) to the Flatpak Stable PPA? That should create a nice workaround for users until Ubuntu updates appstream-glib in Jammy.

[smcv]

Can you (or me, if I get permission) upload the AppStream version from https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/2006110 (well, a lower one, of course) to the Flatpak Stable PPA?

Welcome to the team. Hopefully you should be able to upload there, using version 0.15.2-2flatpak1 or similar.

[ximion]

Welcome to the team. Hopefully you should be able to upload there, using version 0.15.2-2flatpak1 or similar.

Thank you, and done :-) And since 0.15.2-2flatpak1 << 0.15.2-2ubuntu0.1, as soon as Ubuntu uploads a fixed version, the one in the stable PPA should be automatically obsoleted.

[smcv]

There is an official backport of Debian 12's Flatpak 1.14.x into Debian 11 (also maintained by me, in bullseye-backports) which should coincidentally avoid this failure mode by using libappstream instead of appstream-glib

I've confirmed that this version works fine in an otherwise Debian 11 container.

For appstream-glib I've created a new SRU request, to fix the root cause of this bug properly

I opened a Debian 11 bug for this, and a proposed update with essentially the same changes as that SRU is now compiling.

[smcv]

This is not really a Flatpak bug at all, so it is not actionable as part of Flatpak, and I'm going to close this as "not planned" when we have finished coordinating fixes for LTS distributions.

The solution is to either:

• upgrade Flatpak to 1.14.x if possible, or
• upgrade appstream-glib to 0.8.1 or later if possible, or
• apply appstream-glib fixes (see https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/2023215) to an older version of appstream-glib.

If you upgrade to 1.14.x, seeing a lot of GLib-CRITICAL **: 21:47:15.139: g_once_init_leave: assertion 'g_atomic_pointer_get (value_location) == 0' failed is not a Flatpak bug either. It was a bug in libappstream, fixed by ximion/appstream#385.

[TCROC]

@smcv

and I'm going to close this as "not planned"

Wait I'm confused. Is FlatPak going to close this issue in a "won't fix" fashion? Or is action being taken somewhere else to fix it?

[smcv]

Is FlatPak going to close this issue in a "won't fix" fashion? Or is action being taken somewhere else to fix it?

Yes to both. This is a bug in Flatpak's dependencies, not a bug in Flatpak, so changing Flatpak will not fix it. Only fixing the dependencies will do that.

[TCROC]

Ah ok. I would consider that a "fix". I normally mark "won't fix" on issues that literally are not going to be fixed. So if you close it with that, maybe leave a clarifying comment?

Just a thought. Thanks again for the quick action!

[Chamrosh]

I encountered this issue while searching for a package as well.

F: Failed to parse /home/mohammad/.local/share/flatpak/appstream/flathub/x86_64/active/appstream.xml.gz file: Error on line 1960 char 29: <p> already set '
      Organic Maps is a free Android & iOS offline maps app for travelers,
      tourists, hikers, and cyclists.
      It uses crowd-sourced OpenStreetMap data and is developed with love by
      ' and tried to replace with ' ('
No matches found

Flatpak 1.12.7
Ubuntu Mate 22.04

[ximion]

I encountered this issue while searching for a package as well.

If you can't wait for a fix to land in Ubuntu proper, you can use the Flatpak stable PPA to resolve this:
sudo add-apt-repository ppa:flatpak/stable

[eduncan911]

I encountered this issue while searching for a package as well.

If you can't wait for a fix to land in Ubuntu proper, you can use the Flatpak stable PPA to resolve this: sudo add-apt-repository ppa:flatpak/stable

Confirmed, this worked flawlessly!

sudo add-apt-repository ppa:flatpak/stable
sudo apt update
sudo apt upgrade

And I can search now.

$ flatpak --version
Flatpak 1.14.4
$ flatpak search ...

[blade1989]

@ximion Thanks, that fixed it!

[nicolaslagiosrkpt]

The solution on my Debian 11 vm in Chrome OS was to edit /var/lib/flatpak/appstream/flathub/x86_64/active/appstream.xml with nano and replace every < code> and </ code> with nothing.

If I remember correctly I have also replace every < em> and </ em> with nothing.

After that I have remove the gz with sudo rm appstream.xml.gz

After that I have recreate the gz file by login as root with sudo su and the command gzip -c appstream.xml > appstream.xml.gz

and everything was back to normal

Do not try to remove the flatpak and reinstall it from git. This does not work.

The problem in my situation was the html elements I mention that was inside gunziped xml.

Kind Regards, NicolasLagios , MaxServices , Rocket-Path

[ximion]

@nicolaslagiosrkpt This means you have likely broken your local OSTree repository now and will have to repair your Flatpak installation with flatpak repair. This is not a good solution - please upgrade to Debian 12 or wait for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037214 to go through its tests and reach Debian 11 as a stable update instead.

[diamantopoulos12]

Just running into this on Rocky Linux 9.3. So is flatpaks position on this they are okay with breaking every LTS style distribution that will only take major version upgrades? This is unfortunate because it blocks many distributions from using flatpaks with the version that flatpak was shipped with. And therefore removes most of the benefit flatpak had to offer - being able to install on many different platforms. I think this decision should be reconsidered - or some type of workaround given (if its there please point me to it) that doesn't require me to enable an additional repository to upgrade flatpak.

For example I have Oracle Linux 7 systems that used this as well as Rocky Linux 9.3. Now I can't use flatpaks on either of those. I have only seen workarounds for debian based systems - nothing for rpm. And I can't find any rpms for updated flatpaks even on the flatpak website. Or directions how to build it.

[KJ7LNW]

+1 for Oracle Linux / Rocky / Alma 9.3 fixes.

It looks like this is may be "supported" by redhat (ie, its in appstream), so someone may need to open a RHEL bug.

[diamantopoulos12]

I found an open RHEL issue on this: https://issues.redhat.com/plugins/servlet/mobile#issue/RHEL-28856

[ximion]

This is not an issue with Flatpak, the problem is in one of its dependencies (appstream-glib).
There is two options to resolve this:

1. Upgrade Flatpak: Newer versions of Flatpak swap appstream-glib out for appstream which does not have this issue and includes some future-proofing as well.
2. Backport a fix to appstream-glib, as done for Ubuntu (LP: #2023215) and Debian (bug #1037214). Both bug reports have the necessary patch attached.

This issue was holding Flathub back from using any new metadata features for years, and at this point I think it was just assumed that everyone has rolled out either solution 1 or 2.