Lower the release glibc floor to cover every supported Debian/Ubuntu

[ebursztein]

Why

Since #174, the .deb declares the glibc floor it actually needs, derived from the shipped binaries. Today that floor is 2.39, because docker/Dockerfile.host-builder is FROM ubuntu:24.04.

Users can fairly expect Capsem to work on every supported Debian and Ubuntu release. It currently does not:

Distro	glibc	Status
Ubuntu 24.04 LTS, 26.04 LTS	2.39 / 2.41+	works
Debian 13 trixie (stable)	2.41	works
Ubuntu 22.04 LTS (supported to 2027-04)	2.35	refused
Debian 12 bookworm (LTS to 2028)	2.36	refused
Linux Mint 21.x, Pop!_OS 22.04	2.35	refused

Before #174 these installed cleanly and then every binary failed at runtime. They now get an honest refusal, which is better but still not support.

The lever

The floor is a build-image choice, not a code constraint. Nothing in Capsem requires 2.39. Basing Dockerfile.host-builder on ubuntu:22.04 derives a 2.35 floor and covers everything in the table except Ubuntu 20.04 and Debian 11, both of which are out of standard support. libwebkit2gtk-4.1-0 is available in jammy, so the GUI dependencies still resolve.

Lowering the floor is purely additive: no installed user breaks when it drops.

Scope

• Move the release build base down and let scripts/derive-deb-libc-floor.py re-derive the floor.
• Confirm the Rust toolchain and webkit2gtk-4.1 build cleanly on the older base.
• The glow-up Debian proof added alongside this issue asserts install succeeds iff the probe image's glibc satisfies the declared floor, so it follows the change automatically rather than needing an update.

Not in scope

Ubuntu 20.04 / Debian 11 (glibc 2.31), both past standard support.

[ebursztein]

Reverted: ort cannot cross-link for aarch64 on jammy

The base-image move to Ubuntu 22.04 got to step 83 of 113 (126 minutes) and then failed package.arm64.build:

ld: libort_sys-*.rlib(conv.cc.o): in function
    `onnxruntime::xnnpack::Conv::Compute(...)':
  undefined reference to `__cxa_call_terminate'
collect2: error: ld returned 1 exit status
error: could not compile `capsem-service` (bin "capsem-service")

Prebuilt ONNX Runtime objects will not link against jammy's aarch64 cross toolchain.

"Install gcc-12" is not the fix. __cxa_call_terminate is defined (T) in libstdc++.a for both gcc-11 and gcc-12 on jammy:

--- gcc-11 ---                     --- gcc-12 ---
0000000000000000 T __cxa_call_terminate    0000000000000000 T __cxa_call_terminate

So this is a linkage question — which C++ runtime that Rust link picks up, static vs shared — not a missing toolchain. At ~2h per qualification, guessing at it was the wrong thing to keep doing while 0.6 was unshipped.

The actual dependency to remove

ort is the blocker here and the blocker for #182:

• Lower the release glibc floor to cover every supported Debian/Ubuntu #181 (this issue): prebuilt ONNX Runtime aarch64 objects will not cross-link on jammy.
• Ship a musl/Alpine package so Alpine is supported, not just refused #182 (Alpine): ort-sys publishes no musl binaries at all, and ort-tract is not on crates.io.

One dependency, both platform walls. capsem-service is the only crate pulling it, via magika.

Removing magika's ort dependency is the unblock for both. Measured, it is smaller than it looks: dropping magika from capsem-service produces 2 errors, both in fs_utils.rs. The 13 references in main.rs are to wrapper functions, not to magika. And identify_file_sync already returns ("unknown", "application/octet-stream", "unknown", false) on any magika error, with callers written for it — so the degraded path is one the service already takes, not a new failure mode.

What was kept

The revert restores the base images, the derived apt suite, the native-arch cross list, the carried uv interpreter and the 2.35 floor. Everything the attempt uncovered stays on main:

• the .deb's derived libc floor (deb declares no libc dependency: installs cleanly on older distros, then every binary fails #174)
• the glow-up platform matrix across 10 distro releases
• qualify-assets/qualify-binaries and the no-private-recipe guard
• autonomous nightly
• the dirty-tree release refusal

Retry when

After ort leaves the tree. Then re-apply the base move and the platform matrix flips Ubuntu 22.04 and Debian 12 from "cannot run" to "runs" on its own, because the expectation is derived from each image's real libc rather than written down.

[ebursztein]

Blocked pending the magika patch. Not being worked until ort leaves the tree — retrying the base move before then just re-buys the same aarch64 cross-link failure at ~2h per attempt.