fix(release): stop dist building the plugin during the standalone release build

[OpenSauce]

The v0.3.0 tag build failed on both Linux targets. No release was published — host never ran, so nothing shipped and 0.2.0 is still latest on the releases page.

Root cause

thread 'main' panicked at x11-2.21.0/build.rs:42:14:
pkg-config exited with status code 1
  > pkg-config --libs --cflags x11-xcb 'x11-xcb >= 1.6'
  No package 'x11-xcb' found

dist logs its invocation as:

building x86_64-unknown-linux-gnu target, using cargo profile dist --workspace)

cargo build --workspace compiles every workspace member, including rustortion-plugin → iced_baseview → baseview → the x11 crate, whose build script hard-requires x11-xcb headers. That plugin build is pure waste in this job: its output is discarded, and plugin-release.yml builds the real CLAP/VST3 bundles on release: published.

Why it was never caught. v0.2.0 predates the plugin crate (#224), so v0.3.0 was the first tag with the plugin in the workspace. Nothing on the PR path exercises the dist build — ci.yaml installs a full X11 set and goes green, while release.yml derives its packages from dist-workspace.toml. The two diverged silently, and the difference only surfaces after a tag is pushed.

Fix

precise-builds = true narrows the build to the packages that actually produce release artifacts.

dist already knew what to ship — rustortion-standalone is the only package with a [[bin]], xtask is dist = false, and core/ui/plugin are libraries. The bug was only in what it compiled to get there.

The standalone reaches X11 through x11-dl, which dlopens at runtime and needs nothing at build time, so the original four apt packages were correct all along. An earlier revision of this PR added the plugin's ~20 X11 dev packages to the dist apt list; that treated the symptom and is reverted.

Verified with dist plan (local dist is 0.30.2, same as CI): identical artifacts, apt list back to four packages. No release.yml regeneration needed — it reads the matrix from the plan job at runtime.

Also here

Both READMEs told users to download rustortion-<target>.tar.xz. dist names the archive after the package, which became rustortion-standalone, so v0.3.0 ships rustortion-standalone-<target>.tar.xz. The binary inside is still rustortion. This has been wrong since the crate split — it predates this branch and is unrelated to the build failure.

Verification

pr-run-mode = "upload" is set temporarily so this PR runs build-local-artifacts on the real runners instead of skipping it. Once both targets are green I'll drop that line and merge, so the thing that failed at tag time is proven before the tag moves.

Then: delete and re-tag v0.3.0 on the fixed commit, regenerating the changelog after the tag is removed so this fix lands in the 0.3.0 section rather than leaking into 0.4.0's.

[Copilot]

Pull request overview

Aligns cargo-dist’s release runner system dependencies with the workspace’s current build requirements (notably the plugin GUI’s X11/XCB headers) so tagged releases can build successfully on both Linux targets.

Changes:

• Expand [dist.dependencies.apt] in dist-workspace.toml to include the X11/XCB development packages needed by the plugin dependency chain.
• Add in-file documentation explaining why the dist apt list must be kept in sync with CI’s apt list.
• Temporarily set pr-run-mode = "upload" to force PR execution of dist artifact builds (called out as temporary in-file).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.