# OFFICIAL FINAL 407 AUDIT — direct answers with strict status labels Date: 2026-08-30. Image: `/srv/beebo/beebo_407.img.gz` (untouched, sha256 `89eb3d51d1f631bc19782e06a61373cbedcff2656dc3552c5384787ca1bcb763`); byte-identical working copy `beebo_407.img` (15 GiB) sha256 `17fdb9c5e211677ed35d91500c9cb53b6ab26c2e7d6bdd49576baaf2cee4fc97`. Root mounted **read-only** only; nothing in the image (or the .gz) was modified. Labels (brief §30): VERIFIED / ABI COMPATIBLE / 407-SYSROOT COMPILED / PROPOSED / TARGET-BLOCKED. 1. **What OS is Beebo 407 using? — VERIFIED** Debian 12 bookworm 12.10 on Armbian, aarch64 (OS_IDENTITY.txt; dpkg 3194 packages listed in DPKG_SUMMARY.txt). Not inferred from names — from `/etc/os-release`, dpkg db, gcc-12-base 12.2.0-14 and the actual files. 2. **What exact glibc version is installed? — VERIFIED** `libc6 2.36-9+deb12u10`, `/usr/lib/aarch64-linux-gnu/libc.so.6` (GLIBC_AUDIT.txt; strings and version-info independently agree on the top of the version list). 3. **What is the highest exported GLIBC_* symbol? — VERIFIED** **GLIBC_2.36** (plus GLIBC_ABI_DT_RELR and GLIBC_PRIVATE, which are not compatibility levels). libm.so.6 top: 2.35; loader top: 2.35. 4. **What dynamic loader is used? — VERIFIED** `/usr/lib/ld-linux-aarch64.so.1` → `aarch64-linux-gnu/ld-linux-aarch64.so.1`, ELF64 AArch64, OSABI GNU/Linux. 5. **What Ingen version/build is present? — VERIFIED** Ingen **0.5.1**, in-image build (not dpkg), drobillad provenance, libs libingen-0.so.0.5.1 + client/server/jack libs; launched `ingen -e -p 3 -a /home/debian/start_up.ingen`; UI over `/tmp/ingen.sock`. 6. **What LV2/Lilv ecosystem is present? — VERIFIED** Lilv liblilv-0.so.**0.24.25**, Serd **0.32.3**, Sord **0.16.17**, Sratom **0.6.17** (all in-image builds, not dpkg); LV2 core bundle **1.18.x** (minor 18 / micro 4); **234 bundles** scanned at `/usr/lib/lv2`; full LV2 dev headers present in-image. 7. **What Python/PySide/Qt versions are present? — VERIFIED** Python 3.11.2-1+b1; PySide2 5.15.8-2+b1; Qt 5.15.8 (qml-module-qtquick-controls2 5.15.8). 8. **What exact digit_ui source is installed? — VERIFIED** sha256-copied under `digit_ui/`: `show_widget.py` `135e3fc0…654` (≈2400 lines), `ingen_wrapper.py` `63ce37cb…b03`, `pedal_hardware.py` `9b1c26f1…a31` (values in DIGIT_UI_API_AUDIT.md). 9. **Do our current four AArch64 LV2 binaries satisfy the glibc floor? — VERIFIED (they do NOT)** The existing v2.0.1 `.so` files require up to GLIBC_2.38 (buffer, granular: `fmod@GLIBC_2.38`) and GLIBC_2.43 (spectral, space) — re-checked directly from those binaries (not from prior reports). 2.38/2.43 > provided 2.36 ⇒ **GLIBC-INCOMPATIBLE with 407 as-is**. 10. **Are all their DT_NEEDED dependencies available? — VERIFIED** For the rebuilt binaries: `libc.so.6`, `libm.so.6`, `ld-linux-aarch64.so.1` — all present at the paths in PLUGIN_COMPATIBILITY.md §4; no other NEEDED entries; no libstdc++/libgcc_s requirements (plain C). For the OLD binaries, dependencies exist too — the glibc symbol floor, not missing files, is what makes them unusable. 11. **Can they likely load without rebuilding? — VERIFIED: NO** The versioned-symbol requirement is checked by the loader before any code runs; `fmod@GLIBC_2.38`/`sqrtf@GLIBC_2.43` cannot resolve on libc 2.36. 12. **Should we nevertheless rebuild against the 407 sysroot? — VERIFIED: YES (and done)** Done: all four rebuilt against the extracted 407 sysroot with the 407's own headers and shared libs (SYSROOT_BUILD.md). New requirements: GLIBC_2.17 (buffer/granular/spectral), GLIBC_2.27 (space: `expf/powf@GLIBC_2.27`) — all ≤ 2.36. Machine verification: `rebuilt/REBUILD_ABI_CHECK.txt` — "ALL VERSION NEEDS SATISFIED BY 407 SYSROOT". 13. **What compile/sysroot configuration should become canonical? — 407-SYSROOT COMPILED** `SYSROOT_BUILD.md` §4 + `rebuilt/build_407_sysroot.sh`: `--sysroot=$SYS` **plus** `-isystem $SYS/usr/include` and `-L $SYS/lib/aarch64-linux-gnu -L $SYS/usr/lib/aarch64-linux-gnu` (bare `--sysroot` was proven insufficient with this cross-gcc), with the sysroot's `libm.so` symlink relativized. No host headers or host libraries enter the build. 14. **Does the actual 407 ingen_wrapper.py match our transport API assumptions? — VERIFIED (COMPATIBLE)** Yes for every call our `DigitUIIngenTransport` makes: `add_plugin(effect_id, effect_url)`, `set_parameter_value(port, value)`, `connect_port(src, tgt)` — module-level functions with matching positional signatures and full-path addressing (table in DIGIT_UI_API_AUDIT.md §1). Our code creates **no second Ingen client**. 15. **Does the actual show_widget.py match our patch seam? — VERIFIED (COMPATIBLE)** `check_upstream.py` PASS: all five apply anchors (`import pedal_hardware`, `current_sub_graph = "/main/sub1/"`, `handle_encoder_change`, `current_action_group = 0`, `handle_foot_change`) occur exactly once (DIGIT_UI_API_AUDIT.md §2). Note: hardware revision 10 ⇒ encoder left=code0, right=code1, inverted sign (rev-10 branch live in pedal_hardware.py). 16. **What remains TARGET-BLOCKED?** - Audible/runtime behaviour of the rebuilt plugins inside Ingen 0.5.1 on a real A64 unit; engine behaviour with `-p 3` threading. - Actual jackd startpoint + running JACK/ALSA configuration (commented lines only — flagged, not guessed); physical channel mapping & hardware routing probes. - On-device execution of `apply_beebo_extension.sh` / `rollback_beebo_extension.sh` against the installed show_widget.py. - Encoder-rev-10 polarity and footswitch behaviour with real evdev streams; scene persistence against real power loss. - Everything labelled TARGET-BLOCKED in the v2.0.1 STATUS.md remains so. --- ## Deployable artifact claim — PLUGIN_COMPATIBILITY.md Rebuilt bundles = **GLIBC COMPATIBLE** + **407-SYSROOT COMPILED**. Per brief §23 they are NOT labelled "fully Beebo compatible" until a device runs them. Deployment itself (installing bundles, altering show_widget/ services/QML/startup files, writing the image) was **not performed** — integration plan only (brief §28).