Bug 2182874 - Epiphany rpms not providing appstream data to Gnome Software
Summary: Epiphany rpms not providing appstream data to Gnome Software
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: epiphany
Version: 38
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Michael Catanzaro
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 2184124 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-03-29 20:57 UTC by Flo
Modified: 2023-06-09 13:36 UTC (History)
12 users (show)

Fixed In Version: epiphany-43.1-3.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-03 02:14:38 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ximion appstream issues 476 0 None open Reconsider custom-key-duplicated error 2023-04-04 18:40:14 UTC

Description Flo 2023-03-29 20:57:52 UTC
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

Comment 1 Michael Catanzaro 2023-03-29 21:30:30 UTC
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?

Comment 2 Flo 2023-03-29 21:40:09 UTC
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."

Comment 3 Flo 2023-03-29 21:42:06 UTC
<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>

Comment 4 Milan Crha 2023-03-30 05:49:06 UTC
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.

Comment 5 Milan Crha 2023-04-04 06:06:51 UTC
*** Bug 2184124 has been marked as a duplicate of this bug. ***

Comment 6 Michael Catanzaro 2023-04-04 11:58:16 UTC
(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...?

Comment 7 Milan Crha 2023-04-04 15:53:47 UTC
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.

Comment 8 Michael Catanzaro 2023-04-04 18:42:18 UTC
appstreamcli (newer, from appstream) is stricter than appstream-util (older/disfavored, from appstream-glib). Software is porting away from appstream-util.

Comment 9 Michael Catanzaro 2023-04-05 14:02:40 UTC
(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.

Comment 10 Milan Crha 2023-04-05 14:21:29 UTC
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.

Comment 11 Michael Catanzaro 2023-05-17 14:29:09 UTC
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.

Comment 12 Fedora Update System 2023-05-17 14:31:22 UTC
FEDORA-2023-ec5e418618 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ec5e418618

Comment 13 Fedora Update System 2023-05-18 04:40:04 UTC
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.

Comment 14 Fedora Update System 2023-06-03 02:14:38 UTC
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.

Comment 15 Michael Catanzaro 2023-06-09 13:36:13 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.