Description of problem: Epiphany is missing appstream data to be discoverable in Gnome Software Version-Release number of selected component (if applicable): epiphany-44.0-1.fc38.x86_64 in F38 epiphany-43.1-1.fc37.x86_64 in F37 Steps to Reproduce: 1. In Fedora 37 or 38, start Gnome Software, 2. search "web" or "epiphany" Actual results: Only flatpaks from fedora and flathub remote are showing Expected results: Epiphany/Web as rpm package should be shown too, especially since for F38 it's newer than the flatpak from fedora's flatpak registry
I don't know how to debug this, but I tried: $ appstreamcli validate org.gnome.Epiphany.appdata.xml I: org.gnome.Epiphany.desktop:283: nonstandard-gnome-extension kudos I: org.gnome.Epiphany.desktop:350: url-not-secure http://www.gnome.org/friends/ E: org.gnome.Epiphany.desktop:360: custom-key-duplicated Purism::form_factor I: org.gnome.Epiphany.desktop:~: desktop-app-launchable-omitted ✘ Validation failed: errors: 1, infos: 3, pedantic: 2 So... maybe the duplicate Purism key is the problem? <custom> <value key="Purism::form_factor">workstation</value> <value key="Purism::form_factor">mobile</value> </custom> That's my only guess. Hey Milan, am I on the right track here? Or is there some other tool that I should be using to figure out what GNOME Software does not like?
in https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-custom it says: "The key must be unique; multiple keys with the same name are not allowed."
<quote> Note Before using a custom tag, please consider if there is a better way to achieve your goal than adding the data to the AppStream metainfo file, or whether AppStream maybe already contains a way to achieve what you want. Additionally, if you think that the purpose you use the custom tag for is generally useful, please file a feature request against AppStream, so we can discuss adding the new feature to the specification and make it more usable for a bigger audience. </quote>
Looking into an epiphany-43.1-1.fc37.x86_64.rpm, it does provide org.gnome.Epiphany.appdata.xml. You can view it in the gnome-software with: gnome-software --show-metainfo=/tmp/org.gnome.Epiphany.appdata.xml The problem is elsewhere. When you check the content of /usr/share/app-info/xmls/fedora.xml.gz, you'll realize the Epiphany application is not mentioned there at all, which means the gnome-software doesn't know the Epiphany exists. That file is under appstream-data hands, if I'm not mistaken.
*** Bug 2184124 has been marked as a duplicate of this bug. ***
(In reply to Milan Crha from comment #4) > The problem is elsewhere. When you check the content of > /usr/share/app-info/xmls/fedora.xml.gz, you'll realize the Epiphany > application is not mentioned there at all, which means the gnome-software > doesn't know the Epiphany exists. That file is under appstream-data hands, > if I'm not mistaken. And... you're confident this is not because the metadata is invalid...? Because that seems like a pretty likely cause for the metadata to be dropped, right...?
I've no idea how the appstream-data is populated. Running: $ appstream-util validate-strict /usr/share/metainfo/org.gnome.Epiphany.appdata.xml returns: /usr/share/metainfo/org.gnome.Epiphany.appdata.xml: FAILED: • tag-invalid : XML data contains unknown tag • style-invalid : <image> has vertical padding [https://gitlab.gnome.org/GNOME/epiphany/raw/HEAD/data/screenshot.png] • style-invalid : <image> has horizontal padding [https://gitlab.gnome.org/GNOME/epiphany/raw/HEAD/data/screenshot.png] • aspect-ratio-invalid : <screenshot> aspect ratio not 16:9 [https://gitlab.gnome.org/GNOME/epiphany/raw/HEAD/data/screenshot.png] Validation of files failed and for "validate" (instead of "validate-strict") only the style-invalid is shown. I get the same failure for /usr/share/metainfo/org.gnome.Evolution.appdata.xml, which is part of the fedora.xml.gz.
appstreamcli (newer, from appstream) is stricter than appstream-util (older/disfavored, from appstream-glib). Software is porting away from appstream-util.
(In reply to Michael Catanzaro from comment #1) > So... maybe the duplicate Purism key is the problem? > > <custom> > <value key="Purism::form_factor">workstation</value> > <value key="Purism::form_factor">mobile</value> > </custom> Something else must be wrong here. I tested with several apps and confirmed that other apps with this same problem do appear in Software, so we must not be using appstreamcli to validate the appdata yet. (In reply to Milan Crha from comment #7) > and for "validate" (instead of "validate-strict") only the style-invalid is > shown. I get the same failure for > /usr/share/metainfo/org.gnome.Evolution.appdata.xml, which is part of the > fedora.xml.gz. OK, so it's not that either. Huh.
What you really need to know is how the appstream-data is populated. After that it'll be easier to figure out what precisely failed in that process for the Epiphany.
The problem is missing icon, which is fixed by https://src.fedoraproject.org/rpms/epiphany/c/e2b154e6babae57bfbd447eef21d4c0c1d21b80d?branch=f37 but not yet built. I'll start a build. It's already fixed in F38 metadata, but more recently than the last metadata push. So, Richard has started a metadata push. That should immediately fix F38. For F37, we need to wait until my Epiphany update goes stable, then rebuild and sync metadata. At least, I think that's what's going on.
FEDORA-2023-ec5e418618 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ec5e418618
FEDORA-2023-ec5e418618 has been pushed to the Fedora 37 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-ec5e418618` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ec5e418618 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-ec5e418618 has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
So although this bug is already closed by the Epiphany update, it won't actually be fixed until the metadata update that is being completed today.