Fix qmlformat script for newer Arch

[kairosci]

This pull request fixes the failing QML format job by adding a command fallback since the binary location changed on Arch Linux. It also updates the flatpak external data checker configuration for libebur128 to use git tags instead of GitHub releases, avoiding API rate limits that caused the Flatpak lint job to fail.

[github-actions]

Download the latest artifacts for this pull request:

• easyeffects-flatpak-merge-f80c4dcf2-into-97605d282-x86_64.flatpak.zip
• easyeffects-archlinux-merge-f80c4dcf2-into-97605d282-x86_64.zip
• easyeffects-flatpak-merge-f80c4dcf2-into-97605d282-aarch64.flatpak.zip

[kairosci]

@wwmm could you take a look at it? Thanks!

[wwmm]

As the scripts and flatpak files being touched were written by @vchernin it would probably be better if he reviewed these changes.

Here on my Arch Linux installation the qml scripts seem fine. Qml's linter does complain about

wallace@wwmm ~/myfiles/code/cpp/easyeffects $ ./util/qmlformat.sh 
Failed to parse src/contents/ui/DelegateClientsList.qml
Failed to parse src/contents/ui/DelegateModulesList.qml
Failed to parse src/contents/ui/DelegateStreamsList.qml

But that looks more like a bug in the linter than in the scripts. Our CI job does fail because of it. But I was waiting for Qt 6.12 before deciding what to do about it.

Sometimes the flatpak external data checker job fails. If that is the better way to fix the problem I don't know.

[vchernin]

The qmllint and qmlformat scripts are hacks to begin with, so any changes to make them more reliable seem fine to me. But clearly distros need to do a better job here if we now have 3 possible binary names…

I would suggest that qmllint-qt6 should be checked before trying qmllint in the conditionals. Same for qmlformat. It seems like a safer option to try the -qt6 option first since it is more explicit.

The fix for the Flatpak job makes a bit of sense but is also a bit puzzling. We should be passing the CI provided GITHUB_TOKEN environment variable and so Flatpak external data checker should only be making authenticated API calls. Those should surely not be hitting any GitHub API limit. But if this indeed works more reliably I guess it’s fine.

[kairosci]

@vchernin could you take another look at it? Thanks!

[vchernin]

The qmllint and qmlformat scripts look fine now, thanks.

I understand removing the github actions API usage from the flatpak modules, but why the anitya (release-monitoring.org) ones as well? Anitya is preferable to just getting the github tags, as it can filter out non-stable releases properly. Is anitya also unreliable these days?