io.github.quodlibet.QuodLibet missing metainfo incorrect warnings

[sidt4]

https://appstream.debian.org/sid/main/issues/quodlibet.html

Warnings

    no-metainfo
    This software component is missing a [MetaInfo file](https://freedesktop.org/software/appstream/docs/chap-Metadata.html#sect-Metadata-GenericComponent) to provide metadata.
    We currently took some data from its desktop-entry file and the long description of the package it is located in.
    This has several disadvantages, like poor markup, too technical descriptions for users of software centers, different components having the same description, etc.
    Additionally, a lot of software with desktop-entry files should either not be installable and searchable via the software catalog (like desktop-specific settings applications) or be tagged accordingly via MetaInfo files.
    ...

But, quodlibet has been providing appstream metadata for few years ( https://github.com/quodlibet/quodlibet/blob/main/data/io.github.quodlibet.QuodLibet.appdata.xml.in )

I'm not sure if this is something specific to Debian or appstream-generator, so opening it here for now.

[sidt4]

Sometimes I see random components: 0, hints: 1 when nothing actually changed in the package. ( https://salsa.debian.org/python-team/packages/quodlibet/-/commits/debian/master?ref_type=heads )

2022 logs:

/21_1410.log:2022-01-21 14:11:01 - INFO: Scanned quodlibet/4.4.0-2/all, could be interesting. ./21_0810.log:2022-02-21 08:14:43 - INFO: Scanned quodlibet/4.4.0-2/all, could be interesting. ./21_0810.log:2022-02-21 08:52:51 - INFO: Processed quodlibet/4.4.0-2/all, components: 1, hints: 1 ./26_1410.log:2022-03-26 14:21:58 - ERROR: Encountered invalid tag 'legacy-metainfo-directory' in component 'general' of package 'quodlibet/4.3.0-1/all' ./09_1010_cleanup.log:2022-04-09 10:16:58 - INFO: Dropped package quodlibet/4.4.0-2/all ./09_1010_cleanup.log:2022-04-09 10:17:25 - INFO: Marked io/github/quodlibet.ExFalso/f522abd0317724057eb35f3f5163f190 as cruft. ./09_1010_cleanup.log:2022-04-09 10:17:25 - INFO: Marked io/github/quodlibet.QuodLibet/cfe821821185344e28e822a9d3138cca as cruft. ./09_1010_cleanup.log:2022-04-09 10:17:33 - INFO: Expired media for 'io/github/quodlibet.ExFalso/f522abd0317724057eb35f3f5163f190' ./09_1010_cleanup.log:2022-04-09 10:17:33 - INFO: Expired media for 'io/github/quodlibet.QuodLibet/cfe821821185344e28e822a9d3138cca' ./01_0810.log:2022-04-01 08:10:46 - INFO: Scanned quodlibet/4.5.0-1/all for base suite. ./01_0810.log:2022-04-01 08:11:58 - INFO: Scanned quodlibet/4.5.0-1/all, could be interesting. ./01_0810.log:2022-04-01 08:12:14 - INFO: Processed quodlibet/4.5.0-1/all, components: 1, hints: 1 ./26_0810.log:2022-05-26 08:10:37 - INFO: Scanned quodlibet/4.5.0-2/all for base suite. ./26_0810.log:2022-05-26 08:11:39 - INFO: Scanned quodlibet/4.5.0-2/all, could be interesting. ./26_0810.log:2022-05-26 08:11:54 - INFO: Processed quodlibet/4.5.0-2/all, components: 0, hints: 1 ./04_1010_cleanup.log:2022-06-04 10:21:22 - INFO: Dropped package quodlibet/4.5.0-1/all ./09_1410.log:2022-07-09 14:20:09 - ERROR: Encountered invalid tag 'legacy-metainfo-directory' in component 'general' of package 'quodlibet/4.3.0-1/all' ./10_1410.log:2022-09-10 14:24:59 - ERROR: Encountered invalid tag 'legacy-metainfo-directory' in component 'general' of package 'quodlibet/4.3.0-1/all' ./17_1410.log:2022-12-17 14:28:20 - ERROR: Encountered invalid tag 'legacy-metainfo-directory' in component 'general' of package 'quodlibet/4.3.0-1/all'

2023 logs:

/16_2116.log:2023-04-16 21:27:20 - INFO: Scanned quodlibet/4.5.0-2/all, could be interesting. ./16_2116.log:2023-04-16 22:06:38 - INFO: Processed quodlibet/4.5.0-2/all, components: 1, hints: 1 ./14_0210.log:2023-07-14 02:11:40 - INFO: Scanned quodlibet/4.5.0-3/all for base suite. ./14_0210.log:2023-07-14 02:13:53 - INFO: Scanned quodlibet/4.5.0-3/all, could be interesting. ./14_0210.log:2023-07-14 02:14:16 - INFO: Processed quodlibet/4.5.0-3/all, components: 0, hints: 1

[ximion]

Quodlibet install the metainfo file in the wrong location, it needs to be in /usr/share/metainfo/io.github.quodlibet.QuodLibet.appdata.xml - any legacy location has not been read by appstream-generator for quite a while, and AppStream will stop reading anything from there with version 1.0 as well, and already doesn't read the location in compose. So, it's a Quodlibet bug ;-)

[sidt4]

Hmm.. I got a lot of empty <release> data from Debian appstream. So, I just looked into a random package to see why it's missing <release> info, hence this bug.

I understand that we don't want to support legacy paths, but do we have a way to communicate that to the app developers ? They might still think, that they are doing a good job maintaining their appdata / metainfo files, when in fact their data is actually not being used at all. I'm not sure how many apps fall into this category ( legacy install path ).

[ximion]

Extremely few apps still have this issue. Basically none that also have a Flatpak have this problem, and it has been communicated time and time again. We supported both paths for more than 6 years, and were emitting critical warnings for more than 4 years (or possibly even longer). AppStream-Generator was warning about this ever since it had been created, with instructions to notify upstreams about it.

Frankly, if someone hasn't switched by now, the only way to get them to switch is to ignore the legacy path so they finally change it (also good so no new app makes that mistake).

[sidt4]

AppStream-Generator was warning about this ever since it had been created, with instructions to notify upstreams about it.

I'm not sure if that will work, as everyone is stretched thin on time. AppStream-Generator warnings are useful only if an app maintainer actively looks into their app status via https://appstream.debian.org/sid/main/issues/quodlibet.html. It might not help those who run AppStream-Generator as that typically returns hundreds of warnings / errors, and no one can handle that many warnings / errors and report it to upstream projects.

One way this could work is to make this path validation check, part of the downstream package building process. Since, it has not been fixed upstream I assume none of the downstream distros which package quodlibet have failed their package validation process during build ( rpmbuild / dpkg-buildpackage etc )

[ximion]

These warnings were also showing up on pages like https://tracker.debian.org/pkg/quodlibet and other places, so it wouldn't just be upstream maintainers who had to look out for things, packagers would also have had to look at it.

Tools like dpkg/rpm do not perform any validation, that requires people to actively run rpmlint/lintian against the packages they generate. But appstreamcli already warns about this, so if people were using that, they also know.

[sidt4]

Also, is it possible for the AppStream-Generator to add a single <release> tag, with the release version / date fetched by querying remote git tags ( and fallback to upstream NEWS file ) ?

[ximion]

NEWS files are nothing that can be reliably parsed, and may look however the maintainer wants them to look like (e.g. https://github.com/systemd/systemd/blob/main/NEWS). Querying Git repositories would not only be extremely expensive, it would also be hard to extract a version number from that given that there is no universal convention as to how release tags look like.

The only thing that could be done is to use the package's upstream version and embed that with an empty description.

[sidt4]

The only thing that could be done is to use the package's upstream version and embed that with an empty description.

Sure. But, I guess still there will be no release date info.

Refer table (All time heading) in the issue description of https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2318 for reference.

[ximion]

We could use the data of the packaging. But TBH, for your table I would simply only use software that has a metainfo file / that has release data. That will not only give you high-quality apps to show up, it would also motivate developers to keep their data in good shape and present their application well.

[sidt4]

But TBH, for your table I would simply only use software that has a metainfo file / that has release data.

I don't want to start a political storm in the open source world :)

A better idea would be to discuss this issue with downstream distros ( mainly Debian / Ubuntu + Fedora ), and delegate this task (keep appdata valid) to individual downstream package maintainers. Each downstream package maintainer can do the following:

1. Make sure that the package has an appstream metadata file ( if applicable )

2. Make sure that appstream metadata is installed in the correct location.

3. Run "appstreamcli validate" during post build phase to check for obvious errors, and report it upstream. Since, the major workload is distributed among multiple downstream maintainers, this should offer success in a few months, which I think is good enough.

An even better way would be automate [1], [2] and [3] so that we could automatically open / update issues in gitlab / github via the REST API they offer.