Two compounding bugs in _wolf_download_emulator_appimage_gitlab() made
the ES-DE AppImage download always fail with "Could not resolve
download URL", confirmed live against the real GitLab API:
1. The asset filter checked url.endswith(".AppImage"), but GitLab's own
release-asset URL is an opaque .../package_files/<id>/download link
with no filename in it at all — only the asset's own "name" field
(e.g. "ES-DE_x64.AppImage") carries the real filename. Filtering on
the URL suffix matched nothing, even though the latest ES-DE release
genuinely ships x64/aarch64/SteamDeck AppImage assets.
2. Even with the URL resolved, the download target was built as
$dir/$(basename "$_url"), which for that same opaque URL evaluates
to just "download" instead of the real filename — breaking every
downstream step that looks for a *.AppImage file (the ES-DE.AppImage
symlink creation, and the "already downloaded" idempotency check on
a later rerun).
Fixed by filtering on the asset's own "name" field and threading that
name through (tab-separated from the URL) to use as the actual saved
filename. Verified end-to-end against the live GitLab API: resolves to
ES-DE_x64.AppImage and downloads a real, correctly-arched ELF binary.
(Also had to drop an f-string in the same python snippet — pre-3.12
Python disallows a backslash inside an f-string's {} expression, and
separately this whole snippet is wrapped in a bash single-quoted
string, so it can't contain single quotes at all either. Plain string
concatenation avoids both constraints.)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013BWYKEERLA1a7gv86Z4W23
Claude
750c55a4d4