Skip to content

Fix #27's zip link, stub probe and divider margin; pin engine .27 - #40

Merged
maralcbr merged 5 commits into
mainfrom
fix/27-zip-download-link
Oct 4, 2026
Merged

maralcbr merged 5 commits into
mainfrom
fix/27-zip-download-link

Conversation

@scottjones

@scottjones scottjones commented Oct 4, 2026 •

Copy link
Copy Markdown
Collaborator

Fixes the three defects from @maralcbr's post-merge review of #27, in his priority order. I was wrong earlier in this description, where I said the stub and divider fixes were already on main.

1. Download link → zip (977e588). Since #38 the installer is published only as installer/<version>/<INSTALLER_FILE_STEM>-<version>.zip, but both release templates still gave …/Omarchy-MX-Mac-Installer-2.1.0.pkg as the update link. The identity test pinned the same .pkg name, so it didn't catch this. Both templates and the test now use .zip.

2. Stub containers no longer probed (876df11). A real stub reports the version of the macOS it was made from, so any(os.version …) still sent stubs to the diskutil limits probe. On a Mac with an existing Asahi or Omarchy install, one failed probe failed the whole inventory. The filter is now any(os.version and not os.stub …). The test's fake stub now carries a version and stub=True, as upstream's OSInfo does, and the test fails against the old filter.

Engine rebuilt and re-pinned as .27: installer-v0.9.2-omarchy.27.tar.gz, 17,839,422 bytes, SHA-256 4f9241b0139ba6ccdcfdb3484831002e07e36ba50274279c641ca2020593a15a. Two repacks with macOS /usr/bin/python3 3.9.6 produced identical bytes. Compared with .20, only omarchy_runtime.py and version.tag changed. verify-archive-modes and verify-source-lock pass. The app's bundled inspection pin, the packager and both templates select .27, and docs/extraction.md records it.

3. Divider can't freeze (4820d04). InstallerAllocationRecommendation adopted the recommended (doubled) size as the minimum before withholding the drift margin. In a band of free-space states this made min equal to max, with no margin left. The margin is now subtracted first, and the doubled size is adopted only strictly below the margin ceiling. New tests sweep that band in quarter-GiB steps, checking that the divider has a range and the margin survives; both fail on the old code. Near the partition floor the existing best-effort clamp is unchanged.

Validation (macOS, M4, Xcode toolchain): ./test/all passes (Homebrew Bash 5, Python 3.13). swift-format lint --strict is clean. swift test passes in debug and release: 519 tests, 1 skipped, 0 failures.

Not in this PR: publishing .27 and the signed catalog, and the hardware test (smallest-size encrypted install, reboot, full update). The "Later" items are also not included.

Effect on #39: once this merges, I'll rebase #39 and rebuild its engine once, as .28, on top of .27.

🤖 Generated with Claude Code

scottjones and others added 3 commits October 3, 2026 22:43
Since #38 the installer ships as a zip, published at
installer/<version>/<file stem>-<version>.zip. The release templates
still offered the old .pkg URL as the catalog's download link, and the
identity test pinned that stale name.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The recommended Omarchy size became the minimum whenever it fit the
usable space, before the drift margin was subtracted. In a band of free
space the minimum then equalled the maximum: the divider could not move
and the engine had no margin left at admission. The doubled size is now
adopted only below the margin ceiling, and tests check the range and the
margin across that band.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A stub carries the version of the macOS it was made from, so the
inventory still sent stubs to the limits probe, and one failed probe of
a stub on a Mac with an existing install failed the whole disk check.
The test's fake stub had no version, which hid it. Only versioned OSes
that are not stubs now qualify.

installer-v0.9.2-omarchy.27.tar.gz, 17,839,422 bytes, SHA-256
4f9241b0..., reproduced twice with macOS /usr/bin/python3 3.9.6; only
omarchy_runtime.py and version.tag differ from .20. The app's bundled
inspection pin and both release templates select it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@scottjones scottjones changed the title Point the release templates at the installer zip Fix #27's zip link, stub probe and divider margin; pin engine .27 Oct 4, 2026
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
scottjones added a commit that referenced this pull request Oct 4, 2026
The catalog's installation engine now carries #40's stub-probe fix and
this branch's Recovery step: installer-v0.9.2-omarchy.28.tar.gz,
17,843,348 bytes, SHA-256 0cf1aa87..., reproduced twice with macOS
/usr/bin/python3 3.9.6. Compared with .27 only omarchy_asahi.py,
omarchy_runtime.py and version.tag change. The app keeps bundling .27
for inspection.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@scottjones
scottjones requested a review from maralcbr October 4, 2026 03:57

@maralcbr maralcbr left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed at 9787a83. All three #27 follow-ups are fixed: the templates and identity test use the published zip path, stubs are no longer probed (with a realistic fixture that fails on the old filter), and the doubled size is adopted only below the margin ceiling, so the divider keeps a range and the drift margin survives. I rebuilt .27 twice with /usr/bin/python3 3.9.6 from the locked v0.9.2 checkout and got exactly 4f9241b0…, 17,839,422 bytes; against a .20 rebuild from main only omarchy_runtime.py and version.tag differ, and verify-archive-modes and verify-source-lock pass. ./test/all and swift test pass locally (677, 1 skipped).

@maralcbr
maralcbr enabled auto-merge October 4, 2026 09:55
@maralcbr
maralcbr merged commit a8dedf9 into main Oct 4, 2026
3 checks passed
@maralcbr
maralcbr deleted the fix/27-zip-download-link branch October 4, 2026 09:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants