a sl0p.foo repository https://git.sl0p.foo/sl0ppi.git/atom/packaging/stage.sh?h=main 2026-08-12T21:51:34Z 2026-08-12T21:51:34Z user user@clank 2026-08-12T21:51:34Z urn:sha1:8f5dc3904093c402c16eca835528f59fbb9851b3 Published 0.1.1 with the dead-session and flaky-read fixes. Also removes the `sl0ppi-cli` line from MANIFEST and the version field from cli/package.json: the CLI ships as part of the product, so a version of its own only drifts -- a 0.1.1 release shipped a MANIFEST claiming sl0ppi-cli 0.1.0. Records the terminal-level flakiness as a known issue with the measurements, so it is a tracked defect rather than folklore: list-tabs/list-panes fail ~60% of the time against a detached live session on a 2-vCPU box, ~25% with a client attached, and the action client blames "no active session" for what is really a transient enumeration failure. 2026-08-12T20:51:23Z user user@clank 2026-08-12T20:51:23Z urn:sha1:f8f035713f29676348602246036aba840468cc5f The artifact was stale twice over: it predated the protobuf fix and did not contain the CLI at all. Both fixed, and the whole chain re-verified from the tarball rather than assumed. The CLI ships as a single 31K file (`bun build --target=bun`) run by the bundled bun, rather than a source tree or a second `--compile`d binary that would embed another 90M copy of bun. `install.sh` generates the wrapper and pins SL0PPI_BIN to the sl0ppij it just installed, so the orchestrator can never end up driving some other zellij that happens to come first on PATH. Verified in a throwaway HOME with node, npm, bun, cargo, rustc and python3 all replaced by poison stubs that fail loudly if invoked: sl0ppij --version -> 0.45.0+sl0p1 (static musl, no libc dependency) pi --version -> 0.84.1 (bundled bun) sl0ppi doctor -> all good sl0ppi init x2 -> two projects scaffolded sl0ppi up -> session "dev", 2 tabs, agents suspended sl0ppi ls -> agent:suspended, 1 pane each sl0ppi up (again) -> "up to date" And the promise the whole thing exists for, end to end: attach a client, press Enter in the suspended agent pane, and pi starts on the bundled runtime -- while the other project's agent stays suspended, because only the focused pane got the key. `make test` now runs the CLI suite alongside the Rust ones, so the two halves cannot drift apart unnoticed. 2026-08-12T19:12:08Z user user@clank 2026-08-12T19:12:08Z urn:sha1:03a2a8a8cbe30d8acf76420ba5143080cbf65d9e The gnu release build required GLIBC_2.39 (Jan 2024), so the "install it on another machine" artifact would have failed on Debian 12, Ubuntu 22.04 and RHEL 9. That is the whole premise of this repo, so it is a defect, not a nit. make build -> cargo zigbuild --target x86_64-unknown-linux-musl result -> ELF, statically linked, 0 GLIBC_ symbols, 51M make build-gnu kept for fast local use A musl build needs a musl C toolchain: isahc/curl pulls libz-sys and libnghttp2-sys unconditionally (confirmed: --no-default-features does not drop them). cargo-zigbuild + the ziglang python module were already installed here, so this needs no sudo, no docker daemon and no system packages. stage.sh now refuses to be quiet about it: it reports "statically linked" or warns loudly that the artifact inherits the build box's libc. Re-verified from the tarball in a throwaway HOME with node/npm/bun/cargo replaced by poison stubs: static binary, pi 0.84.1 on the bundled bun, both wasm plugins installed, session starts under a pty with no errors. Remaining libc floor is bun's own glibc 2.17 (2012); bun publishes a musl build if Alpine ever matters. 2026-08-12T18:46:39Z user user@clank 2026-08-12T18:46:39Z urn:sha1:045ed6a48a4f65abdafe8222e548b758fb6626a0 Phase 3: `make package` now produces a tarball that provably works on a machine with no node, npm, bun or rust. Two bugs the clean-room test found, neither visible until a session actually started: - the default layout builds its status bar out of zjstatus, which we were not shipping at all (vendored as sl0pstatus/ in the preceding commits) - install.sh installed a hardcoded plugin list, so zjstatus.wasm would not have reached the config dir even once staged Also: layouts/*.kdl still pointed at ~/.config/zellij, missed by the rename pass because that pass only rewrote config.kdl. Verified end to end, from the tarball, in a throwaway HOME with node/npm/bun/ cargo shadowed by stubs that fail loudly if invoked: sl0ppij --version -> sl0ppij 0.45.0+sl0p1 pi --version -> 0.84.1 (on the bundled bun) pir --help -> ok sl0ppij -s realtest -> session starts under a pty, config "Well defined", fork pane titles render, both wasm plugins load, no errors beyond the first-run permission cache Artifact: sl0ppi-0.1.0-x86_64-linux.tar.gz, 83M, + .sha256. 2026-08-12T18:03:19Z user user@clank 2026-08-12T18:03:19Z urn:sha1:04ce010651a73a99d57e8b1c30bcc4f1346c9c52 config/config.kdl plugin path -> ~/.config/sl0ppij/plugins, builtin plugins -> the sl0ppij: URL scheme. Verified to load under the renamed binary ("[CONFIG FILE]: Well defined."). install-config.sh syncs to ~/.config/sl0ppij install.sh a stock zellij on the target is no longer a warning, it is just a fact: the two coexist stage.sh drops the "renaming at package time is a fig leaf" note Makefile builds `-p zellij` (package) and ships `sl0ppij` (binary); `make check` now also gates the root package, using the prebuilt asset plugins so it does not need debug wasm docs/ rename.md records what was done, what was deliberately left (plugin-internal strings live in prebuilt wasm), and the verification actually performed 2026-08-12T17:39:44Z user user@clank 2026-08-12T17:39:44Z urn:sha1:4b77895ba0e8498e29dffdfce61f7d2b329e3e26 Adds the layer that makes this a distributable product rather than three directories: VERSION one sl0ppi version for the whole monorepo FORKS.md what each component is based on, and how to rebase the fork Makefile build / vendor / stage / package, plus dev-box helpers packaging/ fetch pinned payloads, assemble an install tree, install it docs/ architecture, the rename plan, the roadmap The self-contained runtime question is settled and verified: pi upstream builds its own release binary with `bun build --compile`, and a vendored bun runs the vendored pi dist unmodified, so the tarball carries bun + pi and needs no system node, npm or rust on the target machine. packaging/install.sh does a per-user install under ~/.local, never clobbers an existing config (writes .new alongside, or backs up under --force-config), and warns loudly when a stock zellij is present -- because until docs/rename.md is implemented the binary is still zellij underneath and would collide with it.