A shell entered via `su` keeps the ORIGINAL user's XDG_RUNTIME_DIR, so
`systemctl --user` hunts for the bus in someone else's directory and finds
nothing — even when this user's manager is running perfectly. v0.7.2 detected
that and told the operator to export the right path. Typing /run/user/100
instead of /run/user/1000 cost a whole run.
The runtime dir is /run/user/<uid> by definition. The script now derives it,
retries the bus check with it, and installs the units — then tells the operator
to export it for the REST of their shell, because a child process cannot fix
its parent's environment.
The failure message also stopped guessing. It now distinguishes the two real
cases: /run/user/<uid> missing (no logind session — enable-linger, and no fresh
login is needed, contrary to what v0.7.1 said) versus present but unanswered
(the manager itself is the problem — go look at user@<uid>.service).
Four branches fired in a sandbox with three stub systemctls: bus answers
directly; bus answers only with the corrected dir; runtime dir absent; runtime
dir present but manager silent. All exit 0, and the middle one installs units
that the previous version would have skipped.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Found by running install.sh on a second box, not by rereading it. Debian ships
the venv module but splits ensurepip into python3.N-venv. `python3 -c "import
venv"` therefore SUCCEEDS on a machine where `python3 -m venv` cannot work —
the pre-flight passed and the install died two steps later, after writing a
half-built .venv.
Importing a module says nothing about whether it can do its job. The check is
now `import ensurepip`, it runs before anything touches disk, and the error
names the exact versioned package (python3.13-venv on that box).
The old failure text also offered a two-branch diagnosis that matched neither
the real cause nor Python's own message, which already named the right package.
Guessing on top of a correct error makes it worse. It now says where to look
and gets out of the way.
Fired both ways in a sandbox: with ensurepip the install completes; with a
python stubbed to refuse it, the script dies early, prints the versioned apt
package, and leaves no .venv behind.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two portability bugs, both found by pre-flighting a second machine (kdmirah,
a Debian LXC) rather than by reading the script again.
1. `systemctl` existing does not mean a user bus is reachable. Inside an LXC,
over `su`, or with no logind session, `systemctl --user` fails with
"Failed to connect to user scope bus". The old check asked whether the
binary was on PATH, then ran `systemctl --user daemon-reload` under
`set -euo pipefail` — so the install ABORTED halfway, after the venv and
before the hermes wiring. It now asks the real question,
`systemctl --user show-environment`, and on failure installs no units, says
why (naming XDG_RUNTIME_DIR and the usual causes), prints the three
commands to run by hand, and continues to hermes.
2. The hermes interpreter was hardcoded to this box's layout,
/usr/local/lib/hermes-agent/venv/bin/python. kdmirah installs hermes under
~/.local/bin with its venv at ~/.hermes/hermes-agent/venv. Both are bash
wrappers that exec their python, so the path is now read out of the wrapper
(with a pip console-script shebang as the second shape). Verified against
both machines: each derives its own interpreter and each reports mcp present.
Also: the closing summary no longer prints the dashboard URL and
`journalctl --user -u socialmag-refresh` when no units were installed. Pointing
someone at a journal for a unit that was never created is the same class of lie
as a silent fallback — it reads as working and answers with nothing.
Both branches fired in a sandbox with a fake HOME and two stub systemctls, one
that answers show-environment and one that refuses it. Both exit 0; the
refusing one installs nothing, warns loudly, and still registers hermes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A clone + ./install.sh + ./launch-brave.sh + sign in once. Nothing else.
pyproject.toml declares the one real dependency (websockets) and maps the
repo-root-is-the-package layout, which retires the PYTHONPATH=<parent> line
every unit used to carry.
cli.py backs three console scripts. They exist because `python3 -m socialmag`
run from INSIDE a clone dies at `import asyncio`: the repo root is the package
dir, so it ships selectors.py and queue.py, and python puts the current
directory first on sys.path. `cd socialmag` is the first thing anyone does
after a clone, so the documented workaround failed at exactly the moment it
would be tried. A generated bin/ script never puts cwd on sys.path.
The same trap bit `python3 -m venv` inside install.sh — the installer was
broken by the thing it exists to fix. Every python3 call now runs from /.
deploy/user/*.in replaces root system units with systemd --user templates:
no User=, WantedBy=default.target, venv paths, @REPO@/@VENV@/@CDP_ENDPOINT@
substituted at install time. deploy/home/ is untouched and still live here.
launch-brave.sh carries --disable-background-timer-throttling. That is
load-bearing, not tidiness: five of six platforms are read in a hidden tab, and
a throttled background tab stops running the timers those pages use to fetch
their own data — the reads come back empty with no error.
install.sh checks the mcp package in hermes's own interpreter and refuses to
continue without it. Hermes treats mcp as optional and silently no-ops the
whole subsystem when it is missing, so a server that never loaded looks exactly
like one that loaded and did nothing.
It will not merge into an existing mcp_servers: key — it backs up config.yaml
and appends only when the key is absent, otherwise it prints the block. Blind
YAML merging is how someone's other servers disappear.
Verified end-to-end in a sandbox with a fake HOME and stubbed systemctl:
real MCP initialize handshake from inside the repo dir returns all 7 tools;
hermes's own yaml parser re-reads the written config with every pre-existing
key intact; a second run leaves the mcp_servers key count at 1; launch-brave.sh
exits 1 against a busy port; no unsubstituted @PLACEHOLDER@ in any rendered unit.
Not fixed, pre-existing: server.py reports SERVER_VERSION 0.1.0 while the repo
is at v0.7. The handshake shows 0.1.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
juxtapoandClaude Opus 5