Closed bbhtt closed 4 months ago
Any chance we could just add those to appstreamcli
as info or pedantic, and you override them in Flathub to be errors? That might make this very convenient, and we wouldn't need another linter tool!
At the moment, flathub/linter is running appstream-util. The test is to check if component has type=console-application in the generated catalogue.
It parses with lxml. I don't think there's a way to get the component type using the commands?
Also the long term fix would be respecting flathub.json
The linter is here to stay because it'll validate direct uploads not through flathub.
The checks are to see if the app-info
has icons and the generated catalogue. Not sure if that's something appstream can error on failing to generate them or check if they exist post generation.
The checks are to see if the
app-info
has icons and the generated catalogue. Not sure if that's something appstream can error on failing to generate them or check if they exist post generation.
appstreamcli compose
will return an error in its report if no icon was found - that could be parsed fairly easily.
I'm definitely nor arguing to remove the check, but appstreamcli
has a pretty nice system to make its validation issues fatal for certain configurations: https://github.com/ximion/appstream/issues/542
So if I could add Flathub-specific checks at a lower priority, you'd have less code to maintain and users could check the metadata files locally and get a somewhat similar result to what Flathub produces, which could be neat for everyone.
The appstreamcli
validator also has a machine-readable output mode, in case you want to do even more involved probing of the generated data :-)
That'd be indeed nice. You should talk with @barthalion on that. I don't think there's a timeline on the switch to libappstream, but it's on todo.
There might be a few things to check but I don't have the full picture re. linting and direct uploads.
Started test build 84300
One issue with direct uploads is that, I think flathub gets the generated ostree refs. The repo check extracts that to a temp directory and performs all the checks. I don't think it's possible to run appstreamcli compose on that and can't tell the ref has somehow missed generating the catalogue/proper icons without those checks in the linter.
But for builds that go through flathub infra, if compose propagates errors when run in flatpak/flatpak-builder that'd be helpful I think.
Build 84300 successful To test this build, install it from the testing repository:
flatpak install --user https://dl.flathub.org/build-repo/66937/org.freedesktop.appstream.cli.flatpakref
One issue with direct uploads is that, I think flathub gets the generated ostree refs. The repo check extracts that to a temp directory and performs all the checks. I don't think it's possible to run appstreamcli compose on that and can't tell the ref has somehow missed generating the catalogue/proper icons without those checks in the linter.
Indeed. AppStream has appstreamcli validate-tree
, but that will only check MetaInfo files and their icons, not catalog files (which is what you would want to check here). That could be added though, I think - all the logic is there in principle, it would just need to be wired up. So far, there hasn't been a usecase for a feature like this, as everything gets checked at compose time, and that process shouldn't return any invalid data (if it does, then that's a bug).
I'll have a look into implementing this check :-) (later though, currently I have a bunch of non-AppStream stuff to do)
bot, build
Queued test build for org.freedesktop.appstream.cli.
Started test build 93759
Build 93759 successful To test this build, install it from the testing repository:
flatpak install --user https://dl.flathub.org/build-repo/76506/org.freedesktop.appstream.cli.flatpakref
Ignore for now, I added some heuristics in the linter for console applications to not error on some checks. This is a test to see if it works.