Commit graph

8 commits

Author SHA1 Message Date
trvon
e389e384b1
feat(packaging): ship the daemon as a systemd user unit
The service is now user-bound: each user runs their own daemon with
their own config ($XDG_CONFIG_HOME/yams/config.toml), corpus
($XDG_DATA_HOME/yams) and socket ($XDG_RUNTIME_DIR/yams-daemon.sock),
which is exactly what the CLI already resolves. The system service, its
yams account/group, the group socket and the /etc/yams/config.toml
configuration go away.

- Unit: /usr/lib/systemd/user/yams-daemon.service runs
  `yams-daemon --foreground` with default path resolution,
  Restart=on-failure, WantedBy=default.target, and light hardening
  (NoNewPrivileges, LockPersonality, RestrictRealtime, RestrictSUIDSGID,
  native syscalls only). No ProtectHome/PrivateTmp: the daemon reads the
  files its user adds.
- Enablement: /usr/lib/systemd/user-preset/80-yams.preset plus
  `systemctl --global preset` on first install (and on upgrade from a
  release with the system unit), so the unit starts with every user's
  next session; administrators override with a user preset or
  `systemctl --global disable`, and later upgrades keep that choice.
  Package scripts never start per-user instances: they reload running
  user managers, try-restart running user daemons on upgrade and stop
  them on removal (`systemctl --user` via runuser per /run/user/<uid>),
  then `systemctl --global disable` on removal.
- Migration from 0.20.x and the system-service design: deb preinst, rpm
  %pre and Arch pre_upgrade stop and disable the old system unit while
  its file is still installed (deb also purges deb-systemd-helper
  state). /var/lib/yams, the old system corpus that the CLI never
  reached, is left alone and documented; user corpora are never
  touched.
- The sysusers entry, account creation and the deb's passwd and
  init-system-helpers dependencies are dropped; the deb purge no longer
  deletes /var/lib/yams.
- Install paths move to lib/systemd/user and lib/systemd/user-preset in
  meson, the Arch stage/PKGBUILD and the install-surface policy.
- docs/install.md: the user service, enabling it now
  (`systemctl --user enable --now`), lingering, plugins via the user's
  config, opting out, upgrade and removal behaviour, and the 0.20.3
  leftover.

Signed-off-by: trvon <me@trevon.dev>
2026-10-02 07:55:01 -06:00
trvon
e895fe2f94
build(packaging): bundle ONNX Runtime privately in <libdir>/yams/onnxruntime
No package carried ONNX Runtime: tools/yams-cli tried to install_subdir()
the runtime's libdir, but read it with get_variable('libdir') from the
dependency meson.build had already normalized into a declare_dependency,
which has no variables, so it installed nothing. Packaged ONNX and Glint
plugins therefore only worked where the user had installed a compatible
runtime themselves.

meson.build now records the directories it resolved ONNX Runtime from,
and the runtime install bundles the shared library from the first that
holds one into <libdir>/yams/onnxruntime/ (install tag runtime). A small
configure-time helper (scripts/list-onnxruntime-libs.py) lists the real
files and the soname symlinks, so the chain libonnxruntime.so ->
.so.1 -> .so.1.23.0 is recreated instead of tripled, and only the core
library and providers_shared are taken (no static archives, CMake or
pkg-config files). The plugins use this copy only when no compatible
system copy exists. Windows is unchanged: onnxruntime.dll already ships
next to the executables in the MSI and is found by the loader search.

- scripts/split-debug-symbols.sh leaves the bundled runtime
  byte-identical: it is an upstream release build, already stripped, and
  re-stripping would void a macOS code signature.
- install_surface_policy: <libdir>/yams/onnxruntime/* is allowed and
  exempt from first-party export/hardening checks; the Glint size budget
  grows to 850,000 bytes (711,352 measured with real ONNX Runtime code).
- Homebrew formulas depend on Homebrew's onnxruntime, which the plugins
  prefer, so they drop the archive's private copy (rm_rf
  lib/yams/onnxruntime).
- Arch: optdepends now reads 'onnxruntime: use the system ONNX Runtime
  instead of the bundled copy' (PKGBUILD and the CI .PKGINFO).

Measured on grim (Linux x86_64 release, --with-onnx, stripped staged
payload): 87,883,247 -> 110,236,706 bytes (+22.4 MB: the 22,207,288-byte
libonnxruntime.so.1.23.0, 14,632-byte providers_shared, and +111 KB of
real GLiNER code in yams_glint.so).

Signed-off-by: trvon <me@trevon.dev>
2026-10-01 22:42:15 -06:00
trvon
d534f090bd
build(packaging): store symlinks in zips, zstd rpm, correct Arch metadata
- macOS zips were built with `zip -r`, which follows symlinks: bin/yams
  (-> yams-cli) shipped as a second 34 MB copy and each versioned dylib
  link became another full file. `zip -ry` stores the links.
- RPMs used rpm's gzip-class default payload (37.5 MB vs 28.6 MB for the
  zstd .deb of the same tree); the spec now sets w19.zstdio (rpm >= 4.14).
  The spec's License also said Apache-2.0.
- The Arch PKGBUILD and the CI .PKGINFO generator declared Apache-2.0
  (the project is GPL-3.0-or-later) and depended on liburing, libarchive,
  taglib, sqlite, openssl, curl and boost-libs, none of which the
  installed binaries load: readelf shows they need only libstdc++,
  libgcc_s, libc and libm, so depends is gcc-libs and glibc.
- packaging/appimage was never built by any workflow; it and the
  *.AppImage globs in release.yml and the release manifest go away.
- packaging/homebrew/yams.rb was a stale CMake-era formula; release.yml
  renders the tap formula from yams.rb.template, which stays.

Signed-off-by: trvon <me@trevon.dev>
2026-10-01 17:15:46 -06:00
trvon
8250b061fc
build: release buildtype with split debug symbols
Release used buildtype=debugoptimized (-O2 -g, strip=false) and relied on
scripts/prune-runtime-install.sh to strip the staged payload, discarding
the debug info. Crash reports from shipped binaries could not be
symbolicated and the build type label did not match what shipped.

- setup.sh/setup.ps1 Release and the Meson project default use
  buildtype=release. setup.sh adds -Ddebug=true for Release so -O3 code
  keeps DWARF for the split, and passes -Db_pie=true explicitly (also a
  project default) so reconfigured build dirs pick it up. Windows keeps
  release without -g so no PDBs land in the MSI stage. Debug/Fuzzing are
  unchanged (-O0 -g, assertions on).
- scripts/split-debug-symbols.sh replaces prune-runtime-install.sh: ELF
  files get objcopy --only-keep-debug (compressed) into <debug-dir>/
  <path>.debug plus .build-id/xx/yyyy.debug links, strip
  --strip-unneeded and --add-gnu-debuglink; Mach-O files get dsymutil
  dSYMs and strip -S -x. Without a debug dir it only strips.
- The release job splits into $BUILD_DIR/debug-symbols and uploads it as
  a debug-symbols-<suffix> workflow artifact (30 days) instead of
  shipping or dropping it. build-deb.sh, the Dockerfile, PKGBUILD and
  build-arch-pkg.sh call the split script in strip-only mode.

Measured on grim (Linux x86_64, clang 21, stripped staged payload):

  file                         debugoptimized  release -O3   delta
  bin/yams-cli                     35,528,968   36,733,304   +3.4%
  bin/yams-daemon                  29,731,312   30,685,792   +3.2%
  bin/yams-mcp-server              19,504,928   19,865,472   +1.8%
  libyams_onnx_resource.so            477,280      481,488   +0.9%
  libyams_object_storage_s3.so      8,226,608    8,239,016   +0.2%
  yams_zyp.so                          79,936       80,040   +0.1%

Debug symbols: 309 MiB (compressed .debug files); gdb resolves
`info line main` on the stripped daemon through the .build-id tree.
check_install_surface: no debug sections or .symtab remain; the
remaining violations are the export leaks fixed later in this series.

Signed-off-by: trvon <me@trevon.dev>
2026-10-01 16:53:23 -06:00
trvon
15f3e3db73
refactor(compression): remove the never-built LZMA compressor
lzma_compressor.cpp targets the 7-Zip LZMA SDK (LzmaEnc.h/Alloc.h), but
the build only finds xz/liblzma, which does not ship those headers, so
every build (release logs: 'Has header "LzmaEnc.h" ... NO') compiled it
out. No build could read or write LZMA blocks, and its decoder never
bounded output by the expected size.

The policy still chose LZMA for cold/archival and large inactive data;
compression then failed ('Compressor not available') and batch stores
kept those blocks uncompressed. Select Zstandard, which already uses the
archive level for old data.

Remove the compressor, its test, the enable-lzma option and the build
flags that passed it. The LZMA algorithm id stays in the header format,
and compression.lzma_level remains accepted in config (now unused).
2026-09-23 19:31:37 -06:00
trvon
66e59d305f
build: make the deprecated ONNX Runtime integration opt-in
Default builds no longer pull onnxruntime: conan enable_onnx and the conan
profiles default to False, meson enable-onnx defaults to disabled and skips
onnxruntime discovery entirely, and setup.sh/setup.ps1 only enable ONNX
(and the ONNX-backed Glint plugin) with --with-onnx / -WithOnnx.
YAMS_DISABLE_ONNX=true still forces it off.

This removes a build blocker on hosts where conan tries to build
onnxruntime from source (e.g. ROCm/MIGraphX on Linux). Release, Docker, and
Arch packaging pass the flag explicitly, so shipped artifacts are unchanged
until ONNX is dropped.
2026-09-22 18:56:22 -06:00
trvon
e58aef6cf5
fix(ci): isolate arch package builds
- stop arch lanes from reusing build/release
   - fix local arch lane quoting
   - align release arch lane with isolated build dirs
2026-07-01 10:02:54 -04:00
trvon
5ce5e6a774
feat: Arch Linux packaging + CI
Add arch:
   - PKGBUILD + yams.install in packaging/arch/
   - build-arch-pkg.sh (pacman deps, makepkg, repo-add)
   - arch-lane.Dockerfile systemd validation substrate
   - arch-package.Dockerfile pre-baked CI builder
   - package-lane.sh --only arch (build + validate local lane)
   - package-validate.sh Arch lane (pacman -U/-R smoke-test)
   - release.yml: 2 new matrix entries, arch-repo metadata, R2 upload
   - publish-repos.yml: arch-repo download + R2 upload
   - yams-repo worker: /archrepo route, .pkg.tar.zst + .db/.files types
2026-07-01 05:50:59 +00:00