8.5 KiB
Linux packaging and deployment inputs
The packaging command stages already-built desktop/server executables for x86_64-unknown-linux-gnu. It runs on Windows PowerShell 5.1 or PowerShell 7 (including Linux) with Python 3.11+ standard library, Git, and the matching Rust/Cargo dependency cache. It does not build, download, install runtime libraries or launch the application. Python creates and reads back the tar archive; end users do not need Python, PowerShell or Rust.
Build and validate first in a source checkout. The current runtime validation baseline is Ubuntu 24.04 x86-64. A glibc symbol inventory is not a claim that every distribution with that glibc version supports the renderer and dialogs.
./scripts/package-linux.ps1 -Target x86_64-unknown-linux-gnu `
-Version 0.2.0-rc1 -BinaryDirectory ./target/release -Python python3
For an explicit-target build, use target/x86_64-unknown-linux-gnu/release. A cross-build may supply another directory containing both arcadia-studio and arcadia-server. Select the Rust compiler used for the intended build before packaging; its Linux target libraries, copyright reports and locked source/archive cache must be installed. Read-only cargo metadata --locked --offline --filter-platform x86_64-unknown-linux-gnu and Rust version/sysroot queries are the only Rust commands run by packaging. When packaging from Windows, -Python C:/path/to/python.exe selects Python explicitly.
The script refuses existing output/claim names. It creates dist/ArcadiaStudio-<version>-x86_64-unknown-linux-gnu/, a .tar.gz, and an adjacent .sha256. A failed attempt leaves its claim and any partial outputs for diagnosis; choose a fresh version or output root rather than overwriting them. Archives use sorted paths, zero timestamps and uid/gid, 0755 for the two Linux executables and 0644 for other files. Every entry is read back and compared against staging, including permissions. The same unchanged inputs on the same Python/zlib implementation produce the same bytes; this does not promise reproducible compiler output.
Contents and provenance
Both executables, the MIT license, a package-specific README, complete tracked examples (including all water-pressure teaching/evidence files), deployment references and the reachable documentation closure are included. Relative Markdown/reST/HTML file links are checked before archiving; upstream license texts are preserved verbatim and their internal source-tree hyperlinks are outside that documentation check. Untracked private files, caches and unrelated harness history are not included merely because they exist on disk.
package.json records input hashes and static ELF dependencies. SHA256SUMS.txt inventories every file except itself; the archive checksum covers that inventory too. dependency-notices.json, THIRD-PARTY-NOTICES.txt and licenses/ use the same strict collector as Windows: exact target-filtered normal/build dependency graph, locked crate archives, actual source hashes, checksum-bound supplements and embedded fonts, Rust distribution notices and target-library hashes. Unknown sources, absent notices or changed supplements stop packaging. No Linux system libraries are bundled by this pipeline; their runtime distribution supplies them and its notices.
ELF preflight requires little-endian x86-64 executables/PIE, the glibc dynamic loader, no RPATH/RUNPATH and a reviewed set of direct libc/compiler-runtime imports. Unknown libraries require an explicit packaging design instead of being silently copied from a developer machine. Graphics/window/portal libraries loaded at runtime are outside that static import list.
Optionally pass -BuildEvidence <json-file>, containing nonempty source_identity, profile, compiler, exact target, and binary_sha256 keyed by arcadia-studio and arcadia-server. Hash strings must be lowercase SHA256. Target and binary hashes are checked; other fields remain explicit caller assertions. Omission records build provenance as unknown. Never label a development binary an optimized release because of its directory or package version.
Native extracted-bundle checks
Extract into a fresh user-writable Linux directory and run from an unrelated working directory. Verify SHA256SUMS, file permissions, file/ldd and actual desktop/runtime libraries. A typical Ubuntu runtime needs X11/XKB and Wayland clients, Vulkan loader/Mesa Vulkan drivers, and working session DBus plus an xdg-desktop-portal backend for file dialogs. A successful ldd alone is insufficient because these libraries can be loaded dynamically.
For a software Vulkan trial, first locate the installed lavapipe ICD; only if it exists, use:
WGPU_BACKEND=vulkan VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json ./arcadia-studio
A compatible native GPU may run without these variables. WSLg uses real Linux user space with a particular display environment; record the actual X11/Wayland backend and do not infer support for all Linux sessions from one trial. Exercise Home walkthrough, Help/search, native Open/Save dialogs, a multi-file project, diagram/source edits, Undo/Redo and reopening at normal/minimum window sizes. Compare complete saved model/source and inspect stderr, not merely whether a window appeared.
Run the server against a separate local data directory and unused loopback port. Follow server configuration for health, authentication, ETags, restart and backup/restore. Test create/import, a changed conditional update, unchanged no-op, stale/invalid rejection, and persistence after a clean restart. Record exact binary/archive/source/compiler hashes and platform. Packaging verification is separate from current-tree release acceptance.
Container server notices and context
The Dockerfile is x86-64 Linux only and requires BuildKit named build contexts. Before its application build it verifies a prepared server-only notice bundle against Cargo.lock, Rust compiler release/commit, exact Linux target-library hashes, notice-file checksums and workspace source hashes. This prevents using Windows dependency notices or a stale source/compiler inventory as the container's notice claim.
In the source checkout, select Rust 1.90.0 and its x86_64-unknown-linux-gnu target libraries to match rust:1.90-bookworm. Populate the locked dependency cache through your ordinary documented build/setup first; notice collection itself remains offline. On a Windows host, a Rust 1.90 GNU-host toolchain with installed Linux target libraries can provide this read-only inventory. Prepare a fresh output root:
./scripts/package-linux.ps1 -Target x86_64-unknown-linux-gnu `
-ServerNoticesOnly -OutputRoot ./.local/container-notices-rc1
This writes .local/container-notices-rc1/server-notices and a sibling claim file. Pass only the notice directory as the named context:
docker buildx build --platform linux/amd64 --load \
--build-context server_notices=./.local/container-notices-rc1/server-notices \
-f deployment/Dockerfile -t arcadia-server:0.2.0-rc1 .
The Dockerfile-specific ignore file allows only its ordinary source/build inputs; .local, model data, .env files and arbitrary caches are excluded from that root context. The separate named context includes only the explicitly prepared notices. The image retains them at /usr/share/doc/arcadia-server/, alongside Debian's own distribution notices. Do not pass a broad cache or home directory as the named context. Updating Cargo.lock, workspace sources or the compiler requires regenerating the bundle under a fresh output name.
The image runs as UID/GID 10001 and expects its data volume and token as described in server configuration. Verify the actual image build, service health/authentication, writable volume and restart on a Docker-capable Linux runner. A Dockerfile review and successful local package checks do not establish container build/runtime acceptance.
Runner-independent validation commands
Run cargo fmt --all -- --check, cargo clippy --locked --workspace --all-targets -- -D warnings, cargo test --locked --workspace --all-targets, and cargo build --release --locked --workspace --bins with the explicit supported compiler and native prerequisites. Run python3 scripts/test-package-artifacts.py and the PowerShell notice contract checks. Then package the resulting binaries and perform the native checks above. These commands are usable on a suitably provisioned runner; this document does not assert that GitLab, Gitea or GitHub has an active runner for this repository.