mirror of
https://github.com/gufo-org/toolboxes.git
synced 2026-11-07 10:46:07 -10:00
* packaging: host (.deb) lane, lite scope -- binary, runtime data, licenses
Builds the gufo .deb from whatever the engine repository currently holds, and
packages the executable, the runtime data the executable is compiled to look for,
the licenses, and one line of linker configuration. No systemd unit, no launcher, no
configuration file, no user, no port: services, environment-based configuration, model
and cache management, deployment helpers and custom upgrade handling are deployment
choices and stay follow-up changes.
Nothing here names a release, so cutting one costs no commit in this directory. The
ref defaults to the newest tag, the version comes from the checkout's version.txt
through gen-deb-ver, and debian/changelog is generated in the scratch tree at build
time and tracked nowhere. Proven: gen-deb-ver on a synthetic 9.9.9 checkout prints
9.9.9+git<sha>-1, and build-deb --dry-run resolves the current newest tag live.
debian/changelog carries the minimal metadata a Debian changelog has to have -- the
version, and a pointer to the release. It copies no prose from Gufo's CHANGELOG.md:
that file and the release page are the history, and a second copy in the packaging
repository is the copy that goes stale and the copy that disagrees with the tag it
claims to describe. rules generates the entry when it is absent and verifies it when
present, and exits non-zero on drift, naming both versions.
Three things a change like this quietly gets wrong, all three tested:
- runtime libraries. The binary links ROCm by soname and carries no RUNPATH, so
/etc/ld.so.conf.d/rocm.conf ships and debian/triggers activates libc-bin's
ldconfig trigger instead of a maintainer script. Proven against its negative
control on pristine debian:trixie: without the trigger the cache is not refreshed
and the library is not indexed; with it, dpkg processes the trigger, the cache
refreshes and the library resolves. The package therefore has no maintainer script
at all.
- declared dependencies. ${shlibs:Depends} is a property of the machine that runs
the query, not of the package: the same grep over /var/lib/dpkg/info/*.shlibs
returns one file on one host and several in a container built against AMD's
repository. A dependency that depends on which machine built the package is not a
dependency, so the ROCm runtime floors are written by hand, and ffmpeg is declared
because the binary execs it rather than links it. debian/tests/smoke.sh audits
NEEDED against Depends and names the libraries a given testbed cannot judge.
- build dependencies, which are a separate list and move with the engine. Since the
engine made sndfile and soxr REQUIRED in CMakeLists, configure aborts without
libsndfile1-dev and libsoxr-dev, so both are in Build-Depends and in the builder
image. "Lite" is lite about what the package INSTALLS; it does not make the engine
cheaper to COMPILE, and a lane that tracks only the install scope fails at
configure the first time upstream adds a dependency. dpkg-checkbuilddeps is the
cheap check, and it belongs before the build.
deb/build-deb computes -j from MemAvailable with a reserved margin and refuses to
start when there is no safe value; --in-container adds a memory ceiling so an
out-of-memory decision stays inside the container's cgroup. deb/tests/lite-scope.sh
gates the scope and injects each forbidden shape into a copy to require that it fails,
because a gate nobody has watched fail is decoration -- and one of its own checks had
in fact been green while blind: it resolved the lane root as `deb/tests/..`, so its
own `grep -v /tests/` exclusion discarded every path in the lane and the
release-literal check inspected nothing. The path is absolute now, and that check
carries a permanent negative control that writes a fake release number into the lane
and requires the same grep to find it.
* packaging: trim Debian lane for reusable release workflow
* packaging: build and publish trimmed Debian releases with ROCm 10.1
* ci(release): allow Debian-only builds and explicit asset replacement
---------
Co-authored-by: Federico Izzo <[email protected]>