Gnome Software - Open and Uninstall button not working for app

I have packaged a test “Hello World” app as an binary RPM (using rpmbuild). I have followed all the guidelines regarding .desktop and metainfo.xml files.

I can install and remove my RPM app from the command line (using dnf) and the app appears to show correctly in Gnome Software.

HOWEVER, the “Open” and “Uninstall” buttons do nothing when clicked. See the screenshot.

I’m guessing this is an AppStream metainfo issue, however, it seems that Gnome Software picks up on the AppStream metainfo and desktop files. I cannot fathom why it cannot launch the app or uninstall it.

What do I need to do to make these buttons work? Are there any logs which will help me diagnose the problem?


[Desktop Entry]
Name=Hello Puppy
Comment=A HelloWorld application


<?xml version="1.0" encoding="UTF-8"?>
<component type="desktop">

    <summary>A HelloWorld application</summary>
    <developer_name>Acme Ltd</developer_name>
    <url type="homepage"></url>

    <content_rating type="oars-1.1" />

        <p>This is a longer application description. REPLACE THIS WITH YOUR OWN.
        IMPORTANT: In this file, you can use supported macros. See the --help output for details.</p>

        <release version="1.0.0" date="2023-03-04">
            <description><p>The latest release.</p></description>

        <screenshot type="default">

    <launchable type="desktop-id">net.example.hellopuppy.desktop</launchable>


And here is the RPM SPEC file. Here, I am building a binary RPM from the output of C# dotnet. There’s no make or autotools here (and yes we have .dll extension under linux), so I’m just including the files in pre-built directory structure.

NOTE. While I’m putting all the metadata under /usr/share, I’m actually installing the app binary itself under the “/opt/appname” directory, so that all the dotnet DLL files can live together in the same place. Any problems with this BTW?

Name: HelloPuppy
Version: 1.0.0
Release: 1
BuildArch: x86_64
Summary: A HelloWorld application
License: GPL-3.0-or-later
Vendor: Acme Ltd

AutoReqProv: no
BuildRequires: libappstream-glib

desktop-file-validate %{buildroot}/%{_datadir}/applications/*.desktop
appstream-util validate-relax --nonet %{buildroot}%{_metainfodir}/net.example.hellopuppy.metainfo.xml

A HelloWorld application




What logs do you get when you run pkill gnome-software; gnome-software --verbose and reproduce the issue by clicking on the Open button then the Uninstall button?

What version of gnome-software are you using? What distribution?

Hey thanks for the reply.

I’m running Gnome 43.4 on Fedora 37.

killall gnome-software ; gnome-software --verbose

Yes this was helpful! Here are the results:

Clicking Open:

00:03:50:768 Gs running launch on plugin=packagekit with dedupe-flags=7 with interactive=True on apps system///net.example.hellopuppy/*

Not sure what this is looking for here

My actual runnable binary is defined in the destkop file by:


Note this is not under /usr/bin.

Clicking Uninstall:

00:04:40:678 Gs uninstall net.example.hellopuppy
00:04:40:678 Gs Chaining cancellation from 0x5651f024c560 to 0x7f8438000ea0
00:04:40:678 Gs nothing adopted system///net.example.hellopuppy/*
00:04:40:678 Gs Setting I/O priority of thread 0x7f84742eee40 to IDLE, 7
00:04:40:679 Gs Setting I/O priority of thread 0x5651ed1da360 to IDLE, 7
00:04:40:680 Gs Setting I/O priority of thread 0x7f8478002300 to IDLE, 7
00:04:40:680 GsPluginPackageKit ignoring /usr/share/applications/net.example.hellopuppy as does not exist
00:04:40:680 Gs Setting I/O priority of thread 0x5651ed1d5860 to IDLE, 7
00:04:40:680 Gs running unknown with dedupe-flags=7, elapsed time since creation 2ms
00:04:40:680 Gs running remove on plugin=packagekit with dedupe-flags=7 with refine-flags=require-setup-action,require-origin with interactive=True on apps system///net.example.hellopuppy/*, elapsed time since creation 2ms
00:04:40:692 Gs content rating system is guessed as PEGI from en_GB.UTF-8
00:04:40:692 Gs content rating system is guessed as PEGI from en_GB.UTF-8

Am I correct in thinking it is looking for a packaged called: net.example.hellopuppy ?

My RPM was named: HelloPuppy

and I use: sudo rpm remove HelloPuppy to remove it.

Is this the problem?

Do I use the application ID (rather than name) in the RPM SPEC file for “Name”, or is there a field in the AppStream metainfo file that I can use to set the uninstall?

I’m still banging my head against the wall with this one, so any input would be appreciated.

Two key lines from the log are:

Attempting to launch:

running launch on plugin=packagekit with dedupe-flags=7 with interactive=True on apps system/*/*/net.example.hellopuppy/*

When attempting to remove:

GsPluginPackageKit ignoring /usr/share/applications/net.example.hellopuppy as does not exist

(NB. the file does exist: /usr/share/applications/net.example.hellopuppy.desktop

Remember that I am building a package with “rpmbuild” and installing it from the command line with “dnf install”. As such, it is showing up in Gnome Software, but cannot be invoked or removed from Gnome Software.

IF THERE IS SOME HIDDEN METADATA (other than metainfo.xml) or option that I must do in the RPM file, or anything else, I would sure appreciate knowing this.


I note that the application KSystemLog when installed from RPM on my system exhibits the exact same behaviour as my test application – i.e. it cannot be uninstalled or launched from the Gnome Software center.

However, the KeePassXC app seems to work correctly. I have poured over the contents of it’s desktop, metainfo and spec files, and for the love of God, I cannot see what it does that I am not doing.

(I am running Fedora 37)

Can you attach the RPM file or link to it please?

Sure. Try this. Renamed it to “HelloWorld” but otherwise as described.

It’s because gnome-software can’t associate the installed metainfo file with a package name, and hence it never gets adopted by gnome-software’s PackageKit plugin. (gs_app_get_bundle_kind (app) == AS_BUNDLE_KIND_UNKNOWN rather than AS_BUNDLE_KIND_PACKAGE for it in gs_plugin_adopt_app() in the packagekit plugin.)

Normally, if your RPM was installed from a repository, this link would be provided by the Appstream catalog data, which would contain a <bundle> or <pkgname> tag for your component which links it to the package name. Catalog data is different from component metainfo files.

Arguably dnf should build a local Appstream catalog when installing stand-alone RPM files. However, stand-alone RPM files are discouraged (everyone should be using package repositories) so I can’t imagine anyone being enthusiastic to implement that.

You could try adding <bundle> or <pkgname> tags to your metainfo file. gnome-software might read them, although I think that would strictly be against the Appstream spec.

Yup, I had a slight suspicion it might be related to the fact that it wasn’t coming a repo, which was why I was keen to point out that I was installing from the command line.

Thank you so much for the response! It’s good know.

I will give your suggestion a shot. Thanks again.

As a follow and reference for others:

Adding tag to the metainfo fails validation with:

? tag-invalid           : <pkgname> not allowed in metainfo
Validation of files failed

Adding the following, however, succeeds validation and installs and runs fine:

<bundle type="package">helloworld-1.0.0</bundle>

HOWEVER, the application now no longer appears at all in the Gnome Software centre.

So it looks like what I asked is just not possible. But at least now I know where I stand with this now, and I’m not left wondering whether I am doing something wrong.

Some other notes and thoughts:

If I build my app and as a flatpak, I note that it can indeed be installed from the command line and launched and uninstalled from the Gnome Software Centre.

From what I understand, the Software Centre has the .desktop file, so it should be possible in theory to start the application?

If the Software Centre cannot uninstall it, it should not offer an option to do so which then fails silently.

Both of these things are true, but supporting stand-alone RPM files is such a low priority for us that I don’t think we are going to spend any time on improving the behaviour of gnome-software here, sorry. Stand-alone RPM files are really not a use case we want to encourage people to use.