You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Tracking the one remaining step of the cross-compilation migration. The purge itself is merged (#1416, e4a871a9); the release that should carry it has not been cut, because it is gated on an upstream publish that has not landed yet.
The directive
purge all cargo zigbuild and zig cc and xwin — soldr has its new blessed cross compiler. Update AI docs, develop linting to ensure this is purged, migrate everything to soldr cross compiles, then push and mint a new release. At the end, no relying on cargo zigbuild or xwin at all for any windows or mac builds.
done — agents/docs/cross-compilation.md, wired into the root routing table
3
Develop linting
done — ci/check_no_legacy_cross.py + 7 unit tests, wired into ci-workflow-drift.yml; ci/hooks/tool_guard.py blocks the commands in real time
4
Migrate to soldr cross
done — four per-target branches collapsed to one soldr prepare + soldr build
5
Push
done — merged to main
6
Mint a release
blocked
The end-state condition — no zigbuild/xwin for any windows or mac build — is met and CI-proven on run 33815922498: aarch64-apple-darwin and x86_64-pc-windows-msvc both green through soldr build, with the cargo-xwin install, the xwin system-deps step and ~40 lines of CRT-casing symlink repair deleted.
What blocks the release
main's musl lanes are red until soldr 0.9.12 is installable. setup-soldr is pinned to 0.9.12 in template_native_build.yml, and that version does not exist on PyPI yet.
Cutting the release before then would ship a partial artifact set: the musl lanes produce both Linux CLI binaries and 2 of the 4 wheels, and ci/publish.py's file-count gate would reject the upload anyway.
Three independent soldr defects stood between the migration and a publishable 0.9.12. All three are fixed and merged:
soldr exported PKG_CONFIG_SYSROOT_DIR; pkg-config prefixed it onto every absolute -L, so a managed syslib resolved to sysroot+absolute. Our musl lanes died with ld: cannot find -lbz2.
Release staging ran host GNU binutils against cross-built artifacts — objcopy: Unable to recognise the format of the input file, strip: file format not recognized.
publish was gated on a macOS Recovery-guest replay that had never once been green (a missing mkdir -p before --extract-to, behind four earlier harness defects).
soldr release run 33827340201 is in flight on the fixed commit with eight of nine build lanes green.
To finish
Confirm soldr 0.9.12 is on PyPI: curl -s "https://pypi.org/simple/soldr/" -H "Accept: application/vnd.pypi.simple.v1+json" | grep -c 0.9.12
If run 33827340201 did not publish, re-dispatch: gh workflow run release-auto.yml --repo zackees/soldr --ref main (the push trigger filters on Cargo.toml/package.json, so a workflow-only merge will not fire it).
Prove all four fbuild lanes green on main: gh workflow run build.yml --repo FastLED/fbuild --ref main -f ref=main
Expect x86_64-unknown-linux-musl, aarch64-unknown-linux-musl, aarch64-apple-darwin, x86_64-pc-windows-msvc.
Bump 2.5.22 → 2.5.23 in bothCargo.toml ([workspace.package].version) and pyproject.toml ([project].version), refresh Cargo.lock with soldr cargo check -p fbuild-cli, and push to main. Do not push a tag — the action creates it after a successful upload.
Watch the Autonomous Release run; verify 4 wheels appear on PyPI.
Verify the floor on any change to the wheel lane: objdump -T <lib>.so | grep -o 'GLIBC_[0-9.]*' | sort -Vu | tail
Never install a floating version of a build tool in a release lane. The unpinned pip install cargo-zigbuild floated 0.23.1 → 0.23.4 mid-release and broke both apple-darwin lanes of 2.5.22.
Tracking the one remaining step of the cross-compilation migration. The purge itself is merged (#1416,
e4a871a9); the release that should carry it has not been cut, because it is gated on an upstream publish that has not landed yet.The directive
Status
cargo-zigbuild/zig cc/cargo-xwinagents/docs/cross-compilation.md, wired into the root routing tableci/check_no_legacy_cross.py+ 7 unit tests, wired intoci-workflow-drift.yml;ci/hooks/tool_guard.pyblocks the commands in real timesoldr prepare+soldr buildmainThe end-state condition — no zigbuild/xwin for any windows or mac build — is met and CI-proven on run 33815922498:
aarch64-apple-darwinandx86_64-pc-windows-msvcboth green throughsoldr build, with thecargo-xwininstall, the xwin system-deps step and ~40 lines of CRT-casing symlink repair deleted.What blocks the release
main's musl lanes are red until soldr 0.9.12 is installable.setup-soldris pinned to 0.9.12 intemplate_native_build.yml, and that version does not exist on PyPI yet.Cutting the release before then would ship a partial artifact set: the musl lanes produce both Linux CLI binaries and 2 of the 4 wheels, and
ci/publish.py's file-count gate would reject the upload anyway.Three independent soldr defects stood between the migration and a publishable 0.9.12. All three are fixed and merged:
PKG_CONFIG_SYSROOT_DIR; pkg-config prefixed it onto every absolute-L, so a managed syslib resolved to sysroot+absolute. Our musl lanes died withld: cannot find -lbz2.objcopy: Unable to recognise the format of the input file,strip: file format not recognized.publishwas gated on a macOS Recovery-guest replay that had never once been green (a missingmkdir -pbefore--extract-to, behind four earlier harness defects).soldr release run 33827340201 is in flight on the fixed commit with eight of nine build lanes green.
To finish
curl -s "https://pypi.org/simple/soldr/" -H "Accept: application/vnd.pypi.simple.v1+json" | grep -c 0.9.12If run 33827340201 did not publish, re-dispatch:
gh workflow run release-auto.yml --repo zackees/soldr --ref main(thepushtrigger filters onCargo.toml/package.json, so a workflow-only merge will not fire it).main:gh workflow run build.yml --repo FastLED/fbuild --ref main -f ref=mainExpect
x86_64-unknown-linux-musl,aarch64-unknown-linux-musl,aarch64-apple-darwin,x86_64-pc-windows-msvc.2.5.22→2.5.23in bothCargo.toml([workspace.package].version) andpyproject.toml([project].version), refreshCargo.lockwithsoldr cargo check -p fbuild-cli, and push tomain. Do not push a tag — the action creates it after a successful upload.Do not regress
.2.17glibc suffix to a soldr target. soldr has no such target, warns, falls back to the bare host toolchain and still exits 0, producing a GLIBC_2.39.sotaggedmanylinux_2_17that installs fine and fails at import on anything older than the build host. soldr's own sysroot links at 2.16, below the floor. Upstream papercut: soldr build silently falls back to the host toolchain for an unknown target and exits 0 (ships wrong-glibc manylinux wheels) zackees/soldr#3082.objdump -T <lib>.so | grep -o 'GLIBC_[0-9.]*' | sort -Vu | tailpip install cargo-zigbuildfloated 0.23.1 → 0.23.4 mid-release and broke both apple-darwin lanes of 2.5.22.Full rationale in
agents/docs/cross-compilation.md.