libappstream regression: Flathub generates invalid remote icon entry #4222
Comments
|
They are relative now, there is a media base url (I'm actually not sure, it might get stripped right now) on one of the root elements We handle this hardcoded on the website for now flathub-infra/website@f740030#diff-9985c8101c5c6fdd34d0bed35f279f01d429eee5f739521c86e114335c3e1fcbR64 |
|
I think it's missing in here. (The version number also seems sus.) <components version="0.8" origin="flatpak"> |
|
Bart is aware, but there's a state holiday and he has a vacation day tomorrow |
|
gnome-software bug https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2196 The paths look odd too, and they care not valid with added The same applies also to |
|
The base path should be |
|
I see. That explains why it did not work for me. It was only a guess from my side. |
bilelmoussaoui
added
the
appstream
|
If flatpak-builder or whatever runs |
|
This should be solved by flathub/org.flatpak.Builder@3bacdbb Everything should be relative to the mirror URL @sophie-h can you please retrigger a build, so that the catalogue data gets composed with libappstream now and check? |
Hm, why should they be relative if the linked patch adds |
|
I meant to say they will be complete URLs starting with https://dl.flathub.org/media/ the current |
|
Yes, seems to work. The only app with a relative URL is a leftover from the previous transition to libappstream |
|
I'm still encountering this issue with some flathub apps. |
|
Where? |
In the "list" view, in Gnome Software (45.3), on apps like Kdenlive, Discord or Extension manager (on the detailed app page, the icon shows fine). |
Can you open a separate issue for this? This is unrelated to the issue here. It seems libappstream is giving only 128px now, 64 px icons are gone from the server. flatpak can't download it anymore in the appstream cache. The list view depends on a 64px icon. @ximion, any idea what to do here? |
Do you apply any odd configuration to appstreamcli? What is its full command-line? |
|
|
Okay, that command-line looks good. A 64x64px icon should always be generated unconditionally, if it isn't there, compose should fail. So I guess the next thing would be to examine the output of that command (not sure how I could test that, but maybe I could have a look later, maybe tomorrow). |
You can manually run the compose step. This should be roughly equivalent. diff --git a/com.discordapp.Discord.json b/com.discordapp.Discord.json
index 6c9dd79..bbada2d 100644
--- a/com.discordapp.Discord.json
+++ b/com.discordapp.Discord.json
@@ -7,6 +7,7 @@
"sdk": "org.freedesktop.Sdk",
"command": "com.discordapp.Discord",
"separate-locales": false,
+ "appstream-compose": false,
"tags": [
"proprietary"
],
@@ -62,9 +63,12 @@
"install -d /app/share/applications",
"sed -e 's/Icon=discord/Icon=com.discordapp.Discord/' -e 's|Exec=/usr/share/discord/Discord|Exec=com.discordapp.Discord|' /app/discord/discord.desktop > /app/share/applications/${FLATPAK_ID}.desktop",
"install -Dm644 /app/discord/discord.png /app/share/icons/hicolor/256x256/apps/${FLATPAK_ID}.png",
- "install -Dm644 com.discordapp.Discord.appdata.xml /app/share/appdata/com.discordapp.Discord.appdata.xml",
+ "install -Dm644 com.discordapp.Discord.appdata.xml /app/share/metainfo/com.discordapp.Discord.appdata.xml",
"patch-desktop-filename ${FLATPAK_DEST}/discord/resources/app.asar"
],
+ "post-install": [
+ "appstreamcli compose --verbose --no-partial-urls --prefix=/ --origin=${FLATPAK_ID} --media-baseurl=https://dl.flathub.org/media/ --media-dir=${FLATPAK_DEST}/share/app-info/media --result-root=${FLATPAK_DEST} --data-dir=${FLATPAK_DEST}/share/app-info/xmls --icons-dir=${FLATPAK_DEST}/share/app-info/icons/flatpak --components=${FLATPAK_ID}.desktop ${FLATPAK_DEST}"
+ ],
"sources": [
{
"type": "archive",It seems to be generated but not put into |
That is expected, I think - only stuff that is to be served from a remote location ends up in |
|
So one issues is, appstream is generating the cached icon entry as https://dl.flathub.org/repo/appstream/x86_64/icons/64x64/com.discordapp.Discord.png is there but https://dl.flathub.org/repo/appstream/x86_64/icons/64x64/com.discordapp.Discord.desktop.png is not. This seems to affect applications with appstream id ending in I'm not sure why flatpak's appstream cache is missing |
|
So seems like it is hitting https://github.com/flatpak/flatpak/blob/f9cbfe1fd67b608b0df1f3f1c333e2b972fda225/common/flatpak-utils.c#L5311-L5312 then https://github.com/flatpak/flatpak/blob/f9cbfe1fd67b608b0df1f3f1c333e2b972fda225/common/flatpak-utils.c#L5209-L5210 because that's what I locally get when generating the appstream ref: I guess Flathub has it in some kind of cache but I guess appstream-glib ignored the ID and generated icons with |
|
This seems hard to solve, maybe applications can change the There is an apparent disconnection between |
|
Yeah, compose will always use the current component-ID for the icon name, verbatim without changing it. We had some issues in the past when compose tried to be a bit too clever with it, so just using the name was the result :-) Why doesn't the builder tool enforce that $FLATPAK_ID == appstream-component-ID? |
Seems for compat flatpak/flatpak-builder@7292b2d |
Appstreamcli creates icons following the component id instead of $FLATPAK_ID but Flatpak ignores it because it doesn't match $FLATPAK_ID when copying the icons to appstream ref. So the ref is missing 64px and 128px icons entirely for the app. This makes GNOME software show a blank icon in list view because it looks up icons from flatpak's appstream cache. Make both match and link older IDs with replaces and provides. See flathub/flathub#4222 (comment)
|
This is the list of affected apps: Apps |
which is 370, +/- 1. |
Brr... That's an amount that would definitely warrant some kind of workaround, fixing that for every app would be a significant effort :-/ All of this really should be a different bug though, the issue here is actually something completely different that has been fixed already. |
|
you should know that NOW flatpak-builder does fix the app-id on |
|
Renaming the component-ID is pretty evil - but if we could do it only once to get rid of this discrepancy, I'd be all for it! |
|
As I mentionned in a different channel, there were 2022 blog post reviewed by people in the know that still used the The reason I implemented the rename in flatpak-builder is because otherwise it's very painfull to fix it as there is not tooling to "edit" the appstream file. (appstream-glib has a "modify" that would work for this, but it's being phased out). |
|
I'd be fine with adding a feature to edit MetaInfo files to But is there anything that speaks against the solution outlined at the very bottom of #4222 (comment)? Does Flatpak maybe require the icon name to match the FLATPAK_ID? (that would require us to search for a new solution - I do have some more ideas then though ^^). |
Icons can match |
In that case, and if I understand the problem correctly, this may actually be pretty trivial to resolve :-) |
|
What is stopping from dropping this line https://github.com/flatpak/flatpak/blob/f1088e3013adc5010012e16d060178b0f1d48226/common/flatpak-utils.c#L5311-L5312 to fix the issue? I don't think it regresses anything and will fix the issue here. This was introduced for an even rarer appstream ID ie. two In case of two I think we can add a check in linter to make sure no such double |
I think this would work, and would be a fairly easy solution. I just checked the 2792 components in Debian's repository, none has a
That also sounds like a really good idea :-) In combination, this should avoid the same issue in future, while also not introducing too much (or any!) breakage. |
See the second issue discussed in flathub/flathub#4222 (comment)
This will pass the exact appstream component ID to copy_icon This was introduced in flatpak@7dd92d8 to handle appstream component IDs that ended in two `.desktop` suffixes. Recent analysis of appstream data shows that on Flathub no such appstream cid exists anymore and Telegram has component ID `com.telegram.desktop` now. With the switch to libappstream, appstreamcli-compose produces icons in `share/app-info/flatpak` named by the appstream component ID instead of the `$FLATPAK_ID` used by appstream-glib. This causes applications whose `$FLATPAK_ID` does not end with `.desktop` but their appstream-component ID ends in `.desktop` ie. `$FLATPAK_ID != appstream-cid` to loose icons from the appstream ostree ref as `copy_icon` was being fed the id without `.desktop` but icons were created by appstreamcli with `.desktop` in them. This will avoid adding anymore ID heuristics/workarounds on either side, per the discussion in flathub/flathub#4222 An application with `$FLATPAK_ID` `com.telegram.desktop` and appstream ID `com.telegram.desktop.desktop` will be broken with this change but such dual `.desktop` IDs are non existent and should be fixed individually or be blocked on an app store level.
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
|
PRs opened, the flatpak PR has the repro steps. I'll wait for others to chime in. I won't deploy anything to Flathub, until bart returns from vacation. |
|
Thanks a lot! :-) Having just one ID for an app will help us greatly in future, I believe. |
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
See the second issue discussed in flathub/flathub#4222 (comment)
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
For historical reasons flatpak-builder passes ``$FLATPAK_ID.desktop` as a valid component ID to appstreamcli. This mismatch creates issues like the one described in flatpak/flatpak#5752 and flathub/flathub#4222 So require that both match and avoid new submissions leaking in with a mismatch.
|
Flathub should no longer accept What remains is getting one of the Flatpak patches merged, getting it backported to Flatpak 1.14.x, getting a new release and getting a PPA build - then it can be deployed to the Flathub servers running Ubuntu. |
Bold claim in the issue title, but generating apps.gnome.org is broken since Jun 6, 2023 6:16am GMT+0200. The reason is an unexpected value in
type="remote"for icons.https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-icon
So rust appstream refuses the
app/drey/EarTag/...value in the example below:The text was updated successfully, but these errors were encountered: