MagicBeanDev/Longshot
MagicBeanDev/Longshot
Watch
8
2
Fork
You've already forked Longshot
 19
Code Issues 32 Pull requests 76 Projects 1 Releases 6 Packages Wiki Activity Actions 136

build(linux): the Linux builder gets its build tools from tools.lock, as Windows does #113

Merged
HumanBean merged 1 commit from HumanBean/Longshot:linux-tools-lock into main 2026-11-13 04:42:38 +00:00
Conversation 0 Commits 1 Files changed 21 +1305 -285
HumanBean commented 2026-11-13 04:33:24 +00:00
Owner

Why

Every Linux release shipped its whole compiler, sysroot and libraries again inside a 245 MB AppImage, and each installed version kept its own copy. The Linux builder now gets its build tools from tools.lock, as Windows does: each one is published once and shared by every version that uses it.

What changed

  • tools.lock: five linux-x64 lines (emsdk, ffmpeg, sdl2, sysroot, cpm). Each dest is where the AppImage used to carry the tool (usr/lib/longshot/..., usr/share/longshot/cpm), so an unpacked builder looks the same as before. Windows also gets cpm with dav1d and third-party.

  • Where the tools live: Packages. Each archive is a file of a generic package of the MagicBeanDev organization: <name>-<system> / <version> / <sha256>-<name>.zip, at https://git.magicbean.dev/api/packages/MagicBeanDev/generic/.... Upstream URLs stay as fallbacks. The package is per system because a tool's Windows and Linux builds have versions of their own (emsdk is hookshot-v2.1.0 on Windows and 23.1.5 on Linux). All 11 files are uploaded, and anyone can download them without an account.

  • scripts/tools.py:

    • store() is the one upload path, a PUT to the package registry. A 409 is accepted only when the existing file has the same size and SHA-256.
    • check --require checks that every tool each builder needs has a line (REQUIRED per system), and that each line's package file exists with its size and SHA-256 (via the package API).
    • profile is no longer required. PROFILE and assemble profile stay.
    • --system on fetch, install and mirror.
    • pack <folder>: a deterministic archive that keeps file modes and relative links. unpack restores them and refuses links that lead outside the folder.
    • install writes .tools/<name> stamps and unpacks a tool again when its line changes.

  • Shared tool entry? Not done, and the format is unchanged. CPM is the only tool that could share an entry, and it can't: the Windows CPM archive also carries Windows FFmpeg and dav1d, and the two systems unpack to different dests.

  • scripts/linux/deps.sh: the default run builds only what the AppImage carries (Python with Tk, appimagetool, the runtime). deps.sh tools builds LLVM, FFmpeg+dav1d, SDL2, the headers and the sysroot (moved here from appimage.sh), puts each tool's licenses in its own folder, and packs each one into build-linux/deps/tools/<name>.zip with an add.sh holding the tools.py add lines. docker.sh tools runs it in the container.

  • scripts/linux/appimage.sh: installs the linux-x64 tools into build-linux/tools and builds the Vulkan back end and the sysroot check with them. It copies none of them into the AppDir, and copies tools.lock into usr/share/longshot.

  • AppImage contents: the builder, its Python with Tk, Longshot's sources and the prebuilt longshot_vk.so.

    • Python stays because the window, the first-start download and make_game.py all run on it, before any tool exists.
    • The launcher runs it with -I, so packages outside its tree would need a path hook.
    • Its packages follow requirements.txt, which changes with each version, so sharing them across versions would gain little.

  • builder/linux/linux_tools.py (new) and builder/linux/AppRun: before the window or --cli starts, AppRun gets EMSDK, LONGSHOT_SYSROOT, LONGSHOT_FFMPEG, LONGSHOT_SDL2 and RX_CPM from linux_tools.py env --install. Each tool is looked for in this order:

    1. beside the builder (the launcher's unpacked copy, or a dev AppDir);
    2. the launcher's own copy of this version (toolchain.json names the SHA-256);
    3. $XDG_DATA_HOME/longshot/builder/toolchains/<version>/, which uses the launcher's layout.

    Whatever is missing is downloaded there on the first start, checked by its SHA-256, with a progress window (on stderr for --cli). A tool another version already has is hard-linked, not downloaded. Once the tools are there, no connection is needed. --cli stops if a tool is missing. --play needs no tools.

  • RecompLauncher: --cli --prepare --game goes through the same --cli path, with progress on stderr.

  • CI:

    • build-linux.yml installs the tools from Packages, cached by tools.lock's hash, and the object cache key names tools.lock.
    • The FSR check uses the installed tools.
    • check_player_build.sh refuses an image that carries a tool, and runs the build from the image with the tools given as the builder's toolchains folder, so nothing is downloaded.
    • release.yml's first job (check --require) now also covers the Linux lines and the package files.

  • Launcher: MagicBeanDev/LongshotLauncher#4. After unpacking the AppImage, it installs the linux-x64 tools of the tools.lock inside it, with reuse across versions. It must be merged and released before the first AppImage made with this PR: an older launcher would run make_game.py without the tools.

  • Docs: docs/releases.md (Linux no longer bundles; Packages), RELEASING.md (bumping a Linux tool, Packages, one-time setup step 6 done), the README (the standalone AppImage's size and first-start download), and docs/development.md. docs/releases.md and RELEASING.md are byte-identical with the launcher PR.

Flags and settings

Flag What it does Default now Recommendation Helps on Doesn't help on Untested on
LONGSHOT_BUILDER_HOME (existing) also moves the AppImage's toolchains folder $XDG_DATA_HOME/longshot/builder keep tests, portable setups
TOOLS, TOOLS_CACHE (appimage.sh, check_player_build.sh) where the build installs and finds tools.lock's Linux tools build-linux/tools, build-linux/tools-cache keep developers

Measurements

main: b9cdc432 (2026-11-12)
this PR: linux-tools-lock @ 78d14610
Hardware: Ryzen desktop, 24 threads, 30 GB, CachyOS (Linux 7.3); the build in longshot-linux-build (Ubuntu 22.04, as CI)
Method: deps.sh + appimage.sh in the container, LONGSHOT_VERSION=v3.0.0-measure. The size is the AppImage file's. The per-tool share is each folder of main's AppDir compressed with zstd -15, which approximates the AppImage's squashfs zstd. The package size is the uploaded zip. The AppImage is deterministic in size: main was built once, this PR twice (both 94,575,096 bytes).
How to reproduce: scripts/linux/docker.sh on each commit (with --network host where the container's DNS fails), then stat -c %s build-linux/*.AppImage.

main @ b9cdc432 this PR @ 78d14610
Longshot-<v>-x86_64.AppImage 244,689,400 B (234 MB) 94,575,096 B (91 MB)
AppDir, uncompressed 889.9 MB 359.2 MB
Tool In main's AppImage (zstd est.) Package zip (this PR) Unpacked
emsdk (clang, lld, llvm-profdata) 119.6 MB 141,542,909 B 415.7 MB
sysroot 9.3 MB 15,857,135 B 51.7 MB
ffmpeg + dav1d 7.7 MB 9,796,808 B 36.9 MB
cpm (Vulkan, SPIR-V, VMA headers) 1.6 MB 2,343,062 B 25.3 MB
sdl2 0.9 MB 889,975 B 2.3 MB
stays: Python + Tk 72.1 MB 314.4 MB
stays: longshot_vk.so 4.5 MB 14.0 MB

A first start downloads 170.4 MB once (516 MB unpacked). A later version downloads only the tools whose line changed.

Testing

Tested:

  • LONGSHOT_VULKAN_HEADERS=/usr/include python -I -B tests/run_all.py, interleaved: main 492 passed, 2 failed, 36 skipped; this PR 493 passed, 2 failed, 36 skipped (the new test_linux_tools.py); main again 492/2/36. The 2 failures are the known ones and fail on main too: test_bake_portability, test_builder_log_read_only.
  • New tests:
    • tests/test_linux_tools.py: the lookup order, the first-start download with progress, offline later starts, hard links across versions, the launcher's copy used as is, a changed download installing nothing, a changed stamp, and AppRun itself (--cli --prepare with tools found offline, --cli stopping without them, --play needing none). It uses fakes and no network.
    • test_tools_lock: Linux lines, systems kept apart, pack/unpack modes and links, links leading outside refused, the package store, check --require per system and with the store, and the profile not required.
    • Updated without weakening: test_appimage_player_build (the tools at their tools.lock places, DLSS with RX_CPM), test_linux_update (the sysroot loop, now in deps.sh, also round-tripped through tools.py pack/unpack), test_make_game_ngx.
  • The AppImage built twice in the Ubuntu 22.04 container, and check_player_build.sh passed: --cli --help, the pipeline list, build.py --standalone --dry-run with 0 missing, nothing written into the image.
  • A real first start outside the container, with an empty builder home: Longshot-v3.0.0-measure-x86_64.AppImage --cli --help downloaded the 5 tools from the package URLs, unpacked 516 MB and ran make_game. The second start took 0.15 s and downloaded nothing.
  • tools.py check --require passes against the uploaded packages.

Not tested:

  • A game build or play with the new AppImage: no game here. The tools are the same bytes main's AppImage carried, built by the same deps.sh pins, but packed and unpacked through tools.py.
  • The builder window's Tk progress window, on screen.
  • The new Windows cpm/third-party on Windows. dav1d was built with scripts/windows/dav1d.sh (llvm-mingw 20261104 for Linux, nasm 2.16.01, libdav1d.a sha256 e6f1adec…), not run under Wine here.

Needs other testers:

  • Linux, any distribution: start a fresh Longshot-*.AppImage with no ~/.local/share/longshot/builder/toolchains, build and play. Expect a download window (about 170 MB), then a normal build (request to open).
  • Windows: LongshotBuilder.exe with this tools.lock. Expect the setup to install third-party. This may fail, see Reviewer notes (request to open; blocked on the setup.c follow-up).

Screenshots

Nothing on screen (the first-start progress window is new, but there was no display here to capture it).

Risk and rollback

  • A launcher without its matching PR runs make_game.py from an unpacked AppImage that has no tools, so its Linux builds fail. Merge and release the launcher PR first. An AppImage started by itself is unaffected.
  • Reverting this commit brings the bundled AppImage back. The packages can stay where they are.

Reviewer notes

  • third-party on Windows is likely broken by setup.c. The archive is uploaded and in tools.lock. But builder/setup/setup.c moves a tool's prefix folder onto its dest with MoveFileW, which fails when the dest exists, and LongshotBuilder/tools/third_party is already in the builder zip. Its reuse also moves an older version's whole folder. The launcher merges files and is fine. This needs a follow-up in setup.c (merge a tool into an existing dest), or another dest.
  • The third-party archive comes from Hookshot v2.1.0's part (c361af47…, 29,574,904 B, the same as in v2.1.0's hookshot-setup.txt), keeping only its 8 prebuilt files. Its a64emit.dll.sha1 stamp doesn't match Longshot's a64emit.cpp + arm64_to_c.h (whose bytes are unchanged since v2.1.0), so the player's PC would rebuild a64emit.dll anyway.
  • scripts/release.py still says "the tools release" in two comments. It is shared with the launcher, so it is left for a follow-up.
  • scripts/linux/make_parts.py and linux_update.py's parts-list path (dev only) still describe the bundled layout.

Issues

See MagicBeanDev/LongshotLauncher#4

Checklist

For everyone

  • One topic.
  • The title is a Conventional Commit (type(scope): description).
  • Rebased on current main.
  • python -I -B tests/run_all.py run and passing (any failure that also fails on main is named above).
  • Tested in the game, or what wasn't is named under Testing.
  • Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests).
  • Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported.
  • No game files, dumps, build output or generated files.
  • third_party/ untouched (a new folder with a PROVENANCE.md instead).
  • The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled.

If applicable

  • Flags noted, and the switch reference updated (docs/development.md, the README).
  • A game-free test added for the fix, failing on main and passing here.
  • A check under tests/ that reads changed source updated in this PR, not weakened.
  • Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (builder/setup/setup.c: one comment changed, no code.)
  • Docs updated.
## Why Every Linux release shipped its whole compiler, sysroot and libraries again inside a 245 MB AppImage, and each installed version kept its own copy. The Linux builder now gets its build tools from `tools.lock`, as Windows does: each one is published once and shared by every version that uses it. ## What changed - **tools.lock**: five `linux-x64` lines (`emsdk`, `ffmpeg`, `sdl2`, `sysroot`, `cpm`). Each `dest` is where the AppImage used to carry the tool (`usr/lib/longshot/...`, `usr/share/longshot/cpm`), so an unpacked builder looks the same as before. Windows also gets `cpm` with dav1d and `third-party`. - **Where the tools live: Packages.** Each archive is a file of a generic package of the MagicBeanDev organization: `<name>-<system>` / `<version>` / `<sha256>-<name>.zip`, at `https://git.magicbean.dev/api/packages/MagicBeanDev/generic/...`. Upstream URLs stay as fallbacks. The package is per system because a tool's Windows and Linux builds have versions of their own (emsdk is `hookshot-v2.1.0` on Windows and `23.1.5` on Linux). All 11 files are uploaded, and anyone can download them without an account. - **`scripts/tools.py`**: - `store()` is the one upload path, a `PUT` to the package registry. A 409 is accepted only when the existing file has the same size and SHA-256. - `check --require` checks that every tool each builder needs has a line (`REQUIRED` per system), and that each line's package file exists with its size and SHA-256 (via the package API). - `profile` is no longer required. `PROFILE` and `assemble profile` stay. - `--system` on `fetch`, `install` and `mirror`. - `pack <folder>`: a deterministic archive that keeps file modes and relative links. `unpack` restores them and refuses links that lead outside the folder. - `install` writes `.tools/<name>` stamps and unpacks a tool again when its line changes. - **Shared tool entry?** Not done, and the format is unchanged. CPM is the only tool that could share an entry, and it can't: the Windows CPM archive also carries Windows FFmpeg and dav1d, and the two systems unpack to different dests. - **`scripts/linux/deps.sh`**: the default run builds only what the AppImage carries (Python with Tk, appimagetool, the runtime). `deps.sh tools` builds LLVM, FFmpeg+dav1d, SDL2, the headers and the sysroot (moved here from `appimage.sh`), puts each tool's licenses in its own folder, and packs each one into `build-linux/deps/tools/<name>.zip` with an `add.sh` holding the `tools.py add` lines. `docker.sh tools` runs it in the container. - **`scripts/linux/appimage.sh`**: installs the `linux-x64` tools into `build-linux/tools` and builds the Vulkan back end and the sysroot check with them. It copies none of them into the AppDir, and copies `tools.lock` into `usr/share/longshot`. - **AppImage contents**: the builder, its Python with Tk, Longshot's sources and the prebuilt `longshot_vk.so`. - Python stays because the window, the first-start download and `make_game.py` all run on it, before any tool exists. - The launcher runs it with `-I`, so packages outside its tree would need a path hook. - Its packages follow `requirements.txt`, which changes with each version, so sharing them across versions would gain little. - **`builder/linux/linux_tools.py`** (new) and **`builder/linux/AppRun`**: before the window or `--cli` starts, AppRun gets `EMSDK`, `LONGSHOT_SYSROOT`, `LONGSHOT_FFMPEG`, `LONGSHOT_SDL2` and `RX_CPM` from `linux_tools.py env --install`. Each tool is looked for in this order: 1. beside the builder (the launcher's unpacked copy, or a dev AppDir); 2. the launcher's own copy of this version (`toolchain.json` names the SHA-256); 3. `$XDG_DATA_HOME/longshot/builder/toolchains/<version>/`, which uses the launcher's layout. Whatever is missing is downloaded there on the first start, checked by its SHA-256, with a progress window (on stderr for `--cli`). A tool another version already has is hard-linked, not downloaded. Once the tools are there, no connection is needed. `--cli` stops if a tool is missing. `--play` needs no tools. - **RecompLauncher**: `--cli --prepare --game` goes through the same `--cli` path, with progress on stderr. - **CI**: - `build-linux.yml` installs the tools from Packages, cached by `tools.lock`'s hash, and the object cache key names `tools.lock`. - The FSR check uses the installed tools. - `check_player_build.sh` refuses an image that carries a tool, and runs the build from the image with the tools given as the builder's toolchains folder, so nothing is downloaded. - `release.yml`'s first job (`check --require`) now also covers the Linux lines and the package files. - **Launcher**: MagicBeanDev/LongshotLauncher#4. After unpacking the AppImage, it installs the `linux-x64` tools of the `tools.lock` inside it, with reuse across versions. It must be merged and released before the first AppImage made with this PR: an older launcher would run `make_game.py` without the tools. - **Docs**: `docs/releases.md` (Linux no longer bundles; Packages), `RELEASING.md` (bumping a Linux tool, Packages, one-time setup step 6 done), the README (the standalone AppImage's size and first-start download), and `docs/development.md`. `docs/releases.md` and `RELEASING.md` are byte-identical with the launcher PR. ## Flags and settings | Flag | What it does | Default now | Recommendation | Helps on | Doesn't help on | Untested on | |---|---|---|---|---|---|---| | `LONGSHOT_BUILDER_HOME` (existing) | also moves the AppImage's toolchains folder | `$XDG_DATA_HOME/longshot/builder` | keep | tests, portable setups | | | | `TOOLS`, `TOOLS_CACHE` (`appimage.sh`, `check_player_build.sh`) | where the build installs and finds tools.lock's Linux tools | `build-linux/tools`, `build-linux/tools-cache` | keep | developers | | | ## Measurements main: b9cdc432 (2026-11-12) this PR: linux-tools-lock @ 78d14610 Hardware: Ryzen desktop, 24 threads, 30 GB, CachyOS (Linux 7.3); the build in `longshot-linux-build` (Ubuntu 22.04, as CI) Method: `deps.sh` + `appimage.sh` in the container, `LONGSHOT_VERSION=v3.0.0-measure`. The size is the AppImage file's. The per-tool share is each folder of main's AppDir compressed with zstd -15, which approximates the AppImage's squashfs zstd. The package size is the uploaded zip. The AppImage is deterministic in size: main was built once, this PR twice (both 94,575,096 bytes). How to reproduce: `scripts/linux/docker.sh` on each commit (with `--network host` where the container's DNS fails), then `stat -c %s build-linux/*.AppImage`. | | main @ b9cdc432 | this PR @ 78d14610 | |---|---|---| | `Longshot-<v>-x86_64.AppImage` | 244,689,400 B (234 MB) | 94,575,096 B (91 MB) | | AppDir, uncompressed | 889.9 MB | 359.2 MB | | Tool | In main's AppImage (zstd est.) | Package zip (this PR) | Unpacked | |---|---|---|---| | emsdk (clang, lld, llvm-profdata) | 119.6 MB | 141,542,909 B | 415.7 MB | | sysroot | 9.3 MB | 15,857,135 B | 51.7 MB | | ffmpeg + dav1d | 7.7 MB | 9,796,808 B | 36.9 MB | | cpm (Vulkan, SPIR-V, VMA headers) | 1.6 MB | 2,343,062 B | 25.3 MB | | sdl2 | 0.9 MB | 889,975 B | 2.3 MB | | stays: Python + Tk | 72.1 MB | | 314.4 MB | | stays: longshot_vk.so | 4.5 MB | | 14.0 MB | A first start downloads 170.4 MB once (516 MB unpacked). A later version downloads only the tools whose line changed. ## Testing **Tested:** - `LONGSHOT_VULKAN_HEADERS=/usr/include python -I -B tests/run_all.py`, interleaved: main 492 passed, 2 failed, 36 skipped; this PR 493 passed, 2 failed, 36 skipped (the new `test_linux_tools.py`); main again 492/2/36. The 2 failures are the known ones and fail on main too: `test_bake_portability`, `test_builder_log_read_only`. - New tests: - `tests/test_linux_tools.py`: the lookup order, the first-start download with progress, offline later starts, hard links across versions, the launcher's copy used as is, a changed download installing nothing, a changed stamp, and AppRun itself (`--cli --prepare` with tools found offline, `--cli` stopping without them, `--play` needing none). It uses fakes and no network. - `test_tools_lock`: Linux lines, systems kept apart, `pack`/`unpack` modes and links, links leading outside refused, the package store, `check --require` per system and with the store, and the profile not required. - Updated without weakening: `test_appimage_player_build` (the tools at their tools.lock places, DLSS with `RX_CPM`), `test_linux_update` (the sysroot loop, now in deps.sh, also round-tripped through `tools.py pack`/`unpack`), `test_make_game_ngx`. - The AppImage built twice in the Ubuntu 22.04 container, and `check_player_build.sh` passed: `--cli --help`, the pipeline list, `build.py --standalone --dry-run` with 0 missing, nothing written into the image. - A real first start outside the container, with an empty builder home: `Longshot-v3.0.0-measure-x86_64.AppImage --cli --help` downloaded the 5 tools from the package URLs, unpacked 516 MB and ran make_game. The second start took 0.15 s and downloaded nothing. - `tools.py check --require` passes against the uploaded packages. **Not tested:** - A game build or play with the new AppImage: no game here. The tools are the same bytes main's AppImage carried, built by the same deps.sh pins, but packed and unpacked through `tools.py`. - The builder window's Tk progress window, on screen. - The new Windows `cpm`/`third-party` on Windows. dav1d was built with `scripts/windows/dav1d.sh` (llvm-mingw 20261104 for Linux, nasm 2.16.01, libdav1d.a sha256 e6f1adec…), not run under Wine here. **Needs other testers:** - Linux, any distribution: start a fresh `Longshot-*.AppImage` with no `~/.local/share/longshot/builder/toolchains`, build and play. Expect a download window (about 170 MB), then a normal build (request to open). - Windows: `LongshotBuilder.exe` with this tools.lock. Expect the setup to install `third-party`. This may fail, see Reviewer notes (request to open; blocked on the setup.c follow-up). ## Screenshots Nothing on screen (the first-start progress window is new, but there was no display here to capture it). ## Risk and rollback - A launcher without its matching PR runs `make_game.py` from an unpacked AppImage that has no tools, so its Linux builds fail. Merge and release the launcher PR first. An AppImage started by itself is unaffected. - Reverting this commit brings the bundled AppImage back. The packages can stay where they are. ## Reviewer notes - **`third-party` on Windows is likely broken by `setup.c`.** The archive is uploaded and in tools.lock. But `builder/setup/setup.c` moves a tool's prefix folder onto its `dest` with `MoveFileW`, which fails when the dest exists, and `LongshotBuilder/tools/third_party` is already in the builder zip. Its reuse also moves an older version's whole folder. The launcher merges files and is fine. This needs a follow-up in `setup.c` (merge a tool into an existing dest), or another dest. - **The `third-party` archive comes from Hookshot v2.1.0's part** (`c361af47…`, 29,574,904 B, the same as in v2.1.0's `hookshot-setup.txt`), keeping only its 8 prebuilt files. Its `a64emit.dll.sha1` stamp doesn't match Longshot's `a64emit.cpp` + `arm64_to_c.h` (whose bytes are unchanged since v2.1.0), so the player's PC would rebuild a64emit.dll anyway. - `scripts/release.py` still says "the tools release" in two comments. It is shared with the launcher, so it is left for a follow-up. - `scripts/linux/make_parts.py` and `linux_update.py`'s parts-list path (dev only) still describe the bundled layout. ## Issues See MagicBeanDev/LongshotLauncher#4 ## Checklist ### For everyone - [x] One topic. - [x] The title is a Conventional Commit (`type(scope): description`). - [x] Rebased on current `main`. - [x] `python -I -B tests/run_all.py` run and passing (any failure that also fails on `main` is named above). - [x] Tested in the game, or what wasn't is named under Testing. - [x] Testing filled in: what was tested, what wasn't, and what needs other testers (with test requests). - [x] Measured: main and this PR at named commits, on the same PC, scene and settings, at least 2 interleaved runs each, the median reported. - [x] No game files, dumps, build output or generated files. - [x] `third_party/` untouched (a new folder with a `PROVENANCE.md` instead). - [x] The license is OK: GPL-3.0-or-later, nothing incompatible and nothing decompiled. ### If applicable - [x] Flags noted, and the switch reference updated (docs/development.md, the README). - [x] A game-free test added for the fix, failing on `main` and passing here. - [x] A check under `tests/` that reads changed source updated in this PR, not weakened. - [x] Host code builds on both Windows (llvm-mingw) and Linux, with UTF-8 paths. (`builder/setup/setup.c`: one comment changed, no code.) - [x] Docs updated.
build(linux): the Linux builder gets its build tools from tools.lock, as Windows does
Some checks failed
CI / Python source checks (ubuntu-24.04, part 1/2) (pull_request) Has been skipped
Details
CI / Python source checks (ubuntu-24.04, part 2/2) (pull_request) Has been skipped
Details
CI / SPIR-V fixtures (global narrow load/store, direct surface atomics, F2I immediate) (pull_request) Has been skipped
Details
Third-party parts / The same as upstream (pull_request) Has been skipped
Details
CI / Conventional Commit title (pull_request) Successful in 2s
Details
CI / Workflow lint (actionlint) (pull_request) Failing after 4s
Details
Third-party parts / As their notes say (pull_request) Successful in 5s
Details
PR description / Description follows the template (pull_request_target) Successful in 2s
Details
78d1461081 
The AppImage carried LLVM, the sysroot, FFmpeg, SDL2 and the Vulkan headers in every release (244.7 MB). They are now
tools.lock's linux-x64 lines, published once as packages and shared across versions: the launcher unpacks them beside
the AppImage, and an AppImage started by itself downloads them at its first start into its toolchains folder. The
AppImage keeps the builder, its Python and the Vulkan back end (94.6 MB). The build tools of both systems are files of
the organization's generic packages, and the play profile is no longer required.
HumanBean changed title from WIP: build(linux): the Linux builder gets its build tools from tools.lock, as Windows does to build(linux): the Linux builder gets its build tools from tools.lock, as Windows does 2026-11-13 04:42:25 +00:00
HumanBean deleted branch linux-tools-lock 2026-11-13 04:42:38 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
area/accessibility
Barriers for people with disabilities

  
area/audio
Sound and music

  
area/input
Controllers, keyboard, mouse

  
area/install
Installing, updating, building from your game

  
area/menu
In-game menu and settings

  
area/renderer
Vulkan renderer, shaders, effects

  
area/saves
Save files

  
area/upscaling
DLSS, FSR, frame generation

  
good first issue
A good start for a new contributor

  
gpu/amd
AMD GPUs

  
gpu/intel
Intel GPUs

  
gpu/nvidia
NVIDIA GPUs

  
help wanted
Extra hands or knowledge wanted

  
kind
bug
 Something doesn't work as it should

  
kind
chore
 Build, CI, dependencies, tidying

  
kind
docs
 Documentation

  
kind
feature
 A new feature or an improvement

  
kind
performance
 Frame rate, frame time, loading, memory

  
kind
question
 A question rather than a change

  
needs measurements
Waiting for before/after measurements

  
platform/linux
Linux only

  
platform/steam-deck
Steam Deck

  
platform/windows
Windows only

  
preview
Maintainers: deploy a preview of this PR's website (read its changes first). Removed after the run.

  
priority
critical
 Crashes, data loss, or blocks most players

  
priority
high
 Important: next in line

  
priority
low
 Nice to have

  
status
blocked
 Waits on something else first

  
status
confirmed
 Reproduced or agreed on

  
status
duplicate
 Already reported or proposed

  
status
invalid
 Not a problem in this project

  
status
needs-info
 Waiting for more information from the reporter

  
status
wontfix
 Will not be worked on

  
testing wanted
Wanted: a test on other hardware (posts a test request in #test-requests)

No labels
area/accessibility
area/audio
area/input
area/install
area/menu
area/renderer
area/saves
area/upscaling
good first issue
gpu/amd
gpu/intel
gpu/nvidia
help wanted
kind
bug
kind
chore
kind
docs
kind
feature
kind
performance
kind
question
needs measurements
platform/linux
platform/steam-deck
platform/windows
preview
priority
critical
priority
high
priority
low
status
blocked
status
confirmed
status
duplicate
status
invalid
status
needs-info
status
wontfix
testing wanted
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
MagicBeanDev/Longshot!113
No description provided.