v2.22.0 — the builds that reported success and produced nothing¶

Released 2026-08-16. Upgrade:

sudo snap refresh yazses     # snap
pipx upgrade yazses          # or: uv tool upgrade yazses

Two releases shipped without an Intel Mac bundle and without a Windows ARM one. Not because the builds were missing — both existed, both ran on every tag, and both failed every time. They are continue-on-error legs, which is the right call for a new cross-architecture job, and the consequence is that a failure appears nowhere a person looks: not the run summary, not the checks list, not the release page. The workflows reported success and attached nothing.

This release is mostly that shape, found in six places.

Two bundles that have never existed¶

The Intel .dmg failed at dependency resolution, and not for any reason to do with Intel. uv.lock is a single universal resolution pinning an onnxruntime that upstream publishes for Apple Silicon only, faster-whisper requires onnxruntime with no marker, and uv sync installs exactly what the lock says. That leg now resolves unlocked, where it backtracks to the last release carrying an Intel wheel, and it produced a working 85 MB bundle on the first run afterwards — the first this project has made.

The cost is written down rather than hidden: the Intel bundle is not built from the pinned dependency set, so it is not reproducible against uv.lock the way the Apple Silicon one is. The alternative was pinning the whole project two years back for one architecture Apple has already scheduled for removal.

The Windows ARM64 .exe failed before compiling anything, asking uv for an interpreter it had no build of. setup-uv was pinned to 0.5.x in the two desktop-bundle workflows and latest in the other five; that pin predates Windows ARM64 Python entirely. Lifted, it produced a 160 MB installer on its first run.

If you are on an ARM PC, the release notes now say so — the x64 installer runs there under emulation and was the only thing anyone was ever told to download.

Five of the six ways YazSes starts itself¶

Every component that spawns another — the daemon launching the tray and the overlay, the crashed-tray supervisor, the Settings window's Apply → Restart, and two lifecycle backends — used [sys.executable, "-m", "yazses.x"].

That is correct for a pip, pipx or uv install and silently wrong inside the shipped .app and .exe. There, sys.executable is the application rather than an interpreter; the bundle dispatches on argv; and an unrecognised first argument falls through to the CLI, which exits 2 — with no console, because the binary is windowed. So in a bundle the tray never appeared, the overlay never appeared, the supervisor's five relaunch attempts each did nothing, and Apply → Restart never restarted. Nothing reported any of it.

Three more defects came out of writing the fix down:

• The macOS Settings… button pointed at a file that does not exist. An earlier fix named a yazses-cli sibling on any frozen non-Windows build, and the macOS .app ships exactly one executable. Its test asserted that behaviour, so the bug was green.
• The overlay had no argv a bundle would accept at all — __main__.py carried no --overlay branch, making it unreachable from a bundle by construction.
• python -m yazses.cli --version printed nothing and exited 0. No if __name__ == "__main__" block, so the documented last-resort launch path did nothing, on exactly the installs with no other way to report a failure.

The macOS download is half the size¶

143.9 MB → 70.4 MB. uv sync was installing the dev group — pytest, mypy, ruff, hypothesis, an ONNX model — into the environment PyInstaller then analyses, so a linter and a test runner were being shipped inside the application.

The Intel bundle did not change size, which is the confirmation rather than an anomaly: that leg installs the project alone and never carried the dev group.

A live level meter, where the guessing was¶

The settings window's silence-threshold slider now has a meter under it. Hold your dictation key and speak: the bar shows whether you are clearing the line, and re-judges as you drag, so you can see when you have moved it far enough. Without it the slider is a person guessing at a float.

It reads the level from the running daemon — the process that owns the microphone — because opening a second capture stream would fight the one dictation uses.

Every Linux arm64 channel already worked¶

The documentation said otherwise, and had for some time. The snap has had an arm64 build on stable for two releases; the .deb declares Architecture: all and contains no compiled code, so the amd64 and arm64 release assets are the same package under two names and the APT repo has served arm64 all along.

Documentation drift is usually an overclaim. This one cost people support that existed, and sent them to a slower install path to get it.

Also¶

• The tray icon's "Y" was white on every state colour, measuring 1.71:1 on yellow — the badge meaning recording, but there is nowhere to type. It now picks black or white per state by contrast.
• Three design/ subtrees the repository treats as private could have been committed to a public repo: the site excluded them and a public file could not link to them, but the guard that decides whether the files themselves are published listed none of them.
• The ADR index listed 12 of 156 records. It is generated now, with a test that fails when it drifts.

Known: snap will lag¶

The snap upload succeeds and the store then holds the revision in review, so latest/stable will remain behind until it clears. The publish step now says which half failed rather than timing out silently — the credentials are fine, the queue is not us. pipx install yazses and the APT repo carry this release immediately.