Updates — 2026-07-28

maintained/libkcompactdisc: no update (false positive)

check_for_updates_maintained.sh flagged UPD ... 25.12.3 58 (bogus 58). Standalone nvchecker -c .nvchecker.toml returned 25.12.3, matching the installed pkgver – no actual update needed. This is a recurring transient scrape glitch on the KDE GitLab tags page this package’s .nvchecker.toml scrapes with a regex (same glitch previously seen 2026-07-20 as a bogus 52) – see memory/libkcompactdisc.md.

maintained/libarchive-static: 3.8.8-1 -> 3.8.9-1

Routine pkgver bump tracking upstream libarchive; bundled deps (attr, acl, openssl, zlib, xz, bzip2, zstd) unchanged this cycle (nvchecker-deps.toml diff empty). updpkgsums only moved the libarchive source’s sha512sum. Built, signed, published for x86_64 via repo_release_changed.sh. See memory/libarchive-static.md.

maintained/pdfalto: 0.6.1-1 -> 0.6.2-1

AUR-flagged out-of-date since 2026-07-21; nvchecker (git-tag source) confirmed 0.6.2 is a real upstream release. updpkgsums moved only the tarball source’s checksum. Built, signed, published for x86_64 via repo_release_changed.sh – this succeeded despite prior sessions’ concern about missing libpng14/gcc12, so those must already be satisfied on this host/in this repo now. See memory/pdfalto.md.

private/archlinux32-keyring: real bug fix, checksum was stale

Found broken while triaging the routine changed-set release batch: a prior, undocumented pkgver bump to 20260116 never got a matching updpkgsums run, so sha512sums still held the old 20240131 tarball’s hash – this package could never have built since that bump landed (.SRCINFO was stale too, still showing pkgver = 20240131). Fixed with updpkgsums + regenerated .SRCINFO; built, signed, and published (arch=any) via repo_release.sh private/archlinux32-keyring. See memory/archlinux32-keyring.md.

Routine changed-set release batch (repo_release_changed.sh, x86_64)

28 packages showed NEW/CHANGED against the private repo (repo_diff_local_remote.sh). Results: 2 PASS initially (libarchive-static, pdfalto above), 26 FAIL; one of the 26 (archlinux32-keyring) turned out to be a real, fixable bug (see above) and passed on a follow-up individual release, bringing the confirmed total to 3 published. The other 25 are the same long-standing backlog that persists cycle to cycle (already documented per-package in memory/): mostly Could not resolve all dependencies against out-of-tree AUR-only packages (cmake3, qt5-webengine, gtk-sharp-2, etc.) or intra-tree ordering (qgpgme1-qt5 needs gpgme-1, which failed this batch too), plus a couple of real build failures (cppcms, kdiagram5, kjots) and one persistent upstream issue (gpgme-1: dev.gnupg.org returning HTTP 429 on every attempt, including a same-session standalone retry outside the batch – not request-volume-related, genuinely blocked right now). New memory files written for archlinux32-keyring, qgpgme1-qt5, yabause-qt5 (previously undocumented); gpgme-1 updated with the recurrence + standalone-retry result. Full per-package logs in repo_release_logs/. Overview and site regenerated/republished.

Updates — 2026-07-27

maintained/i686-elf-binutils: 2.45-2 -> 2.47-1

Routine pkgver bump (upstream GNU binutils, tracked directly via .nvchecker.toml). Verified 2.47 is a real release (present alongside 2.46.0/2.46.1/2.45.1 etc. on ftp.gnu.org), not a bait flag. updpkgsums regenerated the sha256sum; test build via extra-x86_64-build succeeded (pre-existing namcap lint noise from the cross-toolchain layout, not a regression). No dependents in this tree need a rebuild – see memory/i686-elf-binutils.md. Built, signed, published (main + debug); overview and site regenerated/republished.

maintained/x86_64-elf-binutils: 2.46.0-1 -> 2.47-1

Same cycle, same upstream release as the i686-elf-binutils bump above (both pull the identical binutils-2.47.tar.xz, matching sha256sums confirmed that). Test build via extra-x86_64-build succeeded. No dependents in this tree. Built, signed, published (main + debug); overview and site regenerated/republished.

Updates — 2026-07-25

maintained/linux-lts515: 5.15.211 -> 5.15.212

Routine kernel point-release bump via the package’s own update.sh, built and published on all 4 archs (x86_64, i686, i486, pentium4; kernel + headers

• docs subpackages each). Found and fixed a real sequencing bug in update.sh along the way: it updated PKGBUILD’s checksum for the shared config source file only after reconciling all archs’ configs, but the 32-bit archs’ builds also validate that same shared config entry (their source_i686/etc arrays add a per-arch config, they don’t replace the shared one) – so the second arch onward saw a checksum mismatch against the (by-then-stale) PKGBUILD value. Reordered so the shared checksum updates right after x86_64’s config is reconciled, before the loop moves on. pkgrel stays at 1 per convention. Overview and site regenerated/republished.

private/notion3: pkgrel 5 -> 6, ioncore_winprops.lua Lua 5.5 fix

Added notion3-ioncore-winprops-lua55-hole-border.patch: ifnil()’s vararg-counting helper used #arg, but #’s result on a table with holes (a nil first argument – the common case for id.role/id.instance) is unspecified by the language and silently changed between Lua 5.4 and 5.5, collapsing the loop bound to 0. Fixed with select('#', ...), which is well-defined regardless of holes. Test build succeeded, then built, signed, and published to x86_64 (i486 hit the same pre-existing, unrelated texlive-family chroot collision as always). Overview and site regenerated/republished.

private/notion3: rebuild and republish (x86_64), pkgrel 5 (no change)

Rebuilt and republished on request; no PKGBUILD changes needed since the 2026-07-15 pkgrel 4 -> 5 fix (libtu C99 + Lua 5.5 mkman patches) – still builds clean at pkgrel 5. i486 failed again in the same pre-existing way (texlive-bin vs texlive-basic/dvisvgm/texlive-context file collisions, unrelated to notion3 itself); x86_64 built, signed, and published (notion3 + notion3-debug). Overview and site regenerated/republished.

maintained/webkit2gtk: 2.50.6-7 -> 2.50.6-8 (packaging fix, cmake >=4 build failure)

Followed up on the 2026-07-23 AUR build-failure report. extra/cmake moved to 4.4.0 in our own chroot on 2026-07-21, which reproduced the same failure locally for the first time (CMake Error at Source/cmake/WebKitMacros.cmake:311) – so it wasn’t reporter-specific after all, just a matter of our chroot catching up to a newer cmake.

Root cause: upstream WebKit’s _WEBKIT_TARGET_LINK_FRAMEWORK macro compares an unquoted ${_linked_into} variable that is legitimately empty the first time it’s evaluated (a real macro-ordering/bootstrap situation involving LLIntSettingsExtractor linking WTF before JavaScriptCore’s own framework setup runs). An unquoted empty variable vanishes as a token inside if() instead of becoming an empty string, and cmake >=4 rejects the resulting malformed argument list outright. Checked WebKit upstream main and official Arch’s webkit2gtk-4.1 PKGBUILD – neither has a fix yet (the latter simply hasn’t rebuilt since cmake 4.4.0 landed), so this is a packaging-side fix, not something to pull in from elsewhere.

Fix shipped as a standalone patch file cmake4-linked-into-quoting.patch (quotes the two culprit variable expansions), applied via patch -Np1 in prepare() – not an inline sed, so the patch stays reusable by other distros packaging the same upstream source (new standing preference, see this project’s tooling memory). Packaging-only fix, so pkgrel bumped to 8, pkgver unchanged. Verified: cmake configure now completes (build.ninja generated) and the full build finished cleanly; namcap only flagged pre-existing license/dependency lint issues, unrelated to this change. Built, signed, and published (webkit2gtk, webkit2gtk-debug, webkit2gtk-docs); old 2.50.6-7 files archived. OVERVIEW.md and site regenerated and republished. Notes in memory/webkit2gtk.md.

Updates — 2026-07-23

Ran a full scripts/update_cycle.sh pass (cleanup_all.sh, fetch_ff_maintained.sh, check_for_updates_maintained.sh -> STATES.txt) plus scripts/check_aur_feedback.sh (-> FEEDBACK.txt). All 233 submodules fetched clean (no diverged/dirty cases). 0 packages flagged UPD – nothing needed a version bump this round. No new FLAG/UNFLAGGED/MISSING out-of-date-flag changes either.

AUR feedback scan turned up one new comment: webkit2gtk (2.50.6-7) got a build-failure report (CMake error in WebKitMacros.cmake at the _WEBKIT_TARGET_LINK_FRAMEWORK macro). Our own build of the same pkgver/pkgrel still succeeds locally and is already published (OVERVIEW.md: SAME), so this looks like a cmake-version difference on the reporter’s side rather than a packaging bug – not reproduced, no PKGBUILD change made. Notes in memory/webkit2gtk.md. Nothing else to build/publish this round, so no overview/site regen was needed (state unchanged from last publish).

Updates — 2026-07-22

Ran a full scripts/update_cycle.sh pass (cleanup_all.sh, fetch_ff_maintained.sh, check_for_updates_maintained.sh -> STATES.txt) plus scripts/check_aur_feedback.sh (-> FEEDBACK.txt). 1 package flagged UPD; AUR feedback scan reported nothing new besides pdfalto’s out-of-date flag clearing (from the 2026-07-20 fix).

maintained/thunderbird-esr-bin: 140.12.1-1 -> 140.13.0-1

• Bumped pkgver to 140.13.0, regenerated sha512sums with updpkgsums, regenerated .SRCINFO.
• Checked FEEDBACK.txt for this package (per updated workflow — check AUR comments for every touched package, not just UPD-flagged ones) and found three related comments (2025-12-17 to 2026-07-21) about the taskbar/icon not showing correctly under GNOME/Wayland. Applied the user-confirmed fix: added StartupWMClass=thunderbird-esr to thunderbird-esr-bin.desktop.
• Test-built and released to the private repo (x86_64 only this pass).
• Notes saved to memory/thunderbird-esr-bin.md.
• Overview/site regenerated and republished after this build.

maintained/riscv32-elf-gcc + maintained/riscv32-elf-newlib: circular-dependency fix

• Long-standing mutual build-dependency cycle (riscv32-elf-gcc <-> riscv32-elf-newlib, open since 2026-07-07) resolved – no PKGBUILD changes. riscv32-elf-gcc’s existing PKGBUILD.bootstrap (a stage-1, libc-free compiler that provides/conflicts the real package) breaks the cycle when built/published first, then riscv32-elf-newlib, then the real riscv32-elf-gcc.
• riscv32-elf-binutils (hard depends= of both gcc variants) turned out to be an official extra repo package, not AUR – nothing to build or maintain there.
• Found matching, already-built .pkg.tar.zst artifacts for all three (bootstrap/newlib/full-gcc) in /data/INSTALL from a manual 2026-01-25 bootstrap run; diffed their PKGBUILDs against the current tree (byte-identical) and published those directly via repo_sign.sh/ repo_publish.sh in bootstrap -> newlib -> gcc order, instead of rebuilding.
• All three now resolve cleanly in the private repo. Notes in memory/riscv32-elf-gcc.md.
• Overview/site regenerated and republished after this publish.

Updates — 2026-07-20

Ran scripts/check_for_updates_maintained.sh (output saved to STATES.txt). 2 packages flagged UPD.

maintained/check_ssl_cert: 2.101.0-1 -> 2.103.0-1

• Bumped pkgver to 2.103.0 (pkgrel reset to 1), regenerated md5sums with updpkgsums, regenerated .SRCINFO.
• Test-built successfully for x86_64, i686, pentium4 (the other archs in arch=() — armv6h/armv7h/aarch64 — aren’t buildable on this host).
• Released to the private repo (x86_64, i686, pentium4); old x86_64 build archived.
• Notes saved to memory/check_ssl_cert.md.

maintained/libkcompactdisc: false-positive UPD (25.12.3 -> reported “52”)

• The ?-less UPD was a bogus nvchecker read — the .nvchecker.toml scrapes the KDE GitLab tags page via regex, which returned an implausible version “52” on this run. Re-running nvchecker -c .nvchecker.toml standalone immediately after correctly reported 25.12.3, matching the installed pkgver. No update needed; no changes made.
• Notes saved to memory/libkcompactdisc.md.

Updates — 2026-07-02

Ran scripts/check_for_updates_maintained.sh (output saved to STATES.txt). 2 packages flagged UPD. Additionally, STATES.stderr (nvchecker output for pacman-static’s and libarchive-static’s bundled third-party dependencies, which the OK/UPD/? table doesn’t cover) flagged 3 outdated bundled deps in pacman-static.

maintained/libarchive-static: 3.8.7-3 -> 3.8.8-1

• Bumped pkgver to 3.8.8 (pkgrel reset to 1), regenerated sha512sums with updpkgsums (only the libarchive git-tag source hash changed — bundled deps attr/acl/openssl/zlib/xz/bzip2/zstd are unchanged versions), regenerated .SRCINFO.
• Test-built successfully for all buildable architectures: x86_64, i686, pentium4, i486.
• Notes for next time saved to memory/libarchive-static.md.

maintained/pacman-static: bundled deps updated (pkgrel 12 -> 13)

• STATES.stderr showed curl, gpgme, and libarchive (bundled static deps, tracked via nvchecker-deps.toml against current Arch package versions) were behind: curl 8.20.0->8.21.0, gpgme 2.1.0->2.1.2, libarchive 3.8.7->3.8.8. pkgver itself (pacman’s own version) is unaffected — bumped pkgrel 12 -> 13, refreshed sha512sums with updpkgsums and .SRCINFO.
• Test-built successfully for x86_64, i686, pentium4, i486.
• Synced nvchecker-new.txt -> nvchecker-old.txt so the next run doesn’t re-report these as new.
• Notes for next time saved to memory/pacman-static.md.

maintained/linux-lts515: 5.15.209 -> 5.15.210 — SKIPPED

• nvchecker reports 5.15.210 available (git tag exists on kernel.org’s linux-5.15.y branch), but the corresponding release tarball (linux-5.15.210.tar.xz) has not been published on cdn.kernel.org yet (confirmed via makepkg -do, real 404, not a sandboxing artifact). Reverted the pkgver bump; left the package at 5.15.209. Retry later.
• Retried same day: reran check_for_updates_maintained.sh (fresh STATES.txt/STATES.stderr), still only linux-lts515 flagged UPD. Bumped pkgver to 5.15.210 again and re-checked with makepkg -do --skippgpcheck (unsandboxed) — still a 404, tarball still not published. Reverted pkgver back to 5.15.209, no diff left behind.
• Notes saved to memory/linux-lts515.md.

Other findings

• Fixed an unrelated encoding regression: editing libarchive-static’s PKGBUILD caused a pre-existing invalid-UTF-8 byte sequence in a maintainer comment (# Tomáš Mráz) to get further corrupted into U+FFFD replacement characters by the edit tooling. Restored the original bytes to match the last git revision exactly; see memory/TOOLING_NOTES.md.

Updates — 2026-07-04

Fetched+fast-forwarded all maintained/ submodules (230 of them; none were behind their remote tip). Ran scripts/check_for_updates_maintained.sh. Only linux-lts515 flagged UPD.

maintained/linux-lts515: 5.15.210 -> 5.15.211 — SKIPPED

• Same pattern as 2026-07-02/03: nvchecker’s git-tag tracking reported 5.15.211, but the release tarball isn’t published on cdn.kernel.org yet (confirmed genuine 404 via update.sh, which uses makepkg -do internally per [[feedback-network-debugging]]). Script auto-reverted the pkgver bump; package stays at 5.15.210. Retry later.
• Fixed a small gap in update.sh: its 404 early-exit path cleaned up the downloaded tarball but left an empty src/ dir behind — now removes it too.
• Notes updated in memory/linux-lts515.md.

Private-repo build-all-packages pass — 2026-07-07/08

Ran scripts/update_cycle.sh first (208/230 maintained/ submodules fast-forwarded; 22 hit transient SSH resets from the AUR host, harmless; 0 dirty/diverged). Only qtkeychain-qt5 needed a version bump (0.16.0 -> 0.17.0), done and published as the pipeline smoke test.

Then built, signed, and published every package under arch/ (maintained/private/adapted/owned, excluding attic/) to the private archlinuxaba repo on euroweb.lan, restricted to x86_64 for now, per explicit scope decisions (see memory/private_repo_publish_scope.md in auto-memory).

Results

• 250 packages attempted (0 skipped — every package’s arch=() either included x86_64 or was any/empty).
• 155 published successfully (138 on the first full pass, plus 17 more recovered via manual retries after fixing the bugs described below: c2t-git, diskm8-git, dos33fsprogs-git, dsk2nib-git, arduino-builder, libarchive-static, pacman-static, pgfuse, sqlitexx, vattery, xdialog, z80ex, xawtv, xxdiff-git, x86_64-elf-binutils, vhd2vl-git, e1000e-dkms-lts515).
• 4 fixed but not yet rebuilt/republished: libcurlpp-git, llvm-mos-git, pcmanfm-gtk3, prodos-utilities-git (same trivial missing-git-in-makedepends bug as the ones above, already corrected in their PKGBUILDs + .SRCINFO, just not queued through a build yet).
• ~91 still failing, one memory/<package>.md note per package with the specific cause. Rough breakdown (some packages fall into more than one bucket transitively):
  • ~14 are intra-tree forward-reference ordering — depend on another package from this same tree that hadn’t been built+published yet at the point this single top-to-bottom alphabetical pass reached them (now available; should resolve on a future retry pass without any code change). E.g. kplotting5, kunitconversion5, plasma-framework5, prison5, fvwm, gcc-ia16, hq, i686-elf-pcc-git, pcc-git, python-pyqt5-chart, python-pyqt5-purchasing, qgpgme1-qt5.
  • ~15 depend on a real package that isn’t tracked anywhere in this arch/ tree at all (not official-Arch-anymore, or genuinely AUR-only, e.g. qt4, cc65, gcc14, gtk-sharp-2, python2’s own openssl-1.1 chain, qt5-webengine, qt5-webkit, Perl/Apache modules for thruk) — out of scope for a build+publish pass per the user’s guidance; just recorded for a future decision.
  • The rest are genuine, distinct build/source defects — real compiler errors (old code vs modern GCC strictness, e.g. leafpad, modest, newsboat-og, xfractint, gsoap287, notion3, optdb5.3), missing/stale local patch files (gcc47, linux-lts510), a stale source checksum (trojita, pce-git), missing GPG keys (pcmciautils), a CMake-version-policy incompatibility (kdiagram5), a circular cross-toolchain bootstrap dependency (riscv32-elf-gcc <-> riscv32-elf-newlib), and a few transient network blips (gpgme-1, elasticsearch6, wildfly22, vattery before its retry). See each package’s own memory/<name>.md for specifics.

Script/tooling fixes made along the way

• repo_publish.sh: added repo-remove before repo-add and archiving of superseded package files to a new ${REPOSITORY_REMOTE_PATH}/archive/ dir (append-only — see memory/ARCHIVE_APPEND_ONLY.md); fixed a pre-existing _repo_add typo bug in the arch=any symlink fan-out.
• repo_lib.sh: ssh -n on every remote call, and REPO_LIB_DIR resolved to an absolute path — both fix real bugs (ssh silently draining a driver loop’s stdin after one package; a relative path breaking once repo_build.sh cds into a package directory).
• repo_build.sh: build-byproduct cleanup rewritten to be git status-driven instead of a fixed glob list (catches arbitrary VCS-cloned source dirs); added REPO_BUILD_ONLY_ARCH and a _build_cmd per-arch dispatcher.
• New scripts/archlinuxaba-archbuild (+ archlinuxaba-x86_64-build symlink): a copy of the system archbuild that adds this project’s own private repo into the chroot’s pacman.conf (arch/config/pacman.conf.d/archlinuxaba.conf), so a package already published earlier in a run resolves as a dependency for one built later in the same run. Wired into repo_build.sh for x86_64 only.
• repo_release.sh: now collects every valid package extension (.gz/.bz2/.xz/.zst/.lz), not just .zst (libarchive-static/ pacman-static build .xz); post-publish, removes the local *.pkg.tar.*/.sig so a released package directory doesn’t stay dirty. Also fixed a real oksh bug along the way: a set -A array with zero elements ever assigned makes oksh treat any later reference to it as unset under set -u — replaced with a plain space-separated string (see memory/oksh_coding_style.md in auto-memory and memory/TOOLING_NOTES.md).
• Two trivial PKGBUILD fixes applied to several -git packages that were missing git in makedepends (adtpro-git, c2t-git, diskm8-git, dos33fsprogs-git, dsk2nib-git, libcurlpp-git, llvm-mos-git, pcmanfm-gtk3, prodos-utilities-git) — pkgrel bumped, not pkgver (see memory/PKGREL_VS_PKGVER.md).

Not done in this pass

• A second retry pass specifically for the ~14 forward-reference packages (task tracked, not run yet).
• Rebuilding the 4 fixed-but-not-rebuilt packages listed above.
• Any of the ~15 out-of-tree-dependency or ~60 genuine-defect packages — each needs its own investigation/decision, recorded per-package in memory/.
• i686/pentium4/i486 builds — this pass was x86_64-only per explicit scope.

Update check + changed-only publish cycle — 2026-07-09

Ran scripts/update_cycle.sh (cleanup + fetch/fast-forward + version check). Fresh STATES.txt/STATES.stderr: 0 packages flagged UPD (nothing needs a version bump this cycle), 112 OK, 79 ? (no .nvchecker.toml — see below).

NVCHECKER.md

Per request, investigated all 79 ?-flagged packages and wrote /home/build/aurupdater/NVCHECKER.md: a planning doc (no .nvchecker.toml files created) grouping them by upstream-hosting pattern — KDE Frameworks5/PIM/Plasma5 families (21 packages, share a gitlab+host=invent.kde.org pattern), plain GitHub/GitLab tag packages, a Launchpad group, a SourceForge group (nvchecker has no native sourceforge source — documented the RSS-regex workaround, verified live), a “Laborejo Software Suite” family (5 packages, one shared directory, verified live), and 13 packages judged genuinely dead/frozen with no viable automatic check (autoconf2.13, python2, boost-65-compat, etc.). Ends with a prioritized quick-wins list.

Changed-only build/publish (per explicit instruction: don’t rebuild

the full tree, only what actually changed)

Wrote two new scripts:

• scripts/repo_diff_local_remote.sh — compares every local package’s real version (makepkg --printsrcinfo, so split packages/ epochs/array pkgnames are handled correctly) against what’s actually published on the repo host, and reports NEW/CHANGED/SAME. Remote packages with no local counterpart (other AUR packages published by hand, outside this tree) are silently ignored, per instruction. VCS (-git) packages get a -VCS-suffixed verdict instead of a plain one, since their static pkgver only reflects whatever a previous build’s pkgver() last computed (and cleanup_all.sh’s git-checkout reset can revert that between sessions without touching what’s already published) — not a live “did upstream move” signal.
• scripts/repo_release_changed.sh — runs repo_diff_local_remote.sh and builds/signs/publishes only the plain NEW/CHANGED (non-VCS) results, same PASS/FAIL/per-package-logfile discipline as repo_release_all.sh.

Diff found 82 NEW + 1 CHANGED non-VCS packages (plus 10 NEW-VCS / 11 CHANGED-VCS -git packages, intentionally left out of the automated build — see script header) against 142 already-published/unchanged. Collapsing split-package name duplicates, that’s 79 package directories run through repo_release_changed.sh.

Results

• Initial pass: 26 PASS / 53 FAIL.
• +7 more via targeted retries — a chunk of the 53 failures were purely this run’s own build-order artifact: packages that depend on a sibling also in this batch, but alphabetically later, so the dependency wasn’t published yet when pacman went looking for it inside the chroot. Retried in dependency order once their deps were confirmed published: kpimtextedit5 (needed ktextaddons5), kirigami-addons5 (needed kitemmodels5), cervisia (needed kdesu5), kcontacts5 (transient checksum error, succeeded on retry), akonadi-contacts5 (needed libakonadi5/kcontacts5/prison5), kidentitymanagement5 (needed kpimtextedit5, itself just-fixed) — all now published.
• 2 more fixed via a real (if trivial) PKGBUILD bug: maintained/woz2dsk and maintained/wozzle both declared makedepends=() despite using a git+ VCS source, so the chroot had no git to clone with (Cannot find the git package needed to handle git sources) — same class of bug as the 2026-07-07/08 pass. Added makedepends=('git'), bumped pkgrel (not pkgver, per memory/feedback_pkgrel_vs_pkgver.md). wozzle rebuilt and published clean (makepkg’s own pkgver() picked up a newer upstream commit in the process, resetting pkgrel back to 1, as expected). woz2dsk still fails, now for an unrelated reason (see below) — fix confirmed correct, just not sufficient on its own.
• Net: 35 published this cycle, 44 still failing.

Remaining 44 failures — categorized, not individually fixed

This is well beyond the scope of a “publish what changed” pass — each needs its own investigation. Grouped by cause so it’s triageable later:

• Missing/unavailable dependency, not in official repos or this repo (17): p2c (gcc14), bless (gtk-sharp-2), boost-65-compat (python312), dbmodel-qt4 (qt4>=4.0), kchmviewer/qmc2/qt5-webview (qt5-webengine), kcm-fcitx (fcitx-qt5), libkolabxml (libxsd), lxappearance-obconf-gtk3 (lxappearance-gtk3), mp3splt-gtk (libaudclient>=3), ogmrip (gconf), passport (exomizer), pdfalto (libpng14), perl-cookie-baker (perl-test-time), python-postfix-policyd-spf (python-pyspf), python-pyqt5-3d (qt5-3d), python-pyqt5-datavisualization (qt5-datavis3d), qt5-webglplugin (qt5-websockets), thruk (mod_fcgid), woz2dsk (perl-digest-crc/perl-file-slurp — the git fix above got it past its original failure, this is a new, separate one), yabause-qt5 (cmake3). Each of these needs a decision: build the dependency into this tree too, or accept the package can’t be built here.
• Cascading from another failed package in this same batch (3): obexftp/qgpgme1-qt5 (need openobex/gpgme-1, both themselves failing for real reasons below), kjots (needs akonadi-notes, real C++ error below).
• Circular cross-toolchain bootstrap dependency (2): riscv32-elf-gcc <-> riscv32-elf-newlib — each needs the other; needs a proper staged-bootstrap build order, not a simple retry.
• Genuine compiler/source errors (16): cyrus-imapd2 (clang misconfigured as the C compiler in the chroot — “C compiler cannot create executables”), gcc47/linux-lts510 (a local patch file referenced in source=() is missing from the package dir), openssl-1.1 (enable-ktls no longer a supported Configure option), corral (Pony compiler: “match is exhaustive, else clause unreachable” — Pony version mismatch), cppcms (pacman dependency-resolution prompt blocking non-interactively), akonadi-notes (KMime::Message::subject (bool) — API mismatch against the currently-built kmime5), kdiagram5, newsboat-og (-Werror=unused-but-set-variable), xfractint (too many arguments to function 'this->change'), gsoap287 (X509_EXTENSION incomplete type — OpenSSL ABI break), notion3/optdb5.3 (incompatible function-pointer types — modern GCC strictness vs old C code), openobex, trojita (“Could not download sources”).
• Dead/unreachable upstream (2): pcmciautils (“Could not download sources”, matches NVCHECKER.md’s dead-projects list), archlinux32-keyring (“Could not download sources”).
• Transient network (2, likely fine on a plain retry later): gpgme-1 (dev.gnupg.org returned HTTP 429 — rate-limited), elasticsearch6 (curl 404 on the download URL — may be genuinely moved, not just transient; worth a quick check first).

None of the above 44 were modified — flagged for a future, deliberately scoped pass per package rather than guessed at in bulk.

Full check + changed-only publish cycle — 2026-07-13

Ran scripts/update_cycle.sh (cleanup + fetch/fast-forward + version check). Fresh STATES.txt/STATES.stderr: 0 packages flagged UPD, 112 OK, 79 ? (unchanged from 2026-07-09).

Ran scripts/repo_diff_local_remote.sh: 49 NEW + 11 CHANGED-VCS + 10 NEW-VCS against the rest already published/unchanged. Ran scripts/repo_release_changed.sh (builds only the plain NEW/CHANGED, skips -VCS per its own design) against the 46 distinct package dirs in that set: 0 PASS / 46 FAIL on the first pass — this is a pre-existing backlog of packages that have apparently never successfully published, not a regression from this session. Full logs in repo_release_logs/.

Per explicit scope decision, only picked off the “quick win” (transient/mechanical) failures rather than the whole backlog:

Fixed and republished (3)

• private/archlinux32-keyring: validpgpkeys only listed the old signing key (DE9F7688...); the current release tarball is signed with a newer key (33CA3597...) that gpg --recv-keys already had locally, it just wasn’t trusted by validpgpkeys nor exported to keys/pgp/. Added the new fingerprint alongside the old one, exported it properly to keys/pgp/33CA3597....asc (a stray same-named file without the .asc extension already sitting in that dir, presumably from a prior manual gpg --export, got cleaned up in the process), regenerated .SRCINFO. pkgrel 1.0 -> 1.1 (packaging-only fix, not a new upstream version). Rebuilt/published clean.
• maintained/pcmciautils: signing key (DD46DC35691C79509D15F58CFEF39108F6FD2C20, already correctly listed in validpgpkeys) had just never actually been fetched — no keys/pgp/ dir existed at all for this package. Ran the (now-fixed, see below) update_pgp_key_dir.sh to fetch and export it. No PKGBUILD change needed. Rebuilt/published clean.
• private/elasticsearch6: bundled log4j 2.17.0 source URL (dlcdn.apache.org) 404’d — Apache only serves the current release off dlcdn; older versions moved to archive.apache.org. Repointed the URL, bumped pkgrel 1 -> 2. Rebuilt/published clean.

Script fix

• scripts/update_pgp_key_dir.sh: . PKGBUILD (no ./) silently failed with “file not found” — bash’s . builtin only searches $PATH for a bare filename, and $PATH doesn’t include .. This meant the script had never actually worked as written; likely why pcmciautils’s keys/pgp/ was empty and archlinux32-keyring’s had a stray malformed entry from someone working around it by hand. Fixed to . ./PKGBUILD, and added a mkdir -p keys/pgp so it works on a package that’s never had the directory at all.

Left alone (per scope decision — not quick/mechanical)

• maintained/gpgme-1: still HTTP 429 from dev.gnupg.org on retry (checked twice, ~15 min apart) — genuinely transient, retry on a later cycle. qgpgme1-qt5 cascades from this, untouched too.
• adapted/linux-lts510, adapted/gcc47: confirmed via git log that the last commit to each added a source=() reference to a local patch file (0004-depmod-remove-depmod_hack_needed.patch, gcc.texi.49.patch) without ever adding the patch content itself — not a download failure, the file was simply never committed. Needs the actual patch regenerated/sourced, not a mechanical fix; the OBS project referenced in a linux-lts510 PKGBUILD comment returned 403.
• Everything else in the original 46-failure categorization (missing out-of-tree deps, the riscv32-elf-gcc/riscv32-elf-newlib circular bootstrap, genuine compiler/API-drift errors) — unchanged from the categorization done during triage, still needs its own scoped pass.

Targeted fix — 2026-07-15

private/optdb5.3: build failure fixed (pkgrel 5 -> 6)

• Previously flagged in the 2026-07-07/08 pass’s “genuine compiler/source errors” bucket alongside notion3: “incompatible function-pointer types — modern GCC strictness vs old C code”. Root cause: gcc 16.1.1 now errors (not just warns) on -Wincompatible-pointer-types by default, and this 2015-era Berkeley DB source (src/env/env_config.c) declares its dispatch tables with old K&R-style unprototyped function pointers (int (*func)();), which the compiler now treats as int (*)(void) and rejects when initialized with the real, typed function pointers (__env_add_data_dir etc.). Same underlying GCC-version-vs-legacy-code class of problem as the pre-existing -Wno-error=implicit-function-declaration already in the PKGBUILD, just a different warning class.
• Fix: added -Wno-error=incompatible-pointer-types alongside the existing -Wno-error=implicit-function-declaration in build()’s CFLAGS. Packaging-only fix (no source/version change), so bumped pkgrel 5 -> 6 per memory/feedback_pkgrel_vs_pkgver.md, not pkgver.
• Test-built clean with extra-x86_64-build (0 compiler errors in the fresh build log; both optdb5.3 and optdb5.3-debug packages produced). Remaining namcap warnings (RUNPATH, non-SPDX custom:sleepycat license, ELF outside /opt) are pre-existing and expected for this legacy /opt-installed package, unrelated to the fix. Not yet published to the private repo — build verification only, per this task’s scope.

private/gsoap287: build failure fixed (pkgrel 4 -> 5)

• Previously flagged in the 2026-07-07/08 pass’s “genuine compiler/source errors” bucket: “X509_EXTENSION incomplete type — OpenSSL ABI break”. Two distinct problems, both in the single real source file gsoap/stdsoap2.cpp (built three times under different symlinked names — stdsoap2.c, stdsoap2_ssl.c, stdsoap2_ssl_cpp.cpp — per Makefile.am, so one patch covers all variants):
  1. tcp_connect()’s certificate subjectAltName check reached directly into X509_EXTENSION’s internal fields (ext->value->data, ext->value->length) and called the long-removed M_ASN1_STRING_data() macro. X509_EXTENSION became an opaque type in OpenSSL 1.1+ and M_ASN1_STRING_data was dropped, so modern OpenSSL 3.x headers reject both outright.
  2. Once past that, soapcpp2 (the bundled bison/flex-generated WSDL parser-generator tool built and run as part of the build itself) failed at link time with “multiple definition of yylval” — the generated parser/lexer both carry a tentative definition of yylval, which old GCC silently merged via common symbols but GCC 10+’s -fno-common default now rejects.
• Fix:
  1. New patch gsoap-2.8.7-openssl3.patch (added to source=(), applied in a new prepare()): replaces the direct struct-field reads with X509_EXTENSION_get_data() / ASN1_STRING_get0_data() / ASN1_STRING_length(), and replaces M_ASN1_STRING_data() with ASN1_STRING_get0_data().
  2. Added -fcommon to build()’s CFLAGS to restore pre-GCC10 tentative-definition merging for the bundled parser generator.
• Packaging-only fix (no source/version change), so bumped pkgrel 4 -> 5 per memory/feedback_pkgrel_vs_pkgver.md, not pkgver. Regenerated .SRCINFO and checksums (updpkgsums).
• Test-built clean with extra-x86_64-build (0 compiler errors; both gsoap287 and gsoap287-debug packages produced). Not yet published to the private repo — build verification only, per this task’s scope.

private/notion3: build failure fixed (pkgrel 4 -> 5)

• Previously flagged in the 2026-07-07/08 pass’s “genuine compiler/source errors” bucket alongside optdb5.3: “incompatible function-pointer types — modern GCC strictness vs old C code”. Two independent bugs surfaced in sequence (both real, pre-existing defects, not just GCC-version friction — see below):
  1. Genuine upstream typo, not just a compiler-version issue: libtu/Makefile sets CFLAGS += $(C98_SOURCE) ..., but every other module’s Makefile in the tree correctly uses $(C99_SOURCE) — C98_SOURCE is never defined anywhere, so it silently expanded to nothing and libtu (which includes obj.c) has always built without -std=c99. Old GCC’s default standard happened to still tolerate calling through libtu’s unprototyped function-pointer tables (e.g. destroy_fn in obj.c) with arguments; GCC’s new default standard (gnu23) correctly rejects it as a real too-many-arguments error. Fixing the C98->C99 typo (one-line patch, notion-libtu-c99.patch) restores the project’s own intended, already-correct-elsewhere build flag and the C99 semantics the rest of the tree already relies on.
  2. Once past that, the C build succeeded fully but the man-page generator (build/mkman.lua, run at build time via the system lua, now 5.5.0) failed: attempt to assign to const variable 'l' — the script reassigns a generic-for loop control variable, which newer Lua now rejects. Fixed by using a separate local (ln) instead (notion-mkman-lua54.patch).
• Both patches added to source=(), applied via prepare(). Packaging-only fix (no source/version change — patches only, upstream _commit/_commit_doc unchanged), so bumped pkgrel 4 -> 5 per memory/feedback_pkgrel_vs_pkgver.md, not pkgver. Regenerated .SRCINFO; kept the two git+ sources’ checksums as SKIP (already pinned by commit) even though updpkgsums tried to hash them — reverted those two entries back to SKIP and kept real sha256sums only for the two new static patch files.
• Test-built clean with extra-x86_64-build (0 compiler errors; both notion3 and notion3-debug packages produced). One unrelated, pre-existing makepkg warning noted but left alone (out of scope): backup=() lists etc/notion/cfg_bindings.lua, a file that doesn’t exist anywhere in the upstream source tree — a stale entry, not a build failure. Not yet published to the private repo — build verification only, per this task’s scope.

optdb5.3 and notion3: published (x86_64)

• Built, signed, and published both to the private archlinuxaba repo (x86_64): optdb5.3 5.3.28-6, notion3 20190501-5.
• notion3’s full repo_release.sh run (which builds every arch in its arch=()) hit an unrelated, pre-existing failure on i486: a pacman file conflict between texlive-bin and texlive-basic/dvisvgm/texlive-context in that chroot — nothing to do with this session’s C/Lua fixes. Under the old scripts/repo_build.sh logic that single-arch failure aborted the whole release before signing/publishing anything, even the x86_64 build that had already succeeded. Worked around by signing/publishing the already-built x86_64 packages directly (repo_sign.sh/repo_publish.sh), then cleaning up the local *.pkg.tar.zst/.sig the same way repo_release.sh would have.
• Fixed the actual bug behind that, per explicit request: changed scripts/repo_build.sh so a failing arch no longer blocks signing/publishing the archs that did succeed — it now only exits nonzero if no arch built at all (matching what its own header comment already claimed the behavior was); a partial failure now just prints a WARNING (still visible in the caller’s log) instead of aborting the release. See the script’s own new comment for the reasoning.
• OVERVIEW.md and site/*.html regenerated afterward (generate_overview.sh + generate_site.sh); both packages now show SAME (published, matches local).

adapted/p2c: build failure fixed (pkgrel 1 -> 2)

• Was in the “missing/unavailable dependency” bucket from the 2026-07-09 triage (p2c (gcc14)) — makedepends=('gcc14'), but gcc14 isn’t tracked anywhere in this arch/ tree nor available in any configured repo, so the chroot build could never even start. Investigated instead of just sourcing the missing package: extracted the source, applied the existing patches by hand, and tried compiling with the current system gcc (16.1.1) directly. Real error: parse.c declares a local Stmt *(*prochandler)(); — an old K&R-style unprototyped function pointer, cast from mp->handler and then called with 2 arguments — which compiles fine under the “unspecified parameters” semantics GCC used to default to, but is a hard error under GCC’s newer default standard (gnu23, where an empty () means (void)). This is exactly why gcc14 (the last version before that default changed) had been pinned. Same root-cause class as notion3’s obj.c issue, just discovered by testing directly rather than via a patch.
• Fix: dropped makedepends=('gcc14') entirely (makedepends=()) and changed both build() invocations from CC='gcc-14' to CC='gcc' OPT='-O2 -s -std=gnu17' — forcing the older C standard restores the semantics the code was written for, without needing the specific old compiler package. Packaging-only fix, pkgrel 1 -> 2 per memory/feedback_pkgrel_vs_pkgver.md. No .SRCINFO exists for this package (pre-existing, unrelated to this fix).
• Test-built clean with extra-x86_64-build (0 compiler errors; both p2c and p2c-debug packages produced). Not yet published — build verification only, per this task’s scope.

adapted/cyrus-imapd2: build failure fixed (pkgrel 2.0 -> 2.1)

• Was in the 2026-07-13 triage’s “genuine compiler/source errors” bucket: “clang misconfigured as the C compiler in the chroot – ‘C compiler cannot create executables’”. build() hardcoded CC=clang, but clang was never declared in makedepends (there was no makedepends array at all), so a clean chroot without clang installed by coincidence can’t even run configure.
• Investigated why clang was pinned in the first place rather than just adding it as a dependency: extracted the source, applied the two existing patches, and tried configure+make directly with plain gcc (16.1.1). configure succeeded outright; make hit one real error: imap/mailbox.c calls mboxlist_findall() passing chkchildren (a real int (*)(char *, int, int, void *)) as its callback argument, but imap/mboxlist.h:208 declares that parameter as an old K&R-style unprototyped int (*proc)() — clang has always tolerated calling that with real arguments, but current GCC’s default standard (gnu23) now rejects it as a hard incompatible-pointer-types error. Same root-cause class as notion3/p2c’s issues this session, and almost certainly the actual reason clang was chosen years ago (undocumented in the PKGBUILD) — just never declared as a build dependency, so it broke silently the moment a chroot didn’t happen to already have clang.
• Fix: dropped CC=clang in favor of CC=gcc plus -std=gnu17 in CFLAGS, restoring the semantics the code needs without adding a clang build dependency. Verified both the plain ./configure ... && make sequence (matching build() exactly, CFLAGS only passed at configure time) and a full clean chroot build. Packaging-only fix, pkgrel 2.0 -> 2.1 (matches this project’s existing decimal-pkgrel convention, see archlinux32-keyring’s 1.0 -> 1.1 in the 2026-07-13 entry above) per memory/feedback_pkgrel_vs_pkgver.md.
• Test-built clean with extra-x86_64-build (0 compiler errors; both cyrus-imapd and cyrus-imapd-debug packages produced). One unrelated, pre-existing makepkg warning noted but left alone (out of scope): “Package contains reference to $srcdir” — a baked-in build-time path in some installed file, not a build failure. Not yet published — build verification only, per this task’s scope.

maintained/corral: build failure fixed and published (pkgrel 1 -> 2)

• Flagged in the 2026-07-07 triage: ponyc fails compiling corral/semver/version/compare_versions.pony:32, “match is exhaustive, the else clause is unreachable” — a defensive else arm, added years ago to satisfy an older ponyc that didn’t do exhaustive tuple-pattern checking, is now a hard error under current ponyc.
• Checked upstream (ponylang/corral on GitHub) before writing a local patch: this exact fix already landed on main in commit 10b85e36e5c7ec4503ecb80ff51aa2342e459805 (“Switch all CI jobs to ponyc nightly (#300)”), just not in a tagged release yet (0.9.2 from 2019 is still the latest tag).
• Fix: added that upstream commit’s .patch URL directly as a source=() entry (no hand-authored local patch file). The full commit patch also retargets CI workflow files that have drifted since the 2019 tag and doesn’t apply cleanly as one blob with plain patch -Np1, so prepare() uses git init -q && git apply --include='corral/semver/version/compare_versions.pony' -p1 ... to scope application to just the relevant source file, then discards the throwaway .git. Packaging-only fix, pkgrel 1 -> 2 (plain integer bump — maintained/, not adapted/).
• Test-built clean with archlinuxaba-x86_64-build (0 compile errors; corral/corral-debug produced). Signed and published to the private repo (x86_64). Details in memory/corral.md.

maintained/newsboat-og: two build failures fixed and published (pkgrel 3 -> 4)

• This is the maintainer’s own upstream fork (andreasbaumann/newsboat-og). Maintainer fixed the json-c build problem upstream as commit d11e3705b53cc219a47c7d6790faea841153d6c1 and asked for it to be wired into the PKGBUILD the same way as the existing f2b404c3... patch (a source=() entry pointing at the commit’s .patch URL). Added it, plus discovered and fixed (also via an upstream-commit patch, at the maintainer’s direction) a second, unrelated pre-existing failure on x86_64 specifically: src/htmlrenderer.cpp’s image_count variable is set but never read (-Werror=unused-but-set-variable) — dead code, already flagged in the 2026-07-07 triage. Fixed via commit ae260fcecc786ab07fd37df00105d410726883bc. Also added, per explicit request (not required to fix a build error): commit 1ab71d889a38a4b3d8251da7c955d1ac1f362215, updating the bundled vendor header 3rd-party/json.hpp (nlohmann JSON, used by the TT-RSS API backend) from 3.2.0 to 3.11.3.
• All four patches are source=() URL entries pointing at andreasbaumann/newsboat-og commits, applied in prepare() via plain patch -Np1 — no hand-authored local patches. Packaging-only fix, pkgrel 3 -> 4 (plain integer bump — maintained/).
• Test-built clean across all four supported arches (x86_64, i486, i686, pentium4) via scripts/repo_build.sh. Signed and published all 8 resulting package files (newsboat-og + newsboat-og-debug per arch) to the private repo. Details in memory/newsboat-og.md.

Updates — 2026-07-18

adapted/fluxengine-git: build failure fixed (pkgrel 1 -> 2)

• Build failed compiling a vendored ImHex GUI plugin (hex_editor.cpp -> localization_manager.hpp) with an overload-resolution error: “no matching function for call to ‘format(fmt::v12::runtime_format_string<>, …)’”. Root cause: fluxengine’s own build system fetches an unpinned davidgiven/ImHex fork (branch master) into dep/r/imhex at build time via a custom git_repository() ninja rule — not a normal git submodule pinned by fluxengine’s own commit. That fork’s localization_manager.hpp reopens namespace fmt with its own fmt::format(const hex::Lang&, Args&&...) overload but only #include <fmt/core.h>, so with Arch’s current fmt 12.2.0 the real runtime_format_string overload (declared in <fmt/format.h>) isn’t visible yet at that point in two-phase lookup, and the call only resolves to the custom overload and fails. Confirmed with a minimal standalone repro before touching the PKGBUILD.
• Fix: added a prepare() that pre-clones dep/r/imhex itself and seds the one #include <fmt/core.h> to <fmt/format.h> in localization_manager.hpp, before make binaries ever runs — the build system’s own fetch rule only clones if dep/r/imhex/.git/config is missing, so pre-seeding it leaves the patch in place. Also added boost-libs to depends (namcap E: error — binary links libboost_regex.so but it wasn’t declared). Packaging-only fix, pkgrel 1 -> 2, .SRCINFO regenerated.
• Test-built clean with extra-x86_64-build (0 compiler errors after the fix, confirmed against a first build that reproduced the original failure). Signed and published (fluxengine-git + fluxengine-git-debug) to the private repo via scripts/repo_release.sh. Details in memory/fluxengine-git.md.

2026-08-02: linux-lts515 5.15.212 -> 5.15.213

• Upstream point-release bump (update.sh 5.15.213), verified the release tarball was actually published on cdn.kernel.org first (memory/linux-lts515.md warns the git tag can precede the tarball). Config diffs across all 4 archs were cosmetic only (build timestamp/toolchain version strings), no Kconfig changes – still persisted per standing preference.
• Full build across all 4 archs (x86_64, i686, i486, pentium4) succeeded and was signed, but the private repo host (euroweb.lan) dropped its SSH connection mid-publish and went fully unreachable for a while (infra outage, not a packaging issue). Waited for the host to come back, then finished the publish directly via repo_sign.sh/repo_publish.sh on the already-built artifacts (rerunning repo_release.sh would have redone the whole kernel compile – it has no “already built” check – so that path was killed instead). All 3 pkgnames x 4 archs published successfully. See memory/linux-lts515.md for the recovery procedure.

2026-08-02: full backlog pass (quick wins, never-investigated, external-dep vendoring)

Full audit-and-fix session covering everything flagged NEW/CHANGED in OVERVIEW.md plus the packages with no memory notes. Per-package details are all in their own memory/ files; summary here:

Quick wins (already-fixed or ordering-only, now rebuilt+republished): dos33fsprogs-git, i686-elf-pcc-libs-git, i686-elf-pcc-git (x86_64 only – i686 blocked by a systemic gap, see memory/i686-elf-pcc-git.md), pcc-git.

distrobuilder-git: fixed a real missing-makedepends bug (btrfs-progs), but hit a second, unrelated Go module version-skew issue deeper in the build (securejoin.OpenInRoot undefined) – flagged, not fixed, needs someone who knows the intended go.podman.io/storage <-> filepath-securejoin version pinning.

Never-investigated packages, all built+published clean (nothing noteworthy) unless noted: emu86-git, gtk2-ng-git, mimetic-git, slimcc-git, vhd2vl-git, chibicc-git (i686 fundamentally can’t build – x86_64-only codegen), liquidshell + xbanish (pre-built packages sitting unpublished in /data/INSTALL, just needed signing+publishing). jwm-git and xxdiff-git: x86_64 published, other archs hit unrelated chroot toolchain issues (stale libxml2/ICU symbol versions). tnylpo-git: published with two minor namcap nits flagged for later.

linux-lts510: investigated the 3 missing packaging patches (depmod hack removal, depmod-disable-for-packaging, python3 compat) – left unresolved. Their content isn’t recoverable anywhere in this environment and fabricating kernel-packaging patches from guesswork is too risky (wrong depmod handling can break module loading at boot).

External-dependency vendoring (new AUR packages added to maintained/, unblocking previously-failing packages):

• cc65 -> unblocked adtpro-git (also needed ant added to its makedepends)
• compiler-rt added to corral-git’s makedepends -> fixed it directly
• fcitx -> unblocked kcm-fcitx
• libaudclient -> unblocked mp3splt-gtk (+ mp3splt-gtk-docs)
• qt5-websockets -> unblocked qt5-webglplugin
• qt5-datavis3d -> unblocked python-pyqt5-datavisualization
• cmake3 -> unblocked yabause-qt5
• perl-plack (pulled in a ~16-package transitive AUR chain, all resolved) + perl-log-dispatch -> both published; mod_fcgid (the third thruk dependency) hit a GPG key-trust issue in the ephemeral build chroot that couldn’t be resolved without modifying shared chroot infrastructure – thruk itself stays blocked on that alone.

Deliberately deferred: qt5-webengine (unblocks qmc2, qt5-webview) and qt5-webkit (unblocks trojita/trojita-git/ trojita-qt5-git) both need full Chromium/WebKit builds – skipped given only ~22GB free disk at the time, too risky for a multi-hour build that could fail partway through. Revisit with more headroom.

Also recovered from a mid-session repo-host (euroweb.lan) outage during the linux-lts515 publish – see memory/linux-lts515.md.