fbuild: Add version 2.5.21

[luhenry]

• Package: fbuild
• Version: 2.5.21
• Source: https://github.com/FastLED/fbuild
• Docs: https://pypi.org/project/fbuild/

Compiles the Rust fbuild and fbuild-daemon binaries and the PyO3 _native abi3 extension of FastLED's PlatformIO-compatible embedded build tool. Upstream publishes no riscv64 wheel (and no sdist).

Mirrors upstream's template_native_build.yml and the build-pypi job of release-auto.yml, assembling the wheel with the checkout's own ci/publish.py.

Differs from upstream

• Native glibc build in manylinux_2_39_riscv64 - upstream cross-builds static musl binaries with cargo-zigbuild
• No -D warnings - lint gate, not packaging

Matrix: one cp310-abi3 wheel, tested on 3.12/3.13/3.14; abi3 is not installable on 3.14t.

Testing

• same as upstream (fbuild --version, import fbuild), plus find_firmware and a licence-metadata check

License: Upstream wheels ship no licence text for the AGPL-3.0-only project, so the build adds it.

Patches

• 0001-publish-ship-LICENSE-in-wheels.patch - To upstream [upstream's wheels ship no licence file or licence metadata on any platform]. Without it the wheel carries no LICENSE. Reproduces on every platform.

[luhenry]

Root cause

The failing job (Build fbuild 2.5.21 manylinux_riscv64, run 38713460011) is a genuine build error, not a runner hiccup — it ran for ~31 minutes on a real runner and failed with actual Rust compile errors:

error[E0425]: cannot find type `__jmp_buf` in this scope
  --> crash-handler-0.6.3/src/linux/jmp.rs:51:16
error[E0609]: no field `fpregs` on type `crash_context::mcontext_t`
  --> crash-handler-0.6.3/src/linux/state.rs:461:48 (and :462)

0002 (vendor-crash-context-riscv64.patch) already vendors crash-context 0.7.0 to fix riscv64 support in that crate. But crash-handler 0.6.3 — pulled in separately by zccache, an external git dependency — has its own arch-specific code that also lacks riscv64: linux/jmp.rs's __jmp_buf layout and linux/state.rs's float-state read (uc_mcontext.fpregs, which doesn't exist on riscv64 glibc; the real field is __fpregs). That's a different crate from crash-context and isn't touched by 0002. (Cargo.lock also resolves a second crash-handler 0.7.0 for running-process's pin — that one already has riscv64 support, so only the 0.6.3 line used by zccache is broken.)

Fix

Added patches/fbuild/2.5.21/0003-vendor-crash-handler-riscv64.patch, following the exact same pattern as 0002: vendors the complete, unmodified crash-handler 0.7.0 release under vendor/crash-handler/, version string turned back to "0.6.3" so it still satisfies zccache's crash-handler = "0.6" requirement, wired in via a second [patch.crates-io] entry alongside the existing crash-context one.

Validated locally with cargo check --target riscv64gc-unknown-linux-gnu:

• registry crash-handler 0.6.3 + 0002's patched crash-context (i.e. today's state) reproduces the CI failure byte-for-byte (same file:line, same error codes).
• this patch's vendored crash-handler + 0002's patched crash-context together compiles cleanly for riscv64gc.

Pushed to fbuild as 100f547821c.