fix(release): actually build the arm64 binary it packages #18

wtclaude · 2026-08-07T20:31:24Z

wtclaude commented

2026-08-07 20:31:24 +00:00

What & why

The cutover merged and release.yml fired — and died at the packaging step:

cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/runicgateway-installer':
    No such file or directory
❌ Failure - Main Package artifacts and SHA256SUMS

installer#10 added linux-aarch64 in three of the four places it belongs — the rustup target add, the cp into dist/, and the SHA256SUMS line — but never added a build step for it. Nothing produced the binary, so the run got all the way to packaging before noticing.

This is not fallout from the cutover merge. The step is absent from edge at 8e52583 too, i.e. before main was merged into it; release.yml auto-merged without dropping anything. It has simply never existed.

No tag and no release were created — the run planned v0.1.0 and failed before tagging — so merging this and re-running produces a clean first release.

What changed

Build arm64, using the same linker / CC / AR env pattern the Windows cross build already uses.
Name libc6-dev-arm64-cross in the apt install. gcc-aarch64-linux-gnu only recommends it and that step runs --no-install-recommends, so without it the Rust half of the build succeeds and then ring (under ureq's rustls) dies compiling C on a missing bits/libc-header-start.h. This is the same trap PLAN.md §5.2 records for both crates.

How it was tested

Reproduced the CI environment in rust:1-slim-bookworm — the same apt line including --no-install-recommends, then the same cargo invocation:

Compiling ureq v3.3.0
Compiling runicgateway-installer v0.1.0 (/w)
 Finished `release` profile [optimized] target(s) in 44.02s

-rwxr-xr-x 4690840  /tmp/target/aarch64-unknown-linux-gnu/release/runicgateway-installer

Builds clean and emits the binary at exactly the path the packaging step reads.

Also: the workflow parses as YAML (13 steps, all three build steps present), and contains no empty ${{ }} tokens — the trap that silently skipped a step in bundle.yml.

After this merges

Re-running the release should publish v0.1.0 with four assets: linux-x86_64, linux-aarch64, windows-x86_64.exe, and SHA256SUMS.

Worth knowing: the sync workflow (project-tree sync) also failed on the cutover commit. That is a separate issue and is not addressed here.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand
every change, and take responsibility for it. AI-authored commits are
marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license
(GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why The cutover merged and `release.yml` fired — and died at the packaging step: ``` cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/runicgateway-installer': No such file or directory ❌ Failure - Main Package artifacts and SHA256SUMS ``` `installer#10` added `linux-aarch64` in three of the four places it belongs — the `rustup target add`, the `cp` into `dist/`, and the `SHA256SUMS` line — but **never added a build step for it**. Nothing produced the binary, so the run got all the way to packaging before noticing. This is not fallout from the cutover merge. The step is absent from `edge` at `8e52583` too, i.e. before `main` was merged into it; `release.yml` auto-merged without dropping anything. It has simply never existed. **No tag and no release were created** — the run planned `v0.1.0` and failed before tagging — so merging this and re-running produces a clean first release. ## What changed - **Build arm64**, using the same linker / `CC` / `AR` env pattern the Windows cross build already uses. - **Name `libc6-dev-arm64-cross` in the apt install.** `gcc-aarch64-linux-gnu` only *recommends* it and that step runs `--no-install-recommends`, so without it the Rust half of the build succeeds and then `ring` (under `ureq`'s rustls) dies compiling C on a missing `bits/libc-header-start.h`. This is the same trap PLAN.md §5.2 records for both crates. ## How it was tested Reproduced the CI environment in `rust:1-slim-bookworm` — the same apt line including `--no-install-recommends`, then the same cargo invocation: ``` Compiling ureq v3.3.0 Compiling runicgateway-installer v0.1.0 (/w) Finished `release` profile [optimized] target(s) in 44.02s -rwxr-xr-x 4690840 /tmp/target/aarch64-unknown-linux-gnu/release/runicgateway-installer ``` Builds clean and emits the binary at exactly the path the packaging step reads. Also: the workflow parses as YAML (13 steps, all three build steps present), and contains no empty `${{ }}` tokens — the trap that silently skipped a step in `bundle.yml`. ## After this merges Re-running the release should publish `v0.1.0` with four assets: `linux-x86_64`, `linux-aarch64`, `windows-x86_64.exe`, and `SHA256SUMS`. Worth knowing: the `sync` workflow (project-tree sync) also failed on the cutover commit. That is a separate issue and is not addressed here. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-07 20:31:26 +00:00

fix(release): actually build the arm64 binary it packages

PR Checks / rust-gates (pull_request) Successful in 1m56s

Details

007791c4fc

The first release attempt failed at packaging:

  cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/runicgateway-installer':
      No such file or directory

installer#10 added linux-aarch64 in three of the four places it belongs — the
rustup target, the `cp` into dist/, and the SHA256SUMS line — but never added a
build step for it. Nothing ever produced the binary, so the run got all the way
to packaging before noticing. No tag or release was created, so a retry is clean.

Two changes:

- Build arm64, with the same linker/CC/AR env pattern the Windows cross build
  already uses.
- Name `libc6-dev-arm64-cross` in the apt install. gcc-aarch64-linux-gnu only
  *recommends* it and this step runs --no-install-recommends, so without it the
  Rust half builds and then `ring` (under ureq's rustls) dies compiling C on a
  missing bits/libc-header-start.h.

Verified by reproducing CI in rust:1-slim-bookworm — the same apt line including
--no-install-recommends, then the same cargo invocation. Builds clean and emits
a 4.6 MB binary at exactly the path the packaging step reads.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech approved these changes 2026-08-07 20:35:44 +00:00

whitlocktech merged commit f81cbcdd04 into main

2026-08-07 20:35:55 +00:00

whitlocktech deleted branch fix/release-arm64-build

2026-08-07 20:35:55 +00:00

whitlocktech referenced this issue from a commit

2026-08-07 20:35:56 +00:00

Merge pull request 'fix(release): actually build the arm64 binary it packages' (#18) from fix/release-arm64-build into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/installer#18