Add a Debian 12 baseline for portable Linux Classic builds

[zoeyrose]

Summary

Provide a reproducible Linux/amd64 Classic portable-build target with a Debian 12 / glibc 2.36 application ABI baseline for atrinik/atrinik#562 and its sole wrapper integration owner atrinik/atrinik#574. Keep the existing authoritative Linux coordinator image and Windows/MXE toolchains intact.

The parent requires a movable user-local client with its application dependencies and real media, without installing host application packages. The current linux-build:1.10.0 image is Ubuntu 26.04; its installed SDL3 requires GLIBC_2.43 from libm. Copying that dependency closure cannot qualify exports for the older Ubuntu/Debian systems proposed by #574. Debian 12 is the selected build baseline for the proposed Ubuntu 24.04/26.04 and Debian 12/13 matrix, not a claim that those systems are already qualified.

Implementation / behavior

• Add a separate digest/snapshot-pinned portable Classic build target or equivalent sealed build sysroot, owned here. Use an explicit Linux/amd64 and baseline contract; do not repurpose the canonical coordinator or activate new delivery authority.
• Build the required modern Classic application dependencies against the baseline. Honor current physical-owner requirements, including SDL3 >= 3.4, SDL3_image/SDL3_ttf >= 3.2 and SDL3_mixer >= 3.2.4. Pin downloaded inputs and verify checksums/source identity; merely changing the distro base or rebuilding SDL alone is insufficient.
• Provide complete application library, codec and dynamic-plugin inputs needed by the Classic client. Record redistribution notices and applicable source/relinking obligations. Keep host graphics drivers external. Prove actual dependency/provider symbol compatibility and compiler CPU targeting; do not rely only on a maximum-glibc-version string.
• Expose machine-readable target, tool/dependency and runtime/ABI metadata so the wrapper can select and verify the eventual immutable artifact. Keep mutable caches, workspace/user state, credentials and authored assets out of the image.
• Add explicit portable-target selection, Dockerfile checks, build and non-root smoke/consumer validation to the automatic pull-request workflow and its required aggregate. Adding a stage without CI selection is insufficient. Use hosted CI's nonpublishing cacheonly/load route; pull-request code must receive no registry credentials or package-write permission.
• Add coherent, reviewed release/publication wiring and documentation for the new target, preserving the existing image contracts, immutable actions, least-privilege permissions and supported recovery rules. Actual merge, semantic release, registry publication or manual candidate dispatch remains a separate approval gate. A candidate_only registry push is still publication.
• Keep supply-chain catalog/audit reports optional diagnostics. Actual immutable-input, provenance, license and payload-verification obligations remain mandatory.

Validation

• Build and smoke the affected target at the exact final PR head, as a non-root user, through automatic nonpublishing PR CI. Validate all newly selected jobs and required aggregate, Dockerfile checks, applicable ShellCheck/actionlint and owner tests.
• Build real Classic client consumers from the current actually merged Classic source (initial reference 8b920dffa0f5c161e9310b334df1cf48fbf15a36) without GPU/display/audio access. Verify compile/source version identity and actual ELF dependency/symbol closure against the declared baseline; reject leakage from newer coordinator libraries and accidental newer CPU targets.
• Exercise representative application-library/codec/plugin loading in an isolated baseline runtime. Keep source-built tools, final runtime dependencies and licenses traceable to verified immutable inputs.
• Review the complete final diff independently and resolve actionable findings. Preserve existing Linux/Classic and Windows/MXE required checks and behavior; do not narrow acceptance or bypass checks to make a new target pass.
• After an explicitly authorized maintainer merge and publication, record successful producer run/source coordinates and the immutable published manifest digest. #574 consumes only the actual published result and reruns affected integration.

Ownership / limitations

This issue owns only reusable image/sysroot inputs, metadata, image smoke/consumer checks, CI/publication wiring and associated documentation in atrinik/devcontainer. Wrapper export orchestration, platform/context authority and final native runtime qualification remain with atrinik/atrinik#574. Do not duplicate #563–#566 implementations or modify their active worktrees.

content@main, resources and sound are read-only dependency inputs for the Classic client artifact; this issue grants no authored-content or asset changes. No live services, host builds outside the supported coordinator contract, Docker-daemon remounts, credential copies, force-pushes, destructive cleanup, VS Code control, unrelated policy changes or later Windows/usability/scaling wave.

Final portable-folder relocation across all documented distributions, separate-server connectivity/persistence, actual hardware gameplay and audible playback remain parent integration evidence. Container loader checks and decoding do not satisfy hardware acceptance. This image delivery must not close parent #562.

Parent: atrinik/atrinik#562
Integration owner: atrinik/atrinik#574

Parent: atrinik/atrinik#562

[github-actions]

🎉 This issue has been resolved in version 1.11.0 🎉

The release is available on:

• v1.11.0
• GitHub release

Your semantic-release bot 📦🚀