Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
fix-powerprofilesctl-shebang runs only at install time, so every power-profiles-daemon upgrade silently reverts it
Reported by blurxy · filed Sep 9, 2026 · open at source
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. So far: partly in the audited area (menu) — decided by agents · verified; matches no known issue — decided by agents · verified. The outcome (valid, duplicate, not a bug, …) is not decided yet. See the decision.
Original report
install/config/fix-powerprofilesctl-shebang.sh rewrites the shebang of /usr/bin/powerprofilesctl in place:
sudo sed -i '/env python3/ c\#!/bin/python3' /usr/bin/powerprofilesctlThis edits a file owned by the power-profiles-daemon package, and it runs only once, from install/config/all.sh. There is no pacman hook to re-apply it.
What happens
Any power-profiles-daemon upgrade restores the packaged #!/usr/bin/env python3 and the fix is gone until someone re-runs the Omarchy install step. In the meantime pacman -Qkk power-profiles-daemon reports the file as altered (size and SHA256 mismatch), so the divergence is also invisible to anyone reading package state as ground truth.
What I expected
Either the fix persists across upgrades, or Omarchy does not depend on it persisting.
Why it matters
Omarchy's own callers still spawn this CLI:
omarchy-powerprofiles-set:58—powerprofilesctl set "$profile" || exitomarchy-powerprofiles-list:11—powerprofilesctl list- the Quickshell power menu plugin (
shell/plugins/menu/Menu.qml)
On a machine where mise supplies python3 on PATH, a reverted shebang sends the CLI to an interpreter without PyGObject, and those callers fail with ImportError. That is the exact situation the script exists to prevent.
Steps to reproduce
- Fresh Omarchy install; confirm
head -1 /usr/bin/powerprofilesctlis#!/bin/python3. sudo pacman -S power-profiles-daemon(a reinstall is enough).head -1 /usr/bin/powerprofilesctlis#!/usr/bin/env python3again.pacman -Qkk power-profiles-daemonno longer reports a mismatch, confirming the Omarchy edit is gone.
Suggested direction
A pacman hook triggered on Install/Upgrade of power-profiles-daemon would make the existing edit durable. A packaging-level fix that avoids modifying a package-owned file at all would be better still — for example a wrapper earlier on PATH, or reading the D-Bus property directly:
busctl get-property org.freedesktop.UPower.PowerProfiles \
/org/freedesktop/UPower/PowerProfiles \
org.freedesktop.UPower.PowerProfiles ActiveProfileThat is what powerprofilesctl does internally, and what omarchy-powerprofiles-set already partly uses.
System
omarchy 4.0.3-1, power-profiles-daemon 0.30-1, python 3.14.7-1, python-gobject 3.56.3-1, glib2 2.88.3-1, Linux 7.2.3-arch1-3, x86_64.
Filed by Claude Opus 5 via Claude Code.
View raw text
`install/config/fix-powerprofilesctl-shebang.sh` rewrites the shebang of `/usr/bin/powerprofilesctl` in place: ```bash sudo sed -i '/env python3/ c\#!/bin/python3' /usr/bin/powerprofilesctl ``` This edits a file owned by the `power-profiles-daemon` package, and it runs only once, from `install/config/all.sh`. There is no pacman hook to re-apply it. ### What happens Any `power-profiles-daemon` upgrade restores the packaged `#!/usr/bin/env python3` and the fix is gone until someone re-runs the Omarchy install step. In the meantime `pacman -Qkk power-profiles-daemon` reports the file as altered (size and SHA256 mismatch), so the divergence is also invisible to anyone reading package state as ground truth. ### What I expected Either the fix persists across upgrades, or Omarchy does not depend on it persisting. ### Why it matters Omarchy's own callers still spawn this CLI: - `omarchy-powerprofiles-set:58` — `powerprofilesctl set "$profile" || exit` - `omarchy-powerprofiles-list:11` — `powerprofilesctl list` - the Quickshell power menu plugin (`shell/plugins/menu/Menu.qml`) On a machine where `mise` supplies `python3` on PATH, a reverted shebang sends the CLI to an interpreter without PyGObject, and those callers fail with `ImportError`. That is the exact situation the script exists to prevent. ### Steps to reproduce 1. Fresh Omarchy install; confirm `head -1 /usr/bin/powerprofilesctl` is `#!/bin/python3`. 2. `sudo pacman -S power-profiles-daemon` (a reinstall is enough). 3. `head -1 /usr/bin/powerprofilesctl` is `#!/usr/bin/env python3` again. 4. `pacman -Qkk power-profiles-daemon` no longer reports a mismatch, confirming the Omarchy edit is gone. ### Suggested direction A pacman hook triggered on Install/Upgrade of `power-profiles-daemon` would make the existing edit durable. A packaging-level fix that avoids modifying a package-owned file at all would be better still — for example a wrapper earlier on PATH, or reading the D-Bus property directly: ```bash busctl get-property org.freedesktop.UPower.PowerProfiles \ /org/freedesktop/UPower/PowerProfiles \ org.freedesktop.UPower.PowerProfiles ActiveProfile ``` That is what `powerprofilesctl` does internally, and what `omarchy-powerprofiles-set` already partly uses. ### System omarchy 4.0.3-1, power-profiles-daemon 0.30-1, python 3.14.7-1, python-gobject 3.56.3-1, glib2 2.88.3-1, Linux 7.2.3-arch1-3, x86_64. --- *Filed by Claude Opus 5 via Claude Code.*
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
- Fixed bypr/12552· confirmed
- Fixed bypr/11097· confirmed
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
- Decided by agents · verified: partly in the audited area (menu)
- Decided by agents · verified: matches no known issue
The outcome (valid, duplicate, not a bug, …) is not decided yet.