Add Lithic_UK - #9596

❌ Test failure

@Xyvir: this pull request adds the AppImage from your GitHub repository to the AppImage catalog; the test reports the following. Could you have a look?

Lithic_UK

Compatibility: not self-contained: uses the C library of the system; references glibc 2.34

• The window is empty, e.g., only a menu bar on a blank background. The application must show its content when started without arguments and without network access.

First error in the log:

ERROR: The window appears to be empty (100% one color, almost no text)
Screenshot: letters by script: 0 Latin, 0 Chinese/Japanese/Korean, 0 Arabic, 0 Cyrillic/Greek

What next: once the AppImage is fixed (e.g. in a new release), comment /retest here to test it again. If it should not be in the catalog after all, close this pull request; an app that is already in the catalog can be removed by a maintainer with /remove.

Commit 0ebc1f9. Full log

Thanks for finding this one automatically, and for the detail in the report — it explains itself once you know which artifact was tested.

The AppImage the bot picked (Lithic_.AppImage) is the shim half of that release. It deliberately carries no web engine: it starts a small local server and hands the launcher to the browser the machine already has, so it never draws a window of its own. On your test runner that is exactly what happens — a headless X server and no browser to open — and the empty screen is the honest outcome rather than a crash. The uses the C library of the system note is the same deliberate choice: it links the host's OpenSSL rather than carrying a second copy of a library the machine is already patching. I would be grateful if it were not added to the catalogue. I will keep publishing it, because it is the build that fits a Linux desktop that already has a browser, but a test that asks for a window is the one thing it cannot pass.

The artifact that belongs in the catalogue is Lithic-webgtk_.AppImage: the Tauri build that bundles WebKitGTK and JavaScriptCore (about 43.5 MB of its ~82 MB) and opens a window of its own, with no browser involved. It had stopped being published while the shim caught up with it; I have put it back in the release pipeline, so it ships beside the shim from the next release onward.

One thing worth flagging for the entry itself: with both AppImages in a release, a plain repository URL is ambiguous for code/find-appimage.sh, which is the behaviour you document — none of its narrowing rules separate the two names, so it reports that there are several AppImages and it is not clear which to test. Your #Channel form solves exactly that, so if you are happy to take it, the line I would ask for in data/Lithic_UK is:

https://github.com/Xyvir/Lithic-UK#webgtk

The word matches the asset name, so it resolves to the WebKitGTK build on every release with nothing to bump by hand. Happy to close this PR and open a fresh one with that line if that is easier than editing it here.

Two caveats so nothing surprises the test: that build is built on Ubuntu 22.04 to keep its C library floor as low as possible (glibc 2.35), so it will probably carry the same compatibility note as the shim; and the asset only exists from the next release onward, so /retest needs that release to have landed first.

✅ Test passed

Please check that the screenshot shows the application's main window.

Lithic_UK

Compatibility: not self-contained: uses the C library of the system; references glibc 2.34

Warnings:

• The AppImage contains no update information, so users cannot update it with AppImageUpdate or similar tools. Please consider embedding it when building the AppImage (e.g., appimagetool -u) and publishing the .zsync file next to the AppImage; see https://docs.appimage.org/packaging-guide/optional/updates.html

Commit 0ebc1f9. Full log