David Heinemeier HanssonandGitHub
2cc3510d2a
* Offer an AI diagnosis when a process crashes systemd-coredump journals every core dump under a known MESSAGE_ID with the crashing program, pid, and signal as structured fields. omarchy-crash-watch follows that stream and raises a "Process crashed: <program>" toast; clicking it opens omarchy-agent-crash, which briefs the default agent on the crash. The toast goes through omarchy-notification-send --exec rather than a libnotify action, because the shell runs clicks from its own omarchy-exec hint and never emits ActionInvoked. It keeps the default "omarchy-action" app name too, the only one shouldBypassDnd() lets through -- a crash being the last notification worth swallowing. It stays quiet until an agent is configured, since a diagnosis is all it offers. The method lives in a diagnose-crash skill rather than the prompt, so it is edited in one place and works with whichever agent is default. It covers investigating the core, and reporting a confirmed Omarchy bug upstream: scoped to bugs Omarchy controls, searched for duplicates first, only with the user's agreement, and signed with the model and harness that produced it. A migration reaches existing installs, whose skill symlinks and unit enablement would otherwise sit behind one-time setup paths. * Let the diagnosis clean up the core it extracted "Do not modify or delete anything" contradicted the symbolization step right above it, which writes a core to a temp file and deletes it on exit. Read literally, the core survives -- and the same section warns it holds passwords and tokens. The prohibition is about the system, not about your own scratch. * Do not spend a crash toast on a dead notification server The shell owns org.freedesktop.Notifications, so its own crash takes the notification server down with it -- and a shell crash is exactly what you want told about. The toast was sent once into that gap and the dedupe window was recorded regardless, so the rest of the crash loop went quiet for a minute and `journalctl -n 0` never replays what was missed. It now waits for the restarted shell to reclaim the bus name, as omarchy-migrate-notify already does, and only a delivered toast starts the dedupe window.
105 lines
3.9 KiB
Markdown
105 lines
3.9 KiB
Markdown
# Reporting a Crash Upstream to Omarchy
|
|
|
|
Read this only after concluding that a crash is genuinely Omarchy's to fix.
|
|
|
|
## Is it even Omarchy's bug?
|
|
|
|
Be strict here. Omarchy is a configuration layer over Arch Linux, so a crash
|
|
inside a third-party application — a file manager, a browser, a GNOME or Qt
|
|
library — is almost always an upstream bug in **that** project, not in Omarchy.
|
|
|
|
Omarchy's sphere of control is roughly:
|
|
|
|
- the `omarchy-*` commands
|
|
- the Quickshell shell and its plugins
|
|
- the Hyprland and terminal configuration it ships
|
|
- its themes
|
|
- its install and migration scripts
|
|
- how it packages and configures what it installs
|
|
|
|
A crash in a program Omarchy merely installs is **not** an Omarchy bug unless
|
|
Omarchy's own packaging or configuration is implicated.
|
|
|
|
If it is not Omarchy's, say so and stop. Suggesting the right upstream project is
|
|
useful; filing there yourself is not part of this.
|
|
|
|
## Three conditions, all required
|
|
|
|
1. **It is a verified bug in Omarchy's sphere**, established on evidence. Issues
|
|
are for verified bugs only. An "is this even a bug?" belongs on the Discord at
|
|
<https://omarchy.org/discord>; a feature idea belongs in GitHub Discussions
|
|
under Suggestions.
|
|
2. **The user has explicitly agreed.** Show them the exact title and body you
|
|
propose, and wait for a yes. Never file unprompted.
|
|
3. **The machine can file it** — `gh auth status` must succeed. If `gh` is missing
|
|
or unauthenticated, do not install or authenticate it. Say so, and hand the
|
|
user the finished text to submit themselves.
|
|
|
|
## Search before filing
|
|
|
|
A duplicate issue costs a maintainer more time than no report at all.
|
|
|
|
```bash
|
|
gh search issues --repo basecamp/omarchy "<program> crash"
|
|
gh issue list --repo basecamp/omarchy --state all --search "<signal> <program>"
|
|
```
|
|
|
|
Search on the crashing program, the signal, and distinctive symbols from the
|
|
backtrace — not on the wording of the title you were about to write.
|
|
|
|
`gh search issues` accepts only `open` or `closed` for `--state`, and errors on
|
|
anything else. Leaving it off searches both, which is what you want here.
|
|
|
|
Include **closed** issues. A matching issue closed as fixed, when the crash still
|
|
reproduces on a current system, is a regression — and reporting that is worth far
|
|
more than another duplicate.
|
|
|
|
## Adding to an existing report
|
|
|
|
If a plausible match comes back, read it properly first:
|
|
|
|
```bash
|
|
gh issue view <number> --repo basecamp/omarchy --comments
|
|
```
|
|
|
|
Confirm it is genuinely the same failure. The same program crashing is not the
|
|
same bug if the trigger or the stack differs.
|
|
|
|
If it is the same, add to that issue rather than opening a new one — but only
|
|
when you have something the thread does not already contain: a different
|
|
reproduction, a symbolized stack where it has none, a narrower trigger, a version
|
|
where it regressed.
|
|
|
|
A comment that only says the bug happens to you too is noise. If that is all you
|
|
have, tell the user so and file nothing.
|
|
|
|
```bash
|
|
gh issue comment <number> --repo basecamp/omarchy --body "..."
|
|
```
|
|
|
|
## Filing a new issue
|
|
|
|
Only when the search turns up nothing that matches:
|
|
|
|
```bash
|
|
gh issue create --repo basecamp/omarchy --title "..." --body "..."
|
|
```
|
|
|
|
Include what happened, what was expected, steps to reproduce, system details from
|
|
`omarchy version`, and diagnostics from `omarchy debug --no-sudo --print` (which
|
|
also writes `/tmp/omarchy-debug.log`; the interactive `omarchy debug` can upload
|
|
it and print a shareable URL worth including).
|
|
|
|
`gh` cannot attach media. If a screenshot would help, save one and give the user
|
|
the path to drag into the web form.
|
|
|
|
## Signing
|
|
|
|
End the issue or comment with a line naming the model and agent harness that
|
|
produced it, so a human reader knows it was machine-authored:
|
|
|
|
> Filed by \<model name\> via \<agent harness\>.
|
|
|
|
Use your actual model and harness names. If you are not certain of them, say so
|
|
plainly rather than inventing a version string.
|