[Fix] Update Omarchy

[yoshimario]

Update omarchy does not work

[valasek]

More details.

When I run Update, Omarchy, it prints:

warning: linux-aarch64: ignoring package upgrade (7.2-2 => 7.2.3-2)

error: failed to prepare transaction (could not satisfy dependencies)

Something went wrong during the update!

Please review the output above carefully, correct the error, and retry the update. If you need assistance, get help from the community at https://omarchy.org/discord`

I did one step further, commented out line

# IgnorePkg = linux-aarch64

in file sudo nano /etc/pacman.conf

and rerun the update. Now it gives me

:: unable to satisfy dependency 'libaquamarine.so=13-64' required by hyprtoolkit
:: installing aquamarine (0.15.0-2) breaks dependency 'libaquamarine.so=13-64' required by hyprland
error: failed to prepare transaction (could not satisfy dependencies)

Something went wrong during the update!

Please review the output above carefully, correct the error, and retry the update.

If you need assistance, get help from the community at https://omarchy.org/discord

[Fail-Safe]

Same aquamarine / pinned-Hyprland ABI break as #134.

Arch Linux ARM moved to aquamarine 0.15 (libaquamarine.so=14) while Try Omarchy’s held Hyprland still needs .so=13, so Omarchy Update aborts mid-transaction. Commenting out the kernel IgnorePkg just exposes that conflict more clearly.

Fixes (new / reset images):

• [fix] Rebuild compatible Hyprland dependencies for factory images #142 — guest IgnorePkg hold and factory pin of aquamarine 0.14.0-2 so empty-root builds still resolve
• thinner update-only hold: [fix] Hold aquamarine with the pinned Hyprland ABI #136

Workaround on an existing VM (until a new/reset image ships the hold). Edit both files — Omarchy’s pre-refresh hook restores /etc/pacman.conf from the share copy:

for f in /usr/share/try-omarchy/pacman.conf /etc/pacman.conf; do
  sudo cp -a "$f" "$f.bak"
  if grep -q '^IgnorePkg = ' "$f"; then
    if ! grep -q '^IgnorePkg = .*\<aquamarine\>' "$f"; then
      sudo sed -i 's/^IgnorePkg = .*/& aquamarine/' "$f"
    fi
  else
    echo "IgnorePkg line missing in $f" >&2
    exit 1
  fi
done
grep -n '^IgnorePkg' /usr/share/try-omarchy/pacman.conf /etc/pacman.conf

Then retry Update. If it still tries to install aquamarine 0.15, paste that grep output.

[jtavin-smp]

The aquamarine-only hold has stopped being sufficient, as of today. Arch Linux ARM has now rebuilt hyprtoolkit against the new soname, so holding aquamarine alone moves the conflict rather than resolving it.

I watched it change during a single session: at 15:16 local, ALARM aarch64/extra still had hyprtoolkit 0.5.4-5 requiring libaquamarine.so=13-64. By 16:07 it was 0.5.4-6 requiring libaquamarine.so=14-64.

The result on an existing VM after applying the documented workaround is a different error, with the soname the other way around:

:: unable to satisfy dependency 'libaquamarine.so=14-64' required by hyprtoolkit

Current state on a v0.3.0 guest, from pacman -Q / pacman -Si:

Package	Installed	Requires / provides	Repo candidate	Requires / provides
aquamarine	0.14.0-2	provides .so=13	0.15.0-2	provides .so=14
hyprland	0.56.1-3.2 (held)	needs .so=13	0.56.1-3.2	needs .so=13
hyprtoolkit	0.5.4-4	needs .so=13	0.5.4-6	needs .so=14

Because the patched Hyprland is pinned at .so=13, aquamarine cannot move; and now hyprtoolkit's only upgrade candidate demands .so=14. The self-consistent set is all three on .so=13, which means hyprtoolkit has to be held alongside aquamarine until a rebuilt Hyprland ships.

Extending the existing workaround to cover it:

for f in /usr/share/try-omarchy/pacman.conf /etc/pacman.conf; do
  sudo cp -a "$f" "$f.bak"
  grep -q '^IgnorePkg = .*aquamarine'  "$f" || sudo sed -i 's/^IgnorePkg = .*/& aquamarine/'  "$f"
  grep -q '^IgnorePkg = .*hyprtoolkit' "$f" || sudo sed -i 's/^IgnorePkg = .*/& hyprtoolkit/' "$f"
done

Verified on this guest: with aquamarine held alone, pacman -Syup exits 1 on the .so=14 conflict. With both held it exits 0 and resolves 44 package upgrades. Editing both files matters for the reason already given in #134 — the update hook restores /etc/pacman.conf from the share copy.

Worth noting for #136 / #142: a hold list that names only aquamarine will hit this same wall now that ALARM has moved hyprtoolkit, so those may need the extra entry too.

[jtavin-smp]

Correcting my own report above on one point, and confirming the rest.

The hyprtoolkit finding holds. With both aquamarine and hyprtoolkit held, pacman -Syu completed on this guest: exit 0, 44 packages upgraded, no dependency errors. With aquamarine held alone it exits 1 on the .so=14 conflict, as reported.

Correction: I earlier attributed a gtk-update-icon-cache: The generated cache was invalid. failure on this guest to a transient condition, based on a manual re-run that appeared clean. That conclusion was wrong — my check had redirected stderr, so it was hiding the errors it was meant to surface. The failure reproduced in (13/14) Updating icon theme caches... during the completed upgrade, so it is repeatable and unrelated to the package holds. It is also harmless to the transaction: pacman reports the hook failure but does not roll back, and pacman -Qkk on the package that first surfaced it reports 279 total files, 0 altered.

I have not tracked down what makes the generated cache invalid, and it is a separate concern from this issue, so I am not going to speculate about it here.

[itamblyn]

🤖 Posted by @itamblyn's AI agent (Claude Fable 5.1) on their behalf.

Confirming #142 works from this end. On 3f7ec01 I ran the full factory build on an empty guest-work volume and it completed: package-lock resolution succeeded, the rebuilt aquamarine 0.14.0-2 and hyprtoolkit 0.5.4-6.1 matched their pinned library hashes, the patched Hyprland and ttfx reproduced their digests, and the runtime and app stages built and signed.

The resulting app boots an ephemeral VM to the Omarchy desktop (Omarchy 4.0.2-1, Linux 7.2.3-2, Hyprland 0.56.1 on Wayland). The in-guest Omarchy Update ran on first boot under the new package holds and finished without the aquamarine / Hyprland dependency failure described in this issue.