The v0.2.20 release failed at the RPM step. rpm --addrequires does not
exist in the rpm that Ubuntu 24.04 ships, so the attempt to add the
missing libva requirement back to the package aborted the job.
The RPM is now built with rpmbuild from a generated spec instead of
through alien, which gives exact control over the requirements. They are
derived from the dynamic section of the binary that was actually built,
so the package always describes its own linkage rather than a hand
maintained list, and libva is added explicitly because the FFmpeg VAAPI
device opens it at runtime. The step fails if either the libva or the
FFmpeg requirement is missing from the finished package.
alien is no longer used and has been dropped from the runner packages.
Two defects found by inspecting the published v0.2.19 artifacts.
The AppImage contained the binary and the desktop file and nothing else.
The binary links FFmpeg, PipeWire, ALSA and XCB directly, so the image
only ran on a host that happened to carry the exact FFmpeg build the
binary was linked against, which is the opposite of what an AppImage is
for. The packaging step now bundles the shared library closure that ldd
resolves, points the binary at it with an RPATH of $ORIGIN/../lib, and
prepends it to LD_LIBRARY_PATH in AppRun. The C runtime is deliberately
left on the host, because bundling a different glibc than the rest of
the system expects produces failures that are very hard to trace. The
step fails if fewer than five libraries were collected or if the image
was not produced, so a silently empty image can never ship.
alien drops libva2 when it converts the Debian package to an RPM,
because it has no Debian to RPM name rule for it. libva is loaded at
runtime by the FFmpeg VAAPI device, so the requirement is now added back
explicitly with rpm --addrequires and the build fails if it is missing
from the finished package. Without it an RPM install would leave
hardware encoding unavailable until the user noticed and installed libva
by hand.
Version bumped to 0.2.20 across the manifest, lock file, RPM spec, AUR
PKGBUILD and the guide.
v0.2.18 was already published to Forgejo on 2026-10-11, carrying the
pre-fix binary, so this cycle cuts a new version rather than moving the
published tag.
The version is bumped in Cargo.toml, Cargo.lock, the RPM spec, the AUR
PKGBUILD and the project guide so they stay in step. Cargo.lock matters
on its own: the CI workflow builds with --locked, which fails outright
when the manifest and the lock file disagree on the package version.
The Debian package declared libgtk-3-0 and libgtk-layer-shell0, which
belonged to the retired GTK backend, and omitted FFmpeg entirely. The
binary links libavcodec, libavformat, libavutil, libswresample and
libswscale directly, so a clean machine would have installed the package
and then failed to start it. The dependency list is now taken from the
dynamic section of the actual build output: libavcodec60,
libavformat60, libavutil58, libswresample4, libswscale7,
libpipewire-0.3-0, libxcb1, libasound2 and libva2.
XCB needs no extra package. The xcb crate marshals the SHM protocol in
Rust, so only libxcb.so.1 is linked and there is no libxcb-shm.so.0
load at runtime.
The RPM spec still said version 0.1.0 and required gtk3 and
gtk-layer-shell. It now tracks the Cargo.toml version, drops the GTK
packages, and adds the VAAPI, ALSA and XCB requirements it actually
needs.
The AUR PKGBUILD installed target/release/scythe-daemon and
target/release/scythe-ui, which no longer exist as build targets, so
any AUR build would have failed at the install step. It now installs the
single unified binary and points the compatibility names at it.
MSYS2 no longer installs gtk3 for the Windows build.
origin now resolves to https://github.com/oiupoyt/scythe.git, using the
oiupoyt credential that is authenticated in the store. The spearzificial
repository stays as a mirror, and the topology table records both along
with the reason the two histories needed a merge: the LICENSE files were
authored independently on each side with byte-identical content, so the
branches had diverged by one commit.
The README pointed at the spearzificial repository for its badge, release
links and clone URL, and still listed GTK 3 and GTK Layer Shell as build
prerequisites even though the GTK backend was retired and no GTK crate
remains in the manifest. It also asked for Rust 1.80 while the crate uses
the 2024 edition, which needs 1.85.
Adds section 4d covering the missing build gate, the Windows feature gap
that broke the Windows target, the unknown-argument hang, the
hardware-dependent audio test, and the Windows autostart no-op. Also
points the verification section at the GitHub Actions workflows.
The Repository Topology table still listed the old oiupoyt GitHub remote
as origin and named a separate spearzificial remote. origin now points at
spearzificial, so the table and both Dual-Push Rule blocks are updated to
the origin/forgejo pair.
Documents the two GitHub Actions workflows: ci.yml compiles and tests
both targets on every push, release.yml packages and publishes on a v*
tag. Records that the fmt check is advisory and that hardware-dependent
tests are opt-in via SCYTHE_HW_TESTS=1.
apply_autostart_system only has a Linux body, so its two parameters were
unused on Windows and the Windows build warned. Marked the parameters as
intentionally unused off Linux and documented the real gap behind it:
Windows has no registry Run key write in either the overlay toggle or
the NSIS installer, so the autostart switch currently does nothing on
Windows.
config.rs reads AC line status through GetSystemPowerStatus, but the
windows crate feature list never enabled Win32_System_Power, so the
Windows target failed to compile with E0432 on that import.
The Windows build has been broken this whole time and nothing caught it:
GitHub Actions only ran on tag pushes, and the local machine is Linux.
The new CI workflow builds both targets on every push, which surfaced it
on the first run.
Verified by checking the crate's windows:: import paths against the
x86_64-pc-windows-gnu target directly.
GitHub Actions built only on tag pushes, so nothing verified that main
compiles. Adds ci.yml running check, unit tests, clippy and a release
build on Linux, plus a Windows MSYS2 build, with both binaries uploaded
as artifacts.
Two issues would have made that workflow hang or fail:
- Unknown CLI arguments fell through the dispatch match into the global
hotkey loop, so `scythe --version` (a typo, or any unrecognised flag)
silently became a background hotkey daemon that never exited. Unknown
arguments now report the flag and exit 2.
- test_audio_probe asserts that a system audio device opens and emits
samples. Headless runners have no audio server, so the suite could
never pass in CI. The test is now opt-in via SCYTHE_HW_TESTS=1 and
still runs on a real desktop session.
Multicall dispatch used std::env::current_exe(), which reads /proc/self/exe
and resolves symlinks. Every installed alias therefore reported the stem
"scythe", so scythe-daemon and vrec-daemon fell through to client mode and
opened the HUD instead of starting the engine. The aliases shipped by
install.sh, the deb/rpm/flatpak packages and the Hyprland exec_cmd line were
all affected; a stale pre-consolidation target/release/scythe-daemon masked
it during local testing.
invoked_stem() now reads argv[0] and only falls back to current_exe() when
argv[0] has no usable stem. Verified against a packaged tarball: both daemon
aliases hit the running-instance guard while scythe, scythe-ui, vrec and
vrec-ui open the client.
The e2e guard also probed liveness with `scythe --status`, which calls
ensure_daemon_running() and so spawned a daemon while probing, then chased
its own tail. It now connects to the socket directly, records the running
daemon's command line and working directory, stops it gracefully, and
restores it on exit so a developer's recorder survives a test run.
Help text now reports the unified binary and marks --gtk as a deprecated
alias, since the GTK backend was retired.
- PROJECT_GUIDE: repository table with forgejo as source of truth and
spearzificial as the active GitHub account; explains that the oiupoyt
GitHub token is expired and why the username is pinned in the remote URL
so Git picks the right credential from the multi-account store
- PROJECT_GUIDE: document ShowOverlay and the retired-config table with the
reason each key existed without effect
- README: point releases, clone URL and CLI examples at the unified binary
and the spearzificial repository
- TODO_CHECKLIST: add the release pipeline, dead config, ShowOverlay and
e2e socket entries; note that pre-v0.2.18 src/bin paths are historical
ShowOverlay was declared in the Command enum but the daemon dispatcher had
no arm for it, so it fell through to `_ => {}`. Nothing could open the HUD
once it was closed except the --menu toggle path.
- daemon: spawn_overlay_once() checks the overlay pid file for a live
process and launches `scythe --menu` only when none is running, so
repeated requests cannot stack overlays
- cli: `scythe --show-overlay` sends the command, falling back to a direct
launch when the daemon is unreachable
Fourteen config keys were persisted and shown in the settings UI while no
capture, encoder, muxer or daemon path ever read them. Removed from
ScytheConfig, from the overlay state, and from their UI panels:
capture_source, replay_storage, change_resolution, resolution_w/h,
container_format, show_scroll_lock_led, autostart_on_game,
save_folder_by_game, name_by_game, language, ui_color_theme, record_enabled.
Unknown JSON keys are ignored by serde, so existing configs still load.
The e2e script also unlinked a live daemon's socket: it ran rm -f on the
socket path unconditionally and only stopped the systemd unit, so a daemon
started by execs.lua or by hand kept its flock while losing its path entry,
leaving the session broken until the process died. It now sends StopDaemon,
waits for the socket to disappear, and aborts without unlinking if the
daemon will not stop.
The multicall consolidation removed the scythe-daemon and scythe-ui crate
targets, but every packaging path still copied them, so a tag push failed
at the first packaging step and no release could be produced.
- release.yml: tarball, .deb and AppImage ship scythe plus daemon/ui/vrec
symlinks; AppRun execs scythe; Windows bundle copies scythe.exe only
- gitlab-ci.yml: artifacts publish target/release/scythe; Windows job
builds --bin scythe
- rpm spec and flatpak manifest install one binary and link the aliases
- NSIS installers target scythe.exe for shortcuts, finish page,
DisplayIcon and forwarded args, keeping legacy taskkill lines so old
installs shut down cleanly
Also make the gitlab fmt job advisory: it reported drift across 20 files
and build-linux hard-depended on it, blocking every build. A whole-tree
reformat belongs in its own commit.
