Omarchy enables omarchy-usb-authorization.service and
omarchy-thunderbolt-authorization.service from first-run, and the
Thunderbolt one from its setup command and a migration. The settings
packages left both only in /usr/share/omarchy/default/systemd/user, where
systemd does not look.
On edge the Thunderbolt migration (1790344599) therefore fails with "Unit
omarchy-thunderbolt-authorization.service does not exist" and every later
migration stays pending. First-run fails as well and enables none of its
units.
Install both in /usr/lib/systemd/user, wherever the source has them: the
4.0.4 release does not, so its package is unchanged.
The self-tests, the build-isolation fixture and the three tracker
workflows pulled archlinux:base-devel from Docker Hub without logging
in. On 2026-10-09 that failed two jobs on one pull request: one with
'toomanyrequests', one with a 504 from Docker Hub's token endpoint.
Arch publishes the same image as ghcr.io/archlinux/archlinux, which
GitHub's runners pull without that limit.
The publish job runs in the concurrency group "publish" with
cancel-in-progress: false. By default such a group holds one running job
and one waiting job: when a third arrives, GitHub cancels the one that was
waiting and puts the new one in its place. That merge's publish is dropped,
with no publish record, PR comment or log line, and nothing reruns it.
17 of the last 181 publish runs ended cancelled, 12 of them from one burst
of merges on 2026-09-28. openvino-genai 2026.4.0.0-1 (#620) was one of
those and is still in no channel.
queue: max lets up to 100 jobs wait in the group and run in the order they
reach it. Nothing else changes: one publish at a time, and a running one is
not interrupted. unpublish.yml shares the group, so it gets the same
setting.
actionlint 1.7.12, the latest release, predates the key and reports it as
unexpected in both files (rhysd/actionlint#654). It reports nothing else.
The README described the repository host as the publisher: bin/repo
release as the main workflow, five-minute systemd timers, a signing key
that lives on the host and nowhere else, aarch64 under emulation. Since
September 18 packages are built by build-pr.yml and published by
publish.yml, and neither workflow was mentioned. ci/README.md still opened
with "Status: spike. Nothing here publishes."
The README now covers, in order: contributing a package, how a package
reaches users, where it is published, the maintainer tasks (republish,
build, retire, check that a version is live, read the publish log), what
to do when a publish fails, who can build and merge, the three scheduled
update workflows, package metadata, releases, and the rules that keep two
publishers from colliding.
Text about the old host pipeline moved to docs/repository-host.md, marked
abandoned. The rest moved to docs/ largely unchanged:
- docs/releases.md: the release train and versioning rules
- docs/rebuild-triggers.md: rebuild_on and bin/sync-rebuilds
- docs/builds.md: dependency order, isolation, builder images
- docs/upstream-sources.md: gains the provider and hook reference
ci/README.md is rewritten as the operating guide for the x86_64 builder
pool. Statements the move would have carried over wrong are corrected,
among them the signing key's location, AUR sync, and which architecture
list CI reads. bin/sync-upstream's help now points at the docs page that
holds the provider schemas.
A builder droplet starts with no images, so publish.yml built
omarchy-pkg-builder from the Dockerfile each time: about 100 s of
pacstrap, keyring setup and toolchain install, to run gpg, repo-add,
bsdtar and rclone for about 14 s.
builder-images.yml already publishes the tested image for the current
build inputs to ghcr.io/omacom/omarchy-pkg-builder under bin/builder-image
key. Pull that, check its org.omarchy.builder.key label, and tag it as the
local name the rest of the step uses.
Build as before when no image carries the key, which is what a merge
that changes build/ sees until the refresh it triggered has finished.
Co-authored-by: Ryan Hughes <ryan@heyoodle.com>
The 2026-10-07 nightly ships the same six compatibility libraries with
their full versioned file names beside the short ones (libXss.so.1.0.0),
and two under their GTK 3 names (libappindicator3, libindicator3). The
guard in package() listed the short names only, so it stopped the build
on both architectures and with it the bundled upstream sync (#837).
Accept an optional 3 and trailing version numbers. Anything else in
usr/ still stops the build. t3code-bin carries the same guard and gets
the same pattern before the change reaches a stable release.
Upstream's 6771b19 ("keep smoke artifacts in the build directory") made
omasnap-smoke reject positional paths; the directory is now passed with
--output-dir. check() still passed it positionally, so every build of a
pin at or past that commit failed with "Unexpected positional argument;
use --output-dir <directory>."
Pass it as --output-dir and move the pin to 6771b19, the tip the branch
tracker has been trying to merge since October 4. The two have to land
together: the old pin does not know --output-dir.
The dropbox watch failed with "no matching releases" on some runs
(e.g. actions run 37236931512). It is not the network: Dropbox's download
redirect sends a share of requests to a newer build the pattern rejects
on purpose. On 2026-10-04, 96 of 100 HEADs ended at
dropbox-lnx.x86_64-272.4.3798 and 4 at 274.3.4801, which is not an x.4.y
stable build. The redirect provider made one probe, so one unlucky
answer failed the whole watch.
It now probes up to five times and keeps the first final URL that
matches, and curl gets --retry 2 as Fetcher.file already has. Live,
100 discovers against Dropbox all found 272.4.3798 in 103 probes. Two
tests cover a rollout answer before the stable one and every probe
missing.
rustdesk 1.5.0 and its newer vcpkg pin moved five of the ports the recipe
pre-seeds into vcpkg's downloads:
aom 3.12.1 -> 3.14.1 (rustdesk's overlay port)
ffmpeg 7.1 -> 7.1.1 (rustdesk's overlay port)
libjpeg-turbo 3.1.1 -> 3.2.0
meson 1.8.2 -> 1.9.0
pkgconf 2.5.1 -> 3.0.3
vcpkg found none of the old archives useful and fetched all five itself
mid-build, aom from googlesource. Each new tarball matches the SHA512 in
its vcpkg port.
0004-bindgen raised libs/scrap's bindgen to 0.72.1 for Clang 22 and
added a git override for it. rustdesk 1.5.0's libs/scrap/Cargo.toml
already requires bindgen 0.72.1, so the patch no longer applies (the
Cargo.toml hunk fails and the scrap hunk is detected as applied) and
prepare() stopped. Comment it out like the retired 0001 patch and drop
its checksum entries.
googlesource's +archive tarballs are generated per request: their bytes
change on every download, so the recipe skipped their checksums, and the
endpoint refuses CI runners at times (503s on aom failed two #785
builds). Clone both at their pinned commits instead, which git verifies.
_prepare_vc writes downloads/<port>-<ref>.tar.gz with the same git
archive command vcpkg_from_git uses, so vcpkg finds them cached. The
archives hold exactly the files of the old tarballs (aom 1347, libyuv
183).
rustdesk 1.5.0 moved VCPKG_COMMIT_ID in flutter-build.yml from 120deac
to 9e593bb (vcpkg, 2026-07-30), and _prepare_vc stops the build when the
recipe's pin differs. Add the 1.5.0 row to the vcpkg table and the new
archive's checksums. Flutter 3.24.5, Rust 1.75 and the README's vcpkg
library list are unchanged from 1.4.9.
Upstream's res/PKGBUILD no longer depends on pam as of 1.5.0. The
recipe's prepare() checks _dpr against that list, so the sync's version
and checksum bump stopped in _dpr_check with "Update _dpr from
res/PKGBUILD/depends=()". The bump is the sync's, unchanged; _dpr now
matches upstream's 1.5.0 depends.
Upstream's release PKGBUILD added python (packaged skill scripts, since
1.12.0), layer-shell-qt (a required build dependency for the Game Mode
overlay, since 1.14.0) and the libpulse and umu-launcher optdepends.
The upstream sync only rewrites pkgver and checksums, so the recipe kept
1.12.0's dependency list: the published 1.12.0 lacks python, and the
1.14 builds in the sync PR fail at CMake on LayerShellQt.
The recipe now matches upstream's PKGBUILD-1.14.2, comments aside.
When edge already holds the version, a PKGBUILD whose recipe changed
(comments and blank lines aside) builds nothing and publishes nothing.
Arch bumps pkgrel only when the built package changes, which is the
reviewer's call, so this is a warning annotation on the PKGBUILD and a
job summary line, not a failure. Comment-only and hook-only changes
stay silent.
A PR can change a package's directory without bumping its version: an
upstream hook, its tests, a README. bin/build then plans nothing, and
the pack step failed on the empty build output, turning the required
result check red (seen on #769). Make the same dry-run check
publish.yml's rebuild job already makes, and skip packing and uploading
when nothing was built. publish.yml finds no artifact for such a merge
and records the package as already published.
Emir Beganović