hestia (the actual deployment target) runs Ubuntu 24.04 (glibc 2.39);
the shared Arch CI image tracks a much newer glibc (currently 2.43).
A binary linked normally there requires GLIBC_2.43 symbols and refuses
to start on hestia at all (glibc symbol versioning is forward-only) —
this is what crashed breadarrd in production after its first
bakery-managed install.
Fix: ci/build.sh now pulls a real glibc + gcc-libs (for libstdc++)
package pair from the Arch Linux Archive, matching hestia's actual
versions, and links against them via --sysroot instead of the
container's native ones. cargo-zigbuild (targeting an older glibc via
zig's cross-linker) was tried first and doesn't work here: zig has no
version database for libstdc++ specifically, and onnxruntime --
statically linked in by the ort crate -- needs a real, complete one.
A real archived glibc+gcc-libs pair sidesteps that entirely.
reqwest's native-tls now vendors (statically builds) OpenSSL instead
of dynamically linking the build host's, since the old sysroot has no
libssl/libcrypto of its own — also means the shipped binary no longer
depends on the target system's OpenSSL version at all.
Verified end-to-end on hestia's actual self-hosted runner: real
ci/build.sh, real bread-ci:breadarr image, real docker build/run —
produced binary requires GLIBC up to 2.39 and GLIBCXX up to 3.4.30
only, and actually starts and runs on hestia.
Adds ci/build.sh + ci/bread-ecosystem.rev (pinned to bread-ecosystem
147cfbbf96ae4b171027defa1130d2caddb934b1), points the three release
workflows' build step through it, and adds check.yml as breadarr's first
lint/test gate on feature/fix branches. No ci/deps.txt: verified ort-sys's
build.rs has no system build-time requirements beyond rust/base-devel
(its download-binaries feature is pure-Rust ureq/lzma-rust2/hmac-sha256).
