I have a repo — taw/joplin Copr —. I have maintained this repo for … years and years. Joplin, the app that that repo deploys has ALWAYS been available via Gnome Software. With Fedora 41 though, it is no longer.
So, I spent some time cleaning up the metainfo.xml and the desktop files and rebuilding the packages and pushing them back out to the repo.
When I look at what repos Gnome Software knows about and confirmed my repo is on its radar …
But …
I can’t “explore” that application.
If I click into “Installed” and the application is installedI can see its details.
If I right click on the application and ask for “App Detail” I get “Sorry! There are no details for that application.”
Here’s the kicker: I have one machine that I upgraded to f41 from f40.
The other machine, I created from scratch, (but I did splat my home directory back to where it belonged, so to speak). The machine that was upgraded from Fedora 40 to 40 sees my application in Gnome Software. The machine that was installed as Fedora 41 does not.
Ok. I am stumped
Trying to discover WHY this behavior. I am pretty convinced (after substantial audit and testing) that my .desktop and .metainfo.xml files validate and are sound, but … my application build just won’t show up. What the heck?
GNOME Software relies on appstream metadata provided by the repository to list / search apps in that repo, and it looks like COPR repos don’t have appstream metadata generated by default.
“”"
If you’re using a COPR then all these steps are done for you automatically. If you’re using xdg-app already, then this is all magically done for you as well, and automatically downloaded by GNOME Software.
“”"
I’m certain it is me that is doing something wrong. Had a night of sleep. Investigation once again. … this stuff is so twitchy and the documentation is … mixed.
I don’t see any appstream data for your COPR repo in FC41.
Below are the relevant logs from gnome-software.
$ gnome-software --verbose 2>&1 | grep "detected content" | grep -v "x-desktop$"
17:10:28:630 XbSilo detected content type of adobe-flash.xml to be application/xml
17:10:28:631 XbSilo detected content type of fedora.xml.gz to be application/gzip
17:10:28:631 XbSilo detected content type of fedora.xml to be application/xml
17:10:29:842 XbSilo detected content type of gnome-pwa-list-foss.xml to be application/xml
17:10:29:843 XbSilo detected content type of gstreamer-non-free.xml to be application/xml
17:10:29:843 XbSilo detected content type of org.gnome.App-list.xml to be application/xml
17:10:29:845 XbSilo detected content type of other-repos.xml to be application/xml
17:10:29:845 XbSilo detected content type of copr:copr.fedorainfracloud.org:phracek:PyCharm.xml to be application/xml
and their corresponding locations.
root@fedora:/usr/share/swcatalog/xml# ls -l
total 6952
-rw-r--r--. 1 root root 773 Oct 8 01:00 adobe-flash.xml
-rw-r--r--. 1 root root 7047006 Oct 8 01:00 fedora.xml.gz
-rw-r--r--. 1 root root 15588 Mar 16 2022 gnome-pwa-list-foss.xml
-rw-r--r--. 1 root root 5806 Oct 8 01:00 gstreamer-non-free.xml
-rw-r--r--. 1 root root 34574 Sep 16 01:00 org.gnome.App-list.xml
-rw-r--r--. 1 root root 882 Oct 8 01:00 other-repos.xml
root@fedora:/var/cache/swcatalog/xml# ls -l
total 0
-rwxr-xr-x. 1 root root 0 Nov 2 05:18 copr:copr.fedorainfracloud.org:phracek:PyCharm.xml
I swear to god that checkbox is new. Or I am losing my mind. Cuz, I have build into this repo for years and this is the first time I encountered this problem. I thought … surely, this is a Fedora 41/GNOME 47 issue. Nope. PEBCAK.
Anyway. THANK YOU! I would have gone down wrong rabbit hole after wrong rabbit hole chasing this phantom issue if you didn’t poke this with a sharp stick for me.
thus it looks like the metainfo.xml was not recognized for whatever reason. I do not know where the logs for the appstream data generaton from the repo are saved, neither there’s obvious which appstream data extractor they use (appstream-builder or appstram-generator, though the former is more likely).
Running appstream-builder ./joplin-3.1.24-4.rp.fc41.taw.x86_64.rpm extracts the appstream data properly, thus either the COPR build calls it in a wrong way (this one is not correct, it uses some default values, which are incorrect), or there happened some other problem with this. Maybe file a bug against COPR.
There are more problems with PackageKit 1.2.8 not reading/installing all the appstream data of the repos, but it’s another story ([1][2]).
