Apparently, appstream-compose command (from libappstream-glib, not to be confused with the RPM by that name which provides the appstreamcli compose subcommand) does not recognize .svgz icons. This caused the kwave 24.12.0 flatpak to fail (note that this is after the kwave.svgz icon was renamed to org.kde.kwave.svgz via rename-icon, per flatpak requirements, but this shouldn't be flatpak specific):
appstream-compose
appstreamcli compose
rename-icon
Processing application org.kde.kwave (appstream-compose:329): As-DEBUG: 23:17:03.631: looking for appdata path '/chroot_tmpdir/work/build/files/share/appdata/org.kde.kwave.appdata.xml' (appstream-compose:329): GLib-GIO-DEBUG: 23:17:03.633: _g_io_module_get_default: Found default implementation dummy (GDummyProxyResolver) for ‘gio-proxy-resolver’ (appstream-compose:329): As-DEBUG: 23:17:03.634: looking for desktop path '/chroot_tmpdir/work/build/files/share/applications/org.kde.kwave.desktop' Error loading desktop file: Failed to find icon: Failed to find icon org.kde.kwave
Given KDE's propensity to .svgz, I'm actually surprised this didn't occur earlier, but this must be the first time such an icon didn't also have various sized .png as a backup.
In any case, while I have a workaround for the kwave flatpak, this is yet another sign that we need to finally move Fedora from libappstream-glib/appstream-* to appstream/appstreamcli*. In the meantime, this may affect the kwave RPM from showing up in Discover.
appstream-compose is not from appstream-glib... that's from appstream.
I meant the command, not the package:
$ rpm -q --whatprovides /usr/bin/appstream-compose libappstream-glib-0.8.3-2.fc41.x86_64 $ rpm -q --whatprovides /usr/libexec/appstreamcli-compose appstream-compose-1.0.2-4.fc41.x86_64
Well... that isn't confusing...
No not in the slightest... /s
kwave was fixed for 25.04 by https://invent.kde.org/multimedia/kwave/-/commit/76401f04c3f741ad5c615d6c5cd90d846ad6c9a0
Hopefully other KDE apps will learn from this. We still really do need to migrate to appstreamcli compose already, but that's another discussion entirely.
Metadata Update from @yselkowitz: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)