Repository navigation
omarchy-settings: ship the full set on aarch64 for runtime-profile sources - #638
Merged
Merged
Conversation
This was referenced Sep 25, 2026
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 27, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
2 tasks
…urces A source with default/settings-runtime-profile decides at runtime which platform-specific files apply, so its aarch64 package now gets the same files, backup and optdepends as x86_64: the Thunderbolt request and the memory stack stay, and its HOOKS files ship as they are. The check that a Mac's asahi line survives still runs on every aarch64 build. Older sources, including the pinned v4.0.4, keep #380's aarch64 package: Thunderbolt removed, the HOOKS line guarded for asahi, the memory stack stripped. The keyboard backlight unit first-run enables ships whenever the source has it. pkgrel 4 so the recipe change builds: edge already holds 4.0.4-3 on both architectures. The payload built from v4.0.4 is unchanged.
maralcbr
force-pushed
the
mac/14-settings-profile
branch
from
September 28, 2026 03:31
227af03 to
2fecfe5
Compare
maralcbr
added a commit
that referenced
this pull request
Sep 28, 2026
No platform package is built for x86_64 and pacman refuses another architecture's package there, so x86 transactions gain nothing from the guard. The x86 HOOKS baseline keeps the busybox line without a detector, so the detector copy goes too. omarchy-settings gets the same change in #638.
maralcbr
added a commit
that referenced
this pull request
Sep 28, 2026
No platform package is built for x86_64 and pacman refuses another architecture's package there, so x86 transactions gain nothing from the guard. The x86 HOOKS baseline keeps the busybox line without a detector, so the detector copy goes too. omarchy-settings gets the same change in #638.
No platform package is built for x86_64, so an x86 machine has nothing to guard. The check that 00-omarchy-hooks.conf has its detector copy follows it: without the copy, x86_64 keeps the busybox line it would have anyway, and leaving the check unscoped would fail every x86_64 build from a source that asks omarchy-hw-platform. Taken from #691, which keeps the -dev recipe.
1 task
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
Contributor
spencerbull
pushed a commit
to jacob-vincent-mink/omarchy-pkgs
that referenced
this pull request
Sep 28, 2026
The guard and its detector copy now ship on aarch64 only (omacom#691), so the check that 00-omarchy-hooks.conf has its detector failed every x86_64 build from a source that carries the HOOKS baseline. x86_64 keeps the busybox line without a detector. Same scoping as omarchy-settings in omacom#638.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
2 of 3 tasks
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
jethrojones
pushed a commit
to jethrojones/omarchy-pkgs
that referenced
this pull request
Sep 28, 2026
…e sources omacom#638 gave omarchy-settings this and -dev was never ported, so edge, the only channel aarch64 machines are qualified for, still stripped zram, oomd, zswap, the sysctl tuning and USB autosuspend there: on Snapdragon, migration 1790328426 installs zram-generator, finds no dev-zram0.swap and completes without zram. A source with default/settings-runtime-profile now gets the same files, backup and optdepends on aarch64 as on x86_64, Thunderbolt drop-in included, and its HOOKS files ship as they are. Older sources, including the current quattro pin, keep today's aarch64 package. The platform guard and its detector check stay aarch64-only (omacom#691, omacom#694). The keyboard backlight unit first-run enables ships whenever the source has it, as in omarchy-settings. tests/settings-runtime-profile.sh now runs both recipes. pkgrel 5 so the recipe change builds; the payload from the current pin is unchanged.
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Sep 28, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
3 tasks done
maralcbr
added a commit
to omacom/omarchy-mac
that referenced
this pull request
Oct 6, 2026
The omarchy-settings recipe leaves the mkinitcpio, Limine, memory and USB drop-ins out of its aarch64 package, because they used to assume x86_64. That leaves an aarch64 install without the HOOKS baseline its initramfs needs, and without the zram and reclaim settings every other Omarchy machine gets. Each of those files now decides at runtime whether it applies: the HOOKS baseline asks the platform, thunderbolt is added only where the kernel has the module, the Limine files are read only where Limine is installed, the oomd drop-ins are inert without systemd-oomd, aarch64 installs the zram generator the zram drop-in needs, and the USB autosuspend option is ignored by a kernel that builds usbcore in. default/settings-runtime-profile says so, file by file; a recipe that finds it ships the same files on every architecture (omacom/omarchy-pkgs#638), and older sources keep today's aarch64 package. A test checks that every file it names exists and that each runtime decision is in place.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Ticket 14 recipe side. Runtime side: omacom/omarchy#13362 (marker
default/settings-runtime-profile, now at fe9611efa).Caution
Maintainer decides when to merge. Merging publishes omarchy-settings 4.0.4-4 to edge, x86_64 and aarch64. Built from the pinned v4.0.4, its payload is the same as 4.0.4-3 on both (see Publishing). rc and stable are untouched until a release.
What changed
Rebased onto master after #380.
default/settings-runtime-profiledecides at runtime which platform-specific files apply. Its aarch64 package gets the same files, backup and optdepends as x86_64: the Thunderbolt request, the memory stack (oomd, zram, zswap, full sysctl, USB autosuspend), and its HOOKS files as they are.asahiguard, and the memory stack is stripped.omarchy-brightness-keyboard-auto.serviceships whenever the source has it (first-run enables it).omarchy-settings-devis unchanged, as before.Publishing
Real makepkg builds from the pinned v4.0.4, 4.0.4-3 recipe against 4.0.4-4, on both architectures:
.PKGINFOare identical apart from version, builddate, size and packager..INSTALLincluded, except 36 icon PNGs made by ImageMagick. Those are pixel-identical; only their embedded timestamps differ, as on any rebuild.So on edge:
post_upgradere-copies the etc-overrides, as every omarchy-settings upgrade does: os-release, faillock, nsswitch, cups-browsed, cups-files, plymouthd.conf and skel .bashrc. Local edits to those are reset.post_upgradeonly reinstalls cups-files.conf and keeps /etc/os-release pointing at the distribution's.The runtime-profile path only takes effect when omarchy and omarchy-settings are pinned to a source carrying the marker.
Platform guard (from #691)
The pacman platform guard's hook, script and detector copy now ship on aarch64 only; #691 keeps the -dev recipe. No platform package is built for x86_64, so an x86 machine has nothing to guard. The check that
00-omarchy-hooks.confhas its detector copy is scoped to aarch64 with it. Without the copy, x86_64 keeps the busybox line it would get anyway, and left unscoped the check would fail every x86_64 build from a #13362 source. v4.0.4 has no guard files, so the publish above is unchanged.Testing
tests/settings-runtime-profile.sh, wired into the self-tests. It runspackage()on both architectures for a v4.0.4-style source and for a #13362 source with the marker, and fails against master's recipe. The profile packages are identical apart from the aarch64-only guard.tests/settings-boot-config.shpasses unchanged, including the pacman upgrade checks as root.OMARCHY_SRC): the aarch64 and x86_64 packages have the same files, modes, contents and.PKGINFOapart fromarch.makepkg --printsrcinfoover-lists thebackup/optdependsadded inpackage(). Nothing reads.SRCINFOfor this recipe.Second review: no blocking findings; tightened two test assertions (network-only sysctl, no guard on x86_64).