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ć