Running desktop-file-validate fails with error: /builddir/build/BUILDROOT/plasma-firewall-5.27.80-1.fc40.x86_64/usr/share/metainfo/org.kde.plasma.firewall.metainfo.xml: FAILED: • tag-invalid : stock icon is not valid [preferences-security-firewall] Thank you!
desktop-file-validate validates desktop files; this is an AppStream metainfo file. You want to be using appstreamcli validate on it.
My apologies. It was appstream-util I was running, not desktop-file-validate: + appstream-util validate-relax --nonet /builddir/build/BUILDROOT/plasma-firewall-5.27.80-1.fc40.x86_64/usr/share/metainfo/org.kde.plasma.firewall.metainfo.xml /builddir/build/BUILDROOT/plasma-firewall-5.27.80-1.fc40.x86_64/usr/share/metainfo/org.kde.plasma.firewall.metainfo.xml: FAILED: • tag-invalid : stock icon is not valid [preferences-security-firewall] Validation of files failed
Aha! But it's weird that we have `appstreamcli validate` and also `appstream-util validate` and they don't agree on whether the file is valid or not. I'm also confused by the assertion that the "preferences-security-firewall" icon isn't valid. It's a perfectly acceptable FDO-compatible icon name, and an icon by that name exists in Breeze, which is the icon theme that users are expected to be using or inheriting from when they see this software in Plasma. It's not really intended to work in GNOME or anywhere else. I did some digging and found https://github.com/hughsie/appstream-glib/issues/360. Apparently with `appstream-util validate` there's a whitelist of allowed icon names, and the purpose of this check is to encourage apps to ship with their own custom icons, rather than relying on icon themes. Richard Hughes says he's willing to whitelist anything in Hicolor and Adwaita, but makes no mention of Breeze or any other icon theme. I think it's somewhat uncool to see the preferences of GNOME project members creep into cross-desktop tools, as well as the idea of whitelisting GNOME stuff but not KDE stuff. As such, I think I can say that in KDE we don't consider this error to be an error. Notably, we validate our appstream files with `appstreamcli validate` which does not count it as an error. Maybe the real solution here is to remove the appstream metainfo file in the first place, as this software isn't really an app that a random user on a random distro and a random desktop environment can install and expect to work. Can you maybe bring that up at https://invent.kde.org/plasma/plasma-firewall/-/issues/ and reference the discussion here?
(In reply to Nate Graham from comment #3) > Aha! > > But it's weird that we have `appstreamcli validate` and also `appstream-util > validate` and they don't agree on whether the file is valid or not. I'm also > confused by the assertion that the "preferences-security-firewall" icon > isn't valid. It's a perfectly acceptable FDO-compatible icon name, and an > icon by that name exists in Breeze, which is the icon theme that users are > expected to be using or inheriting from when they see this software in > Plasma. It's not really intended to work in GNOME or anywhere else. > > I did some digging and found > https://github.com/hughsie/appstream-glib/issues/360. Apparently with > `appstream-util validate` there's a whitelist of allowed icon names, and the > purpose of this check is to encourage apps to ship with their own custom > icons, rather than relying on icon themes. Richard Hughes says he's willing > to whitelist anything in Hicolor and Adwaita, but makes no mention of Breeze > or any other icon theme. > > I think it's somewhat uncool to see the preferences of GNOME project members > creep into cross-desktop tools, as well as the idea of whitelisting GNOME > stuff but not KDE stuff. As such, I think I can say that in KDE we don't > consider this error to be an error. Notably, we validate our appstream files > with `appstreamcli validate` which does not count it as an error. > > Maybe the real solution here is to remove the appstream metainfo file in the > first place, as this software isn't really an app that a random user on a > random distro and a random desktop environment can install and expect to > work. > > Can you maybe bring that up at > https://invent.kde.org/plasma/plasma-firewall/-/issues/ and reference the > discussion here? First, I'm going to see if I can get as-util to include our stock icon names, and if that fails, then I'll go talk to them.
Similar on plasma-nano: + appstream-util validate-relax --nonet /builddir/build/BUILDROOT/plasma-nano-5.27.80-1.fc40.x86_64/usr/share/metainfo/org.kde.plasma.nano.desktoptoolbox.appdata.xml /builddir/build/BUILDROOT/plasma-nano-5.27.80-1.fc40.x86_64/usr/share/metainfo/org.kde.plasma.nano.desktoptoolbox.appdata.xml: FAILED: • tag-invalid : stock icon is not valid [plasma] (I didn't know if I should've open a duplicate ticket on that project or answered here. Let me know if I need to do the former.)
As far as I'm concerned, all occurrences of that are an upstream issue. See the discussion taking place in https://github.com/hughsie/appstream-glib/issues/360. Apparently the tool being used here is deprecated and it might be possible to replace it with a newer one that doesn't suffer from this issue.
I've added a MR to fix Plasma Firewall by changing the icon specified to firewall-config which exists in Breeze and hicolor. This will fix the issue as things shipped with Breeze will get the correct icon and those using hicolor will also get it. The icon is *EVER* so slightly different from the original but still conveys that it's firewall related. Search firewall in /usr/share/icons/breeze to see the two icons. firewall-config could also just be dropped in Breeze and symlink to the preferences-security-firewall icon, then it would be unified.