From 32848e6bea1abeac1384024e31398ab908328921 Mon Sep 17 00:00:00 2001 From: Vader Yang Date: Sat, 12 Sep 2026 18:39:07 +0800 Subject: [PATCH 1/4] =?UTF-8?q?ci(release):=20upgrade=20cargo-zigbuild=20?= =?UTF-8?q?=E2=80=94=200.19.6=20cannot=20link=20aarch64=20any=20more?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The aarch64-unknown-linux-musl leg of the release matrix fails at link time: error: unsupported linker arg: --fix-cortex-a53-843419 rustc stable passes that flag for aarch64 targets (the Cortex-A53 erratum workaround), and zig's linker rejects unknown args outright rather than warning. cargo-zigbuild's job is to translate rustc's linker invocation into something zig accepts, and it learned to filter this one in 0.23.0 (rust-cross/cargo-zigbuild#452, `filter_linker_arg` in src/zig.rs). The pin was 0.19.6, released 2024-12-16 — long before the flag existed. Nothing in this repo changed; `dtolnay/rust-toolchain@stable` moved under it, which is the hazard of pinning one half of a toolchain pair and floating the other. This broke the v0.8.0 tag: three targets built, aarch64 did not, so no release was created. Zig deliberately stays on 0.13.0 — 0.15+ wants clang 18+ for crates using bindgen, and duckdb-sys does. Claude-Session: https://claude.ai/code/session_01GxGWpo3L4BRMkwtoa9X54W --- .github/workflows/release.yml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 867bb491..6903e976 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -114,8 +114,18 @@ jobs: version: 0.13.0 - name: Install cargo-zigbuild + # 0.23.x or newer is required: rustc stable now passes + # `-Wl,--fix-cortex-a53-843419` for aarch64 targets, which zig's linker + # rejects outright ("unsupported linker arg"). cargo-zigbuild learned to + # filter it in 0.23.0 (rust-cross/cargo-zigbuild#452); 0.19.6 was + # released in 2024 and predates the flag, so the aarch64-musl leg of + # this matrix failed at link time on every release cut after rustc + # started emitting it. + # + # Zig stays on 0.13: zig 0.15+ needs clang 18+ for crates that use + # bindgen, which duckdb-sys does. run: | - pip install cargo-zigbuild==0.19.6 + pip install cargo-zigbuild==0.23.4 # libpcap is C, not pure Rust. Build it from source against the same # zig/musl target so cargo-zigbuild produces a fully static binary. From 80c9548122d95dc44cdd78e625da8cc2cb271b8b Mon Sep 17 00:00:00 2001 From: Vader Yang Date: Sat, 12 Sep 2026 18:47:13 +0800 Subject: [PATCH 2/4] =?UTF-8?q?release:=20v0.8.1=20=E2=80=94=20same=20cont?= =?UTF-8?q?ent=20as=20the=20unreleased=20v0.8.0,=20plus=20the=20build=20fi?= =?UTF-8?q?x?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit v0.8.0 was tagged and built three of four targets; the aarch64 leg failed to link, so `release.yml` never reached the create-release step and nothing shipped. The tag stays where it is — deleting a pushed tag buys nothing when no release, no asset, and no deploy ever referenced it — so the content moves to 0.8.1 instead. The CHANGELOG section is renamed rather than duplicated: release.yml extracts the section matching the tag and fails the build if there is none, and a two-line 0.8.1 section pointing at a 0.8.0 section would have produced release notes that omitted everything the release actually contains. The section now opens by saying there is no released 0.8.0 to upgrade from, so the gap in the version sequence is explained where someone will look for it. Claude-Session: https://claude.ai/code/session_01GxGWpo3L4BRMkwtoa9X54W --- CHANGELOG.md | 14 +++++++++++++- VERSION | 2 +- console/package.json | 2 +- server/Cargo.toml | 2 +- 4 files changed, 16 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 13905045..095ebbd5 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,7 +6,12 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] -## [0.8.0] — 2026-09-12 +## [0.8.1] — 2026-09-12 + +`v0.8.0` was tagged from this same content but never released: the +`aarch64-unknown-linux-musl` leg of the release matrix failed to link, so no +release was created and nothing shipped. 0.8.1 is that content plus the build +fix — there is no released 0.8.0 to upgrade from. ### Changed @@ -58,6 +63,13 @@ adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ### Fixed +- **The aarch64 Linux release binary could not be linked.** rustc stable passes + `-Wl,--fix-cortex-a53-843419` for aarch64 targets and zig's linker rejects + unknown arguments outright, so that leg of the release matrix failed and, with + it, the whole release. `cargo-zigbuild` gained a filter for the flag in + 0.23.0; the pin here was 0.19.6, from 2024. Nothing in Heron changed — + `rust-toolchain@stable` moved underneath a pinned build tool, which is what + broke `v0.8.0`. - **`/api/runtime-config` was handing out stored credentials.** It returns the whole `AppConfig` to the console, and `heron config validate --json` prints it, so `storage.aglake.hec_token` and `storage.clickhouse.password` were diff --git a/VERSION b/VERSION index a3df0a69..6f4eebdf 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.8.0 +0.8.1 diff --git a/console/package.json b/console/package.json index c30691e1..a8881aea 100644 --- a/console/package.json +++ b/console/package.json @@ -1,7 +1,7 @@ { "name": "console", "private": true, - "version": "0.8.0", + "version": "0.8.1", "type": "module", "scripts": { "dev": "vite", diff --git a/server/Cargo.toml b/server/Cargo.toml index 67052c89..0e4ded6b 100644 --- a/server/Cargo.toml +++ b/server/Cargo.toml @@ -8,7 +8,7 @@ exclude = ["h-ebpf-prog"] resolver = "2" [workspace.package] -version = "0.8.0" +version = "0.8.1" edition = "2021" license = "Apache-2.0" From 3b46b2eaa93bcec955bb923c6831335487500e83 Mon Sep 17 00:00:00 2001 From: Vader Yang Date: Sat, 12 Sep 2026 19:00:51 +0800 Subject: [PATCH 3/4] =?UTF-8?q?ci(release):=20pin=20ziglang=20too=20?= =?UTF-8?q?=E2=80=94=20it=20was=20the=20half=20that=20was=20actually=20flo?= =?UTF-8?q?ating?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Upgrading cargo-zigbuild fixed the aarch64 link error and broke both Linux targets a different way: they built, but produced dynamically linked binaries, which the static-link check rejected, so no tarball was produced. The cause is that `ziglang` is a pip dependency of cargo-zigbuild with an open upper bound (`ziglang>=0.9.0`), and the zig it installs lands on PATH ahead of whatever `setup-zig` provided. So this workflow has never actually built with the zig version it declared — pip's resolution decided, and it had drifted to 0.16, where the static build silently stops being static. Both halves are now pinned to what the matrix has really been building with: cargo-zigbuild 0.23.4 (has the aarch64 arg filter) and ziglang 0.13.0. The `setup-zig` step is dropped rather than left to imply a version it never controlled, and the install step now prints the zig version so the next person does not have to infer it from a libcxx include path in a build log. Claude-Session: https://claude.ai/code/session_01GxGWpo3L4BRMkwtoa9X54W --- .github/workflows/release.yml | 37 +++++++++++++++++++++-------------- 1 file changed, 22 insertions(+), 15 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index 6903e976..a993fda6 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -109,23 +109,30 @@ jobs: workspaces: server -> target key: ${{ matrix.target }} - - uses: goto-bus-stop/setup-zig@v2 - with: - version: 0.13.0 - - - name: Install cargo-zigbuild - # 0.23.x or newer is required: rustc stable now passes - # `-Wl,--fix-cortex-a53-843419` for aarch64 targets, which zig's linker - # rejects outright ("unsupported linker arg"). cargo-zigbuild learned to - # filter it in 0.23.0 (rust-cross/cargo-zigbuild#452); 0.19.6 was - # released in 2024 and predates the flag, so the aarch64-musl leg of - # this matrix failed at link time on every release cut after rustc - # started emitting it. + - name: Install cargo-zigbuild + zig + # BOTH halves are pinned, and they have to be. + # + # cargo-zigbuild must be >= 0.23.0: rustc stable passes + # `-Wl,--fix-cortex-a53-843419` for aarch64 targets and zig's linker + # rejects unknown args outright, so the aarch64-musl leg failed at link + # time ("unsupported linker arg"). 0.23.0 added a filter for it + # (rust-cross/cargo-zigbuild#452). The old pin, 0.19.6, is from 2024 and + # predates the flag entirely. + # + # `ziglang` must be pinned too, and this is the subtle one: it is a hard + # dependency of the pip package with an open upper bound + # (`ziglang>=0.9.0`), and the zig it installs is the one that ends up on + # PATH — ahead of anything a setup-zig action provides. So the zig + # version was floating no matter what that action said, and when pip + # resolved it to 0.16 both Linux targets silently produced *dynamically + # linked* binaries, which the static check below then rejected. 0.13.0 + # is the version this matrix has always actually built with. # - # Zig stays on 0.13: zig 0.15+ needs clang 18+ for crates that use - # bindgen, which duckdb-sys does. + # Staying on 0.13 is also deliberate: zig 0.15+ wants clang 18+ for + # crates that use bindgen, and duckdb-sys does. run: | - pip install cargo-zigbuild==0.23.4 + pip install cargo-zigbuild==0.23.4 ziglang==0.13.0 + zig version || python -m ziglang version # libpcap is C, not pure Rust. Build it from source against the same # zig/musl target so cargo-zigbuild produces a fully static binary. From cfaec6ff45b464d206edc9bfd2272e8f65c15451 Mon Sep 17 00:00:00 2001 From: Vader Yang Date: Sat, 12 Sep 2026 19:05:11 +0800 Subject: [PATCH 4/4] =?UTF-8?q?ci(release):=20put=20setup-zig=20back=20?= =?UTF-8?q?=E2=80=94=20libpcap=20needs=20a=20`zig`=20on=20PATH?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit My last commit removed it on the reasoning that pip's ziglang wins on PATH and the action was therefore decorative. That was wrong, and the next run said so: libpcap's configure died with "C compiler cannot create executables". The two installs serve different consumers. * the action puts a `zig` *executable* on PATH, which the libpcap step needs because it builds C with `CC="zig cc -target …"`. The pip package exposes `python -m ziglang` and no `zig` binary, so nothing else provides it. * pip's `ziglang` is what cargo-zigbuild uses to link the Rust side, and its open-bounded requirement (`ziglang>=0.9.0`) is what had drifted to 0.16 and quietly turned both Linux builds dynamic. So both are required and both are now pinned to 0.13.0. The install step prints each version separately, because a mismatch between them is exactly the kind of thing that otherwise surfaces three steps later as an unrelated-looking C compiler error. Claude-Session: https://claude.ai/code/session_01GxGWpo3L4BRMkwtoa9X54W --- .github/workflows/release.yml | 38 ++++++++++++++++++++++------------- 1 file changed, 24 insertions(+), 14 deletions(-) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index a993fda6..00f41968 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -109,9 +109,21 @@ jobs: workspaces: server -> target key: ${{ matrix.target }} - - name: Install cargo-zigbuild + zig - # BOTH halves are pinned, and they have to be. - # + # Two zigs, two consumers — both needed, and both must agree on 0.13. + # + # * this action puts a `zig` executable on PATH. The libpcap step below + # builds C with `CC="zig cc -target …"`, so without it that configure + # fails with "C compiler cannot create executables". + # * pip pulls `ziglang` in as a hard dependency of cargo-zigbuild, and + # *that* copy is what links the Rust side. + # + # They are separate installs, so a version pinned on one says nothing + # about the other. + - uses: goto-bus-stop/setup-zig@v2 + with: + version: 0.13.0 + + - name: Install cargo-zigbuild + pin its zig # cargo-zigbuild must be >= 0.23.0: rustc stable passes # `-Wl,--fix-cortex-a53-843419` for aarch64 targets and zig's linker # rejects unknown args outright, so the aarch64-musl leg failed at link @@ -119,20 +131,18 @@ jobs: # (rust-cross/cargo-zigbuild#452). The old pin, 0.19.6, is from 2024 and # predates the flag entirely. # - # `ziglang` must be pinned too, and this is the subtle one: it is a hard - # dependency of the pip package with an open upper bound - # (`ziglang>=0.9.0`), and the zig it installs is the one that ends up on - # PATH — ahead of anything a setup-zig action provides. So the zig - # version was floating no matter what that action said, and when pip - # resolved it to 0.16 both Linux targets silently produced *dynamically - # linked* binaries, which the static check below then rejected. 0.13.0 - # is the version this matrix has always actually built with. + # `ziglang` needs pinning for a different reason: the dependency is + # declared `ziglang>=0.9.0`, so pip resolves it to whatever is newest. + # It reached 0.16, where both Linux targets silently produced + # *dynamically linked* binaries and the static check below rejected + # them. Pinning it to 0.13.0 matches the action above. # - # Staying on 0.13 is also deliberate: zig 0.15+ wants clang 18+ for - # crates that use bindgen, and duckdb-sys does. + # 0.13 rather than something newer is also deliberate: zig 0.15+ wants + # clang 18+ for crates that use bindgen, and duckdb-sys does. run: | pip install cargo-zigbuild==0.23.4 ziglang==0.13.0 - zig version || python -m ziglang version + echo "PATH zig: $(zig version)" + echo "pip zig: $(python -m ziglang version)" # libpcap is C, not pure Rust. Build it from source against the same # zig/musl target so cargo-zigbuild produces a fully static binary.