cockpit (type web-application) not considered for Debian

[martinpitt]

I went through the AppStream hints of Debian's cockpit package recently, which shows some complaints:

• Error: web-app-without-icon: The component is a GUI web application, but it either has no icon set in its metainfo file, or we could not find a matching icon for this application.
• Warning: asv-metainfo-invalid-icon-type cockpit.appdata.xml:111 - local
  Metainfo files may only contain icons of type stock or remote, the set type is not allowed.

Cockpit's AppStream data specifies type="web-application" indeed. It's a bit weird as it gets delivered/installed as a proper distribution package, but you use it through a web browser. I. e. it's a "local web application".

It also specifies

 <icon type="local" width="128" height="128">/usr/share/pixmaps/cockpit.png</icon>

which is shipped by the "cockpit" package (rpm/deb). This seems correct to me, as there is no sensible other way to deliver the icon, except for putting it onto some web server (which is a privacy issue). It's not part of the usual stock icons, so I can't use that.

This doesn't seem to be a problem in Fedora. GNOME Software shows Cockpit just fine (including icon). There it gets processed into /usr/share/app-info/xmls/fedora.xml.gz as a locally cached icon:

<icon type="cached" height="128" width="128">org.cockpit_project.cockpit.png</icon>
<icon type="cached" height="64" width="64">org.cockpit_project.cockpit.png</icon>

and shipped in /usr/share/app-info/icons/fedora/64x64/cockpit.png (same for 128).

Debian has a different approach, it doesn't ship the AppStream metadata in a package (like Fedora's appstream-data), but as part of the package manager indexes: https://appstream.debian.org/data/bullseye/main/ . I don't see cockpit at all in Components-amd64.yml.xz and the icons-*.tar.gz is also missing cockpit.png. So supposedly the generation has skipped cockpit because of that error?

How can this be fixed?

Thank you!

[martinpitt]

I also wonder about the warning itself. The AppStream spec does not forbid using a local icon for a web app. I'm not sure where Debian's meta-data generator lives, but at least to a large part it's just this project. web-app-without-icon is from appstream-generator, but there are no hits for grepping for invalid-icon-type. @iainlane , does that ring a bell? I think you worked on this back then together with @ximion?

[ximion]

There's quite a bit to unpack here... First, a "stock icon" doesn't mean that the icon has to be part of the default-set of defined names for XDG icon themes, it simply means "this icon can be found in any theme". So if you install an icon for Cockpit to /usr/share/icons/hicolor/AxB/apps/ and then add a

<icon type="stock">org.cockpit_project.cockpit</icon>

entry to you metainfo file, this problem will be fixed. Asgen doesn't allow local icons - even though they are technically valid - to push people in the direction of installing icons into the hicolor default theme directory, so people can provide multiple sizes.

This actually raises an intriguing question though: Should the scope of a "stock" icon be limited to only stuff in the standard icon naming spec (here) and should we introduce a new type ("xdg"?) for the other icons, to be more clear? I just changed some code in GNOME Software which removed the (previously added) assumption that an AppStream "stock" icon would always be present, so there might be some confusion here. The counterargument is that any "xdg" icon type that would be added would essentially follow the same logic as a "stock" icon, so those would almost just be aliases, code-wise. @hughsie, what do you think? (Personally I am leaning more towards keeping things the way they are and clarifying the documentation text, but if there is more discussion needed here we should open a separate bug report against AppStream)

As for the question "should appstream-generator allow local icons defined in the metainfo file?", I would say probably not, but if that's the case this should flow back into the specification. Asgen doing something unexpected and different from the spec is not acceptable.

There's one more thing that is puzzling me: The web-application type describes things like GMail, Slack, Riot, external Nextcloud instances etc. So things you can immediately open when you click on a web URL (that's why webapps require an "url" launchable type). Is Cockpit such an application? Isn't Cockpit much rather something like Nginx, a locally installed Nextcloud instance or FreeIPA, so, a service running on your machine that happens to have a web interface? In that case, it shouldn't be of type web-application but rather be of type service - a service component can have an icon and even screenshots too, but unlike for the *-application components, that's not a requirement.
I'm really just asking for clarification here, I have used Cockpit before (it's sooo neat for convincing people that they can maintain their own Linux server ^^) but I am not up to date on its development.

Debian's generator lives here, at a proper CDN that's part of the project: https://appstream.debian.org/ (/me is proud how well-integrated AS is in Debian and how helpful the DSA were in the process - after I have them the YAML-version of AS, which in hindsight probably wasn't a good compromise ^^). You can find the raw hints output here: https://appstream.debian.org/hints/
Cockpit has the same issue there: https://appstream.debian.org/sid/main/issues/cockpit.html

[martinpitt]

@ximion: Thanks for your detailled reply! Moving the icon into /usr/share/icons/hicolor/AxB/apps/ sounds like a clean solution indeed. I wasn't aware of the /apps directory and just thought that this was reserved to the hicolor-icon-theme. On my (admittedly rather slim) system, I just have

❱❱❱ rpm -qf /usr/share/icons/hicolor/
hicolor-icon-theme-0.17-8.fc32.noarch
fedora-logos-30.0.2-4.fc32.x86_64

But indeed

curl http://ftp.de.debian.org/debian/dists/buster/main/Contents-amd64.gz | gzip -cd | grep usr/share/icons/hicolor

shows that lots of packages use that path.

.Isn't Cockpit much rather something like Nginx, a locally installed Nextcloud instance or FreeIPA, so, a service running on your machine that happens to have a web interface?

That's correct. You install the package, enable the service, and the way to access it is https://<server>:9090, so often "localhost", but of course also a remote server. We were struggling a bit with choosing the type; but "desktop-application" doesn't work as there is no .desktop file, a "console-application" doesn't fit either (no program in $PATH and it's really not a CLI program), and the definition of web-application seems to fit (with some wiggle room for interpretation). "Service" actually seems to fit the bill better -- was that perhaps introduced much later than the others? Or we could just have missed it a few years ago. I'll certainly give that a try and see what appstream-util validate has to say.

[martinpitt]

So do you think that fixing that icon error will make it appear in the Debian metadata?

[ximion]

So do you think that fixing that icon error will make it appear in the Debian metadata?

Yes - there is a slim chance that there are other issues that asgen didn't bother looking at since data generation already failed. But I don't think that's the case.

To know with higher confidence, you can just run your file through appstreamcli validate, if validation of the AppStream validator passes (and an icon is found by asgen) your app will be accepted.

The service components exists in AppStream since July 2017, so it's pretty old and established already. I have no idea when it was implemented in appstream-glib though.
I also kind of remember that the service component and the cockpit-manifest launchable type kind of went hand in hand (the former was done in a different request and due to systemd offering (finally!) a pretty good API to manage services that AppStream could specify, and I think the latter was requested from your team shortly after).

Btw, the spec doesn't explicitly allow a launchable=url tag for service components (it's nor forbidden either though), but I think it probably should for the exact case you mentioned: Using a localhost:port URL to an admin interface post installation.

One problem with all of these components is that I think GNOME Software won't show any service, console-app and nowadays even webapp components, so depending on where you want this shown, this is an issue to consider.

Btw, for creating the initial metadata, I made a webapp a while ago that you may find useful in future:
https://www.freedesktop.org/software/appstream/metainfocreator/#/
(not so much now, now that you already have your XML)

Cheers,
Matthias

[martinpitt]

I tried to apply your suggestion:

$ appstream-util validate src/ws/cockpit.appdata.xml
src/ws/cockpit.appdata.xml: FAILED:
• tag-invalid           : stock icon is not valid [org.cockpit_project.cockpit]
Validation of files failed

It doesn't seem to be about the name, if I change it to just "cockpit.png", it complains in the same way:

 appstream-util validate src/ws/cockpit.appdata.xml
src/ws/cockpit.appdata.xml: FAILED:
• tag-invalid           : stock icon is not valid [cockpit]
Validation of files failed

validate-relax does the same. I straced it, and it doesn't even seem to look at /usr/share/icons, just at that:

38986 openat(AT_FDCWD, "/usr/local/share//mime//icons", O_RDONLY) = -1 ENOENT (No such file or directory)
38986 openat(AT_FDCWD, "/usr/local/share//mime//generic-icons", O_RDONLY) = -1 ENOENT (No such file or directory)

[martinpitt]

One problem with all of these components is that I think GNOME Software won't show any service, console-app and nowadays even webapp components

I did test that a few days ago (see original issue description), and at least in Fedora that web-application shows up. I suppose I could locally hack the appinfo files and see if it shows services.

[ximion]

I tried to apply your suggestion:

I think this is a bug in appstream-util - can you try validating the file with appstreamcli (from the appstream package)? (Fedora should have that, I'm doubtful about RHEL having it though).
I think asutil doesn't permit a stock icon tag here at all, while it really should be allowed... (If ascli is happy with the file, reporting this as a bug against appstream-glib may be a good idea)

(I ran ascli on the template file and that produced a few errors because the file was incomplete, but icon-wise everything seemed fine)

As for the webapps, you maybe don't have the latest GNOME Software yet:
https://gitlab.gnome.org/GNOME/gnome-software/commit/ea5eb222f514895f41ad0ce80f48fff98207bdc6

The GNOME design team AFAIR was very much against having services, console apps, etc. in there, and webapps were handled in a special way before that didn't run that well (webapp is definitely not the right component type for Cockpit...). Canonical uses GNOME Software for just about anything in a Snap package though and removed that restriction (which is kind of meh as well).
Honestly, I'm not sure how this issue would be solved - GNOME doesn't want users to be able to install PostgreSQL from GNOME Software, but Cockpit maybe. Both would be service-type components though, so filtering just by component type wouldn't cut it.

[martinpitt]

can you try validating the file with appstreamcli

Yes, that does work:

$  appstreamcli validate ./src/ws/cockpit.appdata.xml
Validation was successful: pedantic: 4

Btw, the spec doesn't explicitly allow a launchable=url tag for service components (it's nor forbidden either though),

Indeed with type="service" it doesn't work:

E: org.cockpit_project.cockpit:~: service-no-service-launchable

For us it's

<launchable type="url">https://localhost:9090</launchable>

and indeed that's not allowed by the spec, it only supports a systemd unit name. But that's not the point of cockpit, this isn't MySQL or timesyncd or similar. I suppose that's what threw me off back then :)

That will take some time to adjust to, as we need to bring that into our CI containers and such, and see how to deal with RHEL. But if that's the designated successor, let's do that. The only nastiness is that the appstream package depends on appstream-data, which is huge, and unnecessary for this functionality.

As for the webapps, you maybe don't have the latest GNOME Software yet:

I just downloaded today's F32 beta iso, and I can still see it, but maybe it's just not yet in 3.36.0 (even though that commit was 4 months ago..). Anyway, if it goes away from g-s, so be it, but at least I can use that to validate the changes to my xml. I changed it to type="service" (and also hacked the name, so that I can confirm that the xml change is taken into account); g-s still shows cockpit.

In either case (web-application or service type), the "Launch" button is broken -- journal shows it's looking for a .desktop file of that name. But that's a g-s bug.

So in summary:

• switching icon to stock is a bit painful, but doable, and the right thing to do
• switching type away from webapp doesn't work right now.

Thanks for your great help @ximion!

[ximion]

E: org.cockpit_project.cockpit:~: service-no-service-launchable

But cockpit is launched by a .service file, right? You can have multiple launchables, so just add one for the service to satisfy this error :-)
A service currently just requires "some way to launch the service" to be present.

But if that's the designated successor, let's do that.

Both tools existed for a really long time, for historical reasons. Of course, personally I'm happy with people using appstreamcli because that's closer to the AppStream spec, while asutil checks a bunch more stuff that GNOME wants.

AppStream (ascli) doesn't depends on any GUI/GDK stuff on purpose though, you may like that.

The only nastiness is that the appstream package depends on appstream-data, which is huge, and unnecessary for this functionality.

In Debian, when we still had a similar package, that issue was solved by having software centers depend on the -data package, since AppStream didn't really need it. Nowadays, we also only pull in icon data from the repository for AppStream if a software center depends on the right apt-config package: https://packages.debian.org/bullseye/apt-config-icons
Maybe that's an option for Fedora too?

I just downloaded today's F32 beta iso, and I can still see it, but maybe it's just not yet in 3.36.0 (even though that commit was 4 months ago..)

Since this is Fedora, I would assume GNOME is up to date. Maybe I'm mistaken and this only affects stuff handled by the Epiphany plugin directly... (when in Purism's PureOS all webapps vanished, some people were upset...)

In either case (web-application or service type), the "Launch" button is broken -- journal shows it's looking for a .desktop file of that name. But that's a g-s bug.

Indeed, I noticed that too on a few occasions (most notably WINE, which is a desktop-app without any launchable set)

switching icon to stock is a bit painful, but doable, and the right thing to do

Indeed, it's also what the Freedesktop specs recommend and the AppStream spec kind of expects people to know how GUI apps work, even though it is talking about service components. I am currently working on improving the HTML, maybe I can also add a better and more general explanation of this to the next spec revision.

Thanks for raising this issue, that is very helpful!