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.
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.
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.
