pastilhasandClaude Opus 5
f4147cef30
Confirmed on macbookpro (macOS 26.6.2): four boots, four identical failures.
caldav's manifest declares apt/pacman/dnf and no brew, so the installer falls
back to the binary name — and radicale is not a Homebrew formula at all, it is
a Python app (pipx/uv). There is nothing correct to put in a brew field, which
is the real gap: PackageManager has no pipx member and osDependencies has no
way to say "unavailable on this platform", so the choice is a wrong guess
retried every boot or silence.
Also recorded, as a NON-bug, because it looked like the real failure and was
already over: the motion/react resolve error appeared on exactly one boot, when
m3e-canvas landed before plugins/node_modules/motion existed. Verified on the
machine — motion is installed and import('motion/react') resolves with 398
exports, and the current boot builds cleanly.
The gap that one exposes is still real: installNpmDependencies is called only
from the install flow, never at boot, so a plugin that arrives without that
flow completing leaves every boot failing a rebuild with "Maybe you need to bun
install" and nothing that ever will.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: f7a62308-0977-4cf4-aa29-c020853fd420
3.2 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| known-bugs/radicale-cannot-be-installed-on-macos | caldav retries `brew install radicale` on every boot, and there is no such formula | known-bugs | open | 2026-09-22 | stated | 8 |
On macOS, caldav fails its own dependency install on every single boot, logging a line that reads like a transient error and is permanent:
[caldav] radicale install failed (exit 1): … Warning: No available formula with the name "radicale".
Confirmed on macbookpro (macOS 26.6.2) 2026-09-22 — four consecutive boots, four identical failures.
Two things are wrong and only one is caldav's. plugins/caldav/manifest.ts declares
packages: { apt, pacman, dnf } with no brew entry, so the installer falls back to the binary name
and runs brew install radicale. And the fallback cannot succeed anyway: radicale is not a Homebrew
formula. It is a Python application, installed with pipx install radicale or uv tool install radicale.
Homebrew's suggestion in the log — "Did you mean radicle or cadical?" — is two unrelated projects.
So the manifest has nothing correct to put in a brew field, which is the actual gap:
PackageManager is 'apt' | 'pacman' | 'dnf' | 'brew' (plugins/manifest.ts). There is no way to express
"this comes from pipx", and no way to say "not available on this platform" — so the only outcomes are a
wrong guess retried forever, or silence.
Consequences, in order of how much they matter: caldav does not work on that machine at all (no calendars,
no contacts — the manifest's own reason says so); the failure repeats every boot with no backoff and no
memory; and the log line is indistinguishable from something worth chasing, which is how it cost a
debugging session that had been opened about something else entirely.
Worth deciding rather than patching: either PackageManager grows a pipx/uv member, or
osDependencies grows a way to declare a platform where a binary is genuinely unavailable, so the
installer can say it once and stop.
Found alongside, and NOT a bug — recorded so the next person does not chase it. The same log carried
[plugins] frontend rebuild failed: ResolveMessage: Could not resolve: "motion/react", which looked like
the real failure and was already over. It appeared on exactly one boot: the m3e-canvas plugin had landed on
disk before plugins/node_modules/motion existed. Verified on the machine afterwards — motion is listed
in the generated plugins/package.json, installed, and import('motion/react') resolves with 398 exports;
the current boot rebuilds cleanly.
The gap it exposes is real even though it healed. installNpmDependencies is called from exactly one
place, plugins/install.ts, the install flow. Boot (plugins/mount.ts) rebuilds the plugin frontend and
never installs anything. So a plugin that reaches plugins/ without that flow completing — cloned by hand,
or an install interrupted — leaves every subsequent boot failing the rebuild with a message that says
"Maybe you need to bun install" while nothing ever will. Here the install finished and the next boot was
fine; on a machine where it does not, the platform cannot recover on its own.