Build-at-install fallback for evsieve is broken: Debian 12's packaged rustc (1.63) can't compile the pinned source

[aradanmn]

Found during #126d (Deck-validating the prebuilt-fetch and forced-fallback paths for v1.2.4)

Path A (prebuilt fetch, the common case) is fully validated and working —
confirmed against the real v1.2.4 release: install_evsieve() fetched
evsieve-x86_64-linux + .sha256 + .stamp from
releases/latest/download, verified the pin/checksum, ran
_evsieve_host_verify, and installed. EVSIEVE_INSTALL_STATUS=installed-prebuilt,
binary reports 1.4.0. No issue there.

Path B (build-at-install, the fallback) does not currently work at all —
on a genuinely fresh mcss-evsieve-build distrobox (purged and recreated
from a freshly-pulled debian:12 image, to rule out stale-container state):

rustc 1.63.0
cargo 1.65.0

cargo build --release on the pinned evsieve source
(ebd7efe1ee902e70c5943b65a2bf44b9a3c31eb8) fails with >100 errors, e.g.:

error: extern block cannot be declared unsafe
   --> src/bindings/libevdev.rs:121:1
    |
121 | unsafe extern "C" {
    | ^^^^^^
...
error[E0433]: failed to resolve: could not find `offset_of` in `mem`
  --> src/bindings/libevdev.rs:80:56
...
error[E0658]: `let...else` statements are unstable
  --> src/arguments/capability.rs:72:17
...
error[E0658]: use of unstable library feature 'int_roundings'
  --> src/arguments/oscillate.rs:54:40

src/bindings/libevdev.rs is checked into the pinned commit itself
(confirmed via git show <pin>:src/bindings/libevdev.rs — it's a
pre-generated file via evsieve's own generate_bindings.sh, not something
our build.rs invocation regenerates), and it already uses unsafe extern "C" { } blocks. That syntax needs a materially newer rustc than Debian
12 bookworm ships via apt. let...else and int_roundings::div_ceil are
also gated on a newer edition/toolchain than 1.63.

This means the fallback has been broken since it was written (#38 D4,
2026-07-19) — EVSIEVE_PINNED_COMMIT has never changed, so this isn't a
regression from today's #126 work. It went unnoticed because
_evsieve_build_in_box redirects the whole cargo build invocation to
/dev/null 2>&1 (only the wrapping print_progress lines are visible), so
a real failure here has never been distinguishable from success in any
install log without redirecting stderr manually, as done here.

Why this doesn't block v1.2.4

With #126 shipped, install_evsieve() tries the prebuilt release asset
FIRST and only reaches this path if that fails (network outage, checksum
mismatch, or a future pin drift). Every real install today uses Path A.
The degrade behavior when Path B also fails is correct and fail-open
exactly as designed: EVSIEVE_INSTALL_STATUS=degraded-build-failed, a
clear print_warning, no partial/corrupt binary, and the rest of the
install (Minecraft, Steam integration) continues unaffected. Confirmed
this on hardware too — nothing broke downstream of the failed build.

What needs fixing

The build-at-install path needs a toolchain that can actually compile the
pin — options:

1. Install Rust via rustup inside the box (a specific stable channel)
   instead of apt-get install cargo, matching what release.yml's CI job
   already does via dtolnay/rust-toolchain@stable. Costs an extra
   download during the (already slow, multi-minute) fallback path, but
   that path is meant to be a last resort now, not the common case.
2. Alternative: vendor/pin an older evsieve commit whose checked-in
   bindings predate the modern syntax — rejected on sight, since it would
   mean shipping two different actual evsieve versions between the prebuilt
   and fallback paths (PRINCIPLES feat: Add Microsoft account OAuth setup during installation #9, one encoding).

(1) is the obvious fix. Not fixing tonight — filing for backlog since it's
real but non-blocking.

Repro

On the Deck, with the box removed (distrobox rm -f mcss-evsieve-build,
or after uninstall-minecraft-splitscreen.sh --purge):

distrobox enter --name mcss-evsieve-build -- sh -c 'cd <pinned evsieve checkout> && cargo build --release'

Related

#126 (prebuilt binary — masks this for all real installs), #38 D4 (original
build-at-install design), #124 (the sudo/TTY hang in this same box, already
fixed).

[aradanmn]

Correcting a claim in the issue body: this was NOT necessarily broken since 2026-07-19

Scott pointed out we had a genuinely successful build-at-install run of
evsieve earlier TODAY (2026-08-01), around 08:30am — visible in
`.workdir/validation-install.log` (`✅ evsieve built and installed:
.../bin/evsieve`, right next to a Steam-shortcuts backup file timestamped
`08:33:55`). That directly contradicts "broken since it was written" — it
was demonstrably working on this same Deck, same pin, earlier the same day.

What I can pin down precisely:

• The box I found already running when I started this afternoon's test
  reported "Up 3 hours" — i.e., created somewhere around 10-11am, well
  AFTER the 8:30am success.
• That box's rustc was 1.63.0 and failed to compile the pin.
• I then fully purged (removed the container + its debian:12 image) and let
  the installer create a brand-new box from a freshly-pulled image — same
  result: rustc 1.63.0, same 100+ compile errors.

So there were at least two distinct box lifetimes today: one before ~10am
that worked, and at least one after that didn't — with the exact same pinned
commit both times. I don't have forensic access to the 8:30am box anymore
(it's gone) to compare its rustc version directly, so I can't say for
certain why it changed. The most plausible mechanism: `docker.io/library/debian:12`
is a floating tag, not a pinned digest — if Docker Hub cut a new bookworm
point-release image between those two pulls and that rebuild picked up a
different `rustc`/`cargo` package resolution, two pulls on the same day
could genuinely disagree. I can't confirm that's what happened, only that
it's consistent with what I observed and is the least exotic explanation
available (Debian stable doesn't normally bump toolchain major versions
mid-release, which is itself evidence this is more likely an artifact of
image-tag churn than a deliberate Debian change).

Either way, the fix in the issue body stands regardless of root cause:
pinning an explicit Rust toolchain (rustup, a specific channel) instead of
depending on whatever `apt-get install cargo` resolves to at build time
removes this class of flakiness entirely — the fallback path becomes
reproducible independent of which debian:12 snapshot got pulled that day.