commit 0e18e8d8e321be1c56b35d16578c00cc3676d25a
Author: lucascouts <lucascs@protonmail.com>
Date: Mon Sep 7 13:46:44 2026 -0300

add(dev-util/{ai-memory-2.1.0,ai-memory-bin-2.1.0}, acct-user/ai-memory-0, acct-group/ai-memory-0), mod(.autoupdate/packages.toml): package akitaonrails/ai-memory, source and prebuilt, OpenRC in both scopes

ai-memory is a local-first long-term memory MCP server for AI coding agents.
Upstream ships a Rust workspace and Linux release binaries for x86_64 and
aarch64, so both a from-source and a prebuilt package are keyworded
~amd64 ~arm64 -- the -bin is not amd64-only the way sys-apps/ai-jail-bin is,
because here upstream publishes an aarch64 asset.

Upstream installs two systemd units, one system and one user. Both get an
OpenRC counterpart at the same scope, neither gated behind USE=systemd, and
each script names what the translation loses rather than pretending parity:
the system unit's PrivateTmp, ProtectHome, ProtectSystem=strict and
ReadWritePaths have nothing in OpenRC to map onto. scripts/check-openrc-
coverage.sh reports PASS on both packages, system and user scope.

The account comes from acct-user/ai-memory + acct-group/ai-memory (uid/gid
602, continuing this overlay's own run above ::gentoo's highest assignment)
rather than from upstream's sysusers.d drop-in, which is deliberately not
installed. The pair is in DEPEND as well as RDEPEND: src_install runs
`fowners root:ai-memory`, which resolves against the BUILD host's account
database.

Two defects found by building the image rather than reading the ebuild:

* doins -r forces 0644, and 80 of the 162 hook scripts ship 0755 and are
EXEC'd by the agents. Measured: 80 executable in the tarball, 0 after a
doins -r. They are installed with cp -a instead.
* `newsystemduserunit` does not exist -- the helper is systemd_newuserunit.
Bash prints "command not found", the phase still exits 0, and the user
unit simply never lands. Verified present in the image after the fix.

src_test runs `--lib --tests`, not upstream's `--bin ai-memory`: that target
carries test = false, so the phase passed having run zero tests. The real
suite is 846 unit tests plus 110 in tests/suite, all passing under
FEATURES=test. Doctests stay out because one of them is a `docker run` shell
snippet in a plain ``` block that rustdoc tries to compile as Rust -- an
upstream defect in a doc comment, reproducible outside Portage.

No USE flag for the LLM crate's local-embeddings feature. It is default-on
upstream and cannot be cleared from a `-p ai-memory-cli` build: the workspace
inheritance rejects `default-features = false` on the member, and the call
sites are not cfg-gated. Nothing is forced hardware-wise either -- it is
pure-Rust CPU inference with no CUDA, ROCm, SYCL or Metal in the graph.

The 490 crates come from a tarball this overlay generates and hosts
(distfiles.obentoo.org), following dev-util/codex: inline CRATES built fine
but drew Portage's "very large number of CRATES" notice and put 151 KiB of
DIST lines in the Manifest, now 626 bytes. Nothing produces that tarball
automatically, so the ebuild carries the exact regeneration commands and the
autoupdate record repeats that a bump is incomplete without them.

Validated on this host without root, with the four unprivileged-install
overrides: full `ebuild clean install` for both packages, image contents
compared file by file, and `FEATURES=test` for the source. Ownership of the
installed files is NOT verified -- fowners is a logged no-op under an
unprivileged build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>