Updates — 2026-08-22

check_ssl_cert: 2.103.0 -> 2.103.1

Full update cycle run (update_cycle.sh + check_aur_feedback.sh + local yay -Qu check). Only check_ssl_cert was flagged UPD by check_for_updates_maintained.sh; check_aur_feedback.sh found no new out-of-date flags or comments across the whole AUR-published tree.

Standard recipe per memory/check_ssl_cert.md: bumped pkgver, reset pkgrel=1, updpkgsums, regenerated .SRCINFO. Built/signed/published via repo_release.sh for x86_64/i686/pentium4 (armv6h/armv7h/aarch64 skipped, no local chroots for those, as usual).

New local-install rebuilds: simplescreenrecorder, odin-git

yay -Qu on the local machine flagged two plain AUR packages (not tracked under arch/) with updates: simplescreenrecorder (0.4.4-4 -> 0.4.4.79.ge73e-4) and odin-git (r17186 -> r18920 by the time of the fresh clone). Followed the standard local-install workflow: backed up each /data/INSTALL/<pkg> to -old, fresh-cloned from AUR, repo_release.sh’d, deleted -old after publish succeeded. Both were first-time releases to archlinuxaba (x86_64 only). Added both to arch/scripts/install_only_packages so generate_overview.sh tracks them. See memory/simplescreenrecorder.md and memory/odin-git.md.

Overview + site regenerated and republished after this batch.

Updates — 2026-08-16

Infra: flat src/ mirror on the repo host for unreliable/proprietary sources

Added ${REPOSITORY_REMOTE_PATH}/src/ on euroweb.lan (flat, sibling of os//archive/) plus arch/scripts/repo_src_upload.sh to upload files into it (forces world-readable perms on upload — the first upload came in as mode 600 from the local file and 403’d until fixed manually). See memory/REPO_PUBLISH_DESIGN.md §1/§3 for the design.

Migrated private/makemkv as the first user: makemkv-bin-1.18.4.tar.gz and makemkv-oss-1.18.4.tar.gz uploaded to src/, PKGBUILD source= repointed at https://archlinux32.andreasbaumann.cc/archlinuxaba/src/... (original makemkv.com URLs kept as a comment above source=), .SRCINFO regenerated, sha256sums unchanged, re-fetch verified against the mirrored copy. Fixes the intermittent Cloudflare-525 build failures against makemkv.com noted 2026-08-14. Same mechanism is intended for genuinely proprietary sources supplied out-of-band (e.g. jdk6-sun). See memory/makemkv.md.

Rebuilt and republished afterward: repo_release.sh built x86_64 cleanly against the new src/ mirror (fetch+checksum passed), signed and published makemkv + makemkv-debug 1.18.4-1.1 (old 1.18.4-1 archived). This was the same pending pkgrel bump from 2026-08-14’s ffmpeg7.1 fix, never previously published, so no further pkgrel bump was needed. i686 failed with target not found: ffmpeg7.1 as expected (that package is x86_64-only, see memory/makemkv.md); aarch64 skipped as always. Overview/site regenerated after this publish.

Updates — 2026-08-15

Update cycle: 1 package flagged, 1 real update

Ran scripts/update_cycle.sh (cleanup + fetch/fast-forward + version check + dependency check). Fetch/fast-forward and dependency check were both clean (0 unresolved deps across 626 entries, no dirty/diverged submodules). Version check flagged one package:

• hfsfuse 0.425 -> 0.435 (x86_64): the UPD ... 0.425 1.18.4 line in STATES.txt was misleading — this AUR git repo slot was reused from a different package (bindfs) back on 2026-07-31, and .nvchecker.toml had been left pointed at bindfs.org, so it was reporting bindfs’s version (1.18.4), not hfsfuse’s. Fixed nvchecker to check the real upstream (GitHub releases, 0x09/hfsfuse), which surfaced the actual pending update, 0.425 -> 0.435. Built, tested, signed and published cleanly; no patches needed. See memory/hfsfuse.md.

Also confirmed svgalib-git (asked about mid-session) is already tracked at maintained/svgalib-git — it just doesn’t show up in STATES.txt because check_for_updates_maintained.sh excludes all -git packages by design (their versions are commit-based, not comparable via vercmp).

Updates — 2026-08-14

New “local-install” category: rebuilding plain AUR packages found via local yay -Qu

The local machine (which the cluster’s package set is meant to be a superset of, installed from archlinuxaba) runs its own yay for AUR packages unrelated to arch/. yay -Qu flagged 4 outdated: localsend, x86_64-elf-gcc, dosbox-x, gameoftrees. None were tracked anywhere in arch/. Built a workflow for these (documented in memory/feedback_local_install_rebuilds.md in cross-session memory): back up /data/INSTALL/<pkg> to -old, fresh git clone from AUR, repo_release.sh, delete -old only once publish succeeds (kept as a fallback if the build/source fetch fails). Added a local-install category to scripts/install_only_packages and a matching entry to generate_overview.sh’s Details-section category loop (previously missing — new-category rows landed in the Summary count but were silently dropped from Details).

• localsend 1.18.1-1 (x86_64): clean rebuild, no issues. See memory/localsend.md.
• x86_64-elf-gcc 16.2.0-1 (x86_64): full GCC cross-toolchain bootstrap, ~2h wall time, clean. See memory/x86_64-elf-gcc.md.
• dosbox-x 2026.08.02-1.1 (x86_64 only): user asked to expand arch=() the same way as oksh below, but i486/i686/pentium4 builds either took excessively long or hung outright (one i486 rebuild needed machinectl terminate + kill -9 to stop, plain SIGTERM was ignored) — dropped those three archs per user instruction rather than debug further. See memory/dosbox-x.md.
• gameoftrees 0.127-1.1 (i486/i686/pentium4/x86_64): arch=() expansion built cleanly on all four, ~15 min total. See memory/gameoftrees.md.

maintained/libarchive-static: republished for all architectures

User requested (after first asking about a nonexistent “libarchive-git” and clarifying they meant libarchive-static). Version unchanged (3.8.9-1) but only x86_64 had ever been published; rebuilt+published i486/i686/pentium4/x86_64. Hit a flaky zlib.net download timeout on the first attempt (identical failure across all 4 archs) — worked around by copying an already-cached zlib-1.3.2.tar.gz(+.asc) from /data/INSTALL/libarchive-static/ into the package dir rather than retrying the network fetch. See memory/libarchive-static.md.

maintained/oksh: 7.9-1 -> 7.9-2, republished for expanded arch=()

User had already expanded oksh’s arch=() to add arm/armv6h/armv7h/aarch64 (pkgrel bumped 1 -> 2 by them). Rebuilt and published i486/i686/pentium4/x86_64 (the only archs with local chroots); old x86_64 7.9-1 build auto-archived. See memory/oksh.md.

Updates — 2026-08-13

Wired up i486/i686/pentium4 to the archlinuxaba private repo (build infra)

Extended repo_build.sh’s _build_cmd (previously hardcoded to x86_64-only) to use archlinuxaba-<arch>-build for any arch with a local symlink for it, falling back to stock extra-<arch>-build otherwise; added archlinuxaba-i486-build, archlinuxaba-i686-build, archlinuxaba-pentium4-build symlinks to archlinuxaba-archbuild. Discovered while testing that the single pacman.conf.d/archlinuxaba.conf (a copy of the generic x86_64 extra.conf) doesn’t work for the 32-bit archs: it uses Architecture = auto and Include = /etc/pacman.d/mirrorlist (the 64-bit Arch mirror), where devtools32’s own extra-i486.conf etc. use an explicit Architecture = <arch> and Include = /etc/pacman.d/mirrorlist32 (mirror.archlinux32.org) – without that, fresh chroot creation for i486/i686/pentium4 failed outright trying to fetch core/extra from the wrong mirror. Added archlinuxaba-i486.conf/archlinuxaba-i686.conf/archlinuxaba-pentium4.conf, each the corresponding stock extra-<arch>.conf plus our [archlinuxaba] section. See memory/TOOLING_NOTES.md and memory/REPO_PUBLISH_DESIGN.md for the full writeup.

maintained/libstroke: 0.5.1-10 -> 0.5.1-11 (packaging only)

Widened arch=() from x86_64 only to i486 i686 pentium4 x86_64 as a prerequisite for widening fvwm below (fvwm depends=(libstroke), and libstroke only ever existed in archlinuxaba for x86_64 – official arch32 extra/core don’t carry it). Built and published for all four arches. See memory/libstroke.md.

maintained/fvwm: 2.7.0-6 -> 2.7.0-7 (packaging only)

Widened arch=() from x86_64 only to i486 i686 pentium4 x86_64, using this as the end-to-end test case for the archlinuxaba build-infra change above. Built and published for all four arches (after the libstroke prerequisite above). See memory/fvwm.md.

Ran update_cycle.sh (cleanup, fetch/fast-forward, check-for-updates, dependency check). Nothing flagged: check_for_updates_maintained.sh reported 0 UPD packages (all checked packages OK, the rest have no .nvchecker.toml and show ?), and check_dependencies.sh found 0 unresolved deps across 611 checked. No packages required touching this cycle.

Updates — 2026-08-10

maintained/linux-lts515: 5.15.213-1 -> 5.15.215-1

Only package flagged UPD by check_for_updates_maintained.sh this cycle (check_dependencies.sh found 0 unresolved deps across 609 checked). Verified the release tarball was actually published on cdn.kernel.org (HTTP 200) before bumping, per this package’s known git-tag-vs-tarball-availability gap. Ran update.sh 5.15.215, which bumped pkgver, re-downloaded/ re-checksummed the source, and reconciled all 4 archs’ kernel configs in their real archbuild chroots (make olddefconfig via --nobuild). All 4 config diffs were cosmetic-only (just the version-string header comment, no Kconfig changes).

Full builds (sudo extra-<arch>-build) run detached in screen. x86_64 and i686 built clean on the first pass. i486 and pentium4 both failed immediately with an SSL timeout syncing mirror.archlinux32.org’s chroot databases – a transient mirror outage, not a package problem. Confirmed the mirror was back up (curl -sI -> 200) and re-ran both archs standalone; both succeeded. Signed and published all 12 files (3 pkgnames x 4 archs). See memory/linux-lts515.md for full detail, including a note on an accidental (harmless) double-publish invocation.

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.

2026-08-11 update cycle

Ran scripts/update_cycle.sh (cleanup_all -> fetch_ff_maintained -> check_for_updates_maintained -> check_dependencies). Clean run, no errors, no dirty/diverged submodules. Result: 0 packages flagged UPD (112 OK, 79 version-undetermined ? from dynamic pkgver expressions, same as before – not out-of-date, just unparseable by the checker). Dependency check: 609 unique depends/makedepends/checkdepends entries scanned, 0 unresolved. Nothing to update or publish this cycle.

2026-08-11 litehtml0.9 and glhack adoption

Adopted two new AUR packages into maintained/ (unchanged PKGBUILDs from their AUR maintainers – litehtml0.9 from Antonio Rojas, glhack from Eric Bélanger) and did the first build+publish of each to the private repo:

• litehtml0.9 (0.9-3): fresh submodule, wasn’t yet checked out locally (git submodule update --init needed first). Builds via cmake against gumbo-parser, ships a litehtml0.9-namespaced cmake config + include dir for coinstallability with other litehtml versions. Built/signed/published litehtml0.9 + litehtml0.9-debug x86_64 packages cleanly, no issues.
• glhack (1.2-12): Nethack fork/port. Built/signed/published glhack + glhack-debug x86_64 packages cleanly. namcap flagged the expected setgid-games ownership warnings inherent to the package’s game-save-directory design (not a build problem).

Both packages: first-ever publish, so repo_publish.sh’s repo-remove/checkpkg “not found” messages are expected and harmless. Regenerated the overview and republished the site afterward.

2026-08-16 svgalib-git publish

Published svgalib-git (1.9.27.r0.gefe6e10-1). The local submodule checkout was stale: a prior session had committed a PKGBUILD change (8f8e679) referencing three new .patch files without actually committing them (06e3e54 "svgalib-git: forgot to add patches" fixed this upstream at 0d33ad1, .SRCINFO included), but this checkout hadn’t fetched past the broken commit, so the patches were missing on disk and the package couldn’t build as committed. Fixed by git fetch

• fast-forward merge in the submodule to pick up the already-fixed upstream commit – no new patch content needed, just an out-of-date local checkout. Built/signed/published svgalib-git + svgalib-git-debug for both i686 and x86_64 cleanly (first-ever publish, so the repo-remove/checkpkg “not found” messages are expected and harmless). Regenerated the overview and republished the site afterward.

2026-08-17 to 2026-08-19: multi-arch extension batch + local-install additions

Large batch, worked as one continuous explicit queue (overview/site regen deferred to the very end per the batch-queue convention). Two threads of work: (1) extending existing packages to i686/pentium4 where feasible, given as an explicit list plus many follow-up “enqueue X” additions; (2) adopting new AUR packages under local-install/.

Arch extensions / verify-builds (maintained + adapted): pcc-libs-git, pcc-git, 8cc-git, libunac, meh-git, oberon-risc-emu-git, hdrecover all gained pentium4. python2 gained i686/pentium4 – needed a fresh openssl-1.1 (adapted/) dep first; hit a real 32-bit test_bigrepeat segfault and a second different 32-bit-only test failure, ended up disabling check() entirely for i686/pentium4 rather than chase individual test exclusions. gcc47 and tsv-utils were attempted for 32-bit and reverted (stage1 bootstrap symbol mismatch; no i686 ldc anywhere, respectively) – not every package fits.

Real bugs found and fixed along the way (not just arch=() edits):

• openssl-1.1 (adapted/): enable-ktls was never a valid Configure option (verified via source grep) – removed from x86_64 optflags.
• trojita-git (maintained/): tracked PKGBUILD had drifted to build against Qt6 despite the -qt5-git name – reverted to real Qt5 + WebKit per user’s explicit call; separately fixed an unpinned git commit (patch no longer applied) and a C++14/C++17 mismatch against a modern qgpgme-qt5 (new trojita-cxx17.patch). qt5-webkit itself (needed by trojita) got a first-time real git clone (was loose files) and was signed+published from an existing local build without a rebuild, per explicit instruction, since a full WebKit rebuild takes hours.
• cloog (local-install): texlive/texi2dvi conflicted with i686/ pentium4’s texlive-bin/texlive-basic – fixed by dropping texlive-* from makedepends and adding TEXI2DVI=true to all three make invocations (took 3 rebuilds to catch every call site).
• fltk1.3 (local-install, brand new): tigervnc-viewer’s i686 build failed on a missing fltk1.3 dependency. Rather than just excluding i686, checked whether it could be built ourselves – turned out archlinux32 builds it for i686/pentium4 in their pool but doesn’t publish it to any live repo, so it wasn’t actually installable anywhere. Pulled the real upstream Arch PKGBUILD via pkgctl, added i686/pentium4, built cleanly first try.
• tigervnc-viewer (local-install): with fltk1.3 available, re-extended to i686/pentium4, then hit a second bug – the tracked nettle-4.patch assumes nettle >=4.0’s EAX_DIGEST API, but the i686/pentium4 chroots still have nettle 3.10.1 (archlinux32 hasn’t packaged 4.0 for 32-bit). Fixed by gating the patch to x86_64 only in prepare().
• python-pydns (local-install, brand new): upstream’s pyproject.toml pins flit_core <4, but Arch’s python-flit-core is now 4.0.2 – fixed with a new pydns-flit-core4.patch relaxing the bound.
• ptouch-print (local-install, brand new, x86_64 only per request): upstream’s own git host (familie-radermacher.ch) returns HTTP 451 to this host – switched source to pettarin/ptouch-print, an hourly-synced GitHub mirror, pinned to a specific commit since the mirror carries no tags.

New local-install adoptions, no notable issues: vasm, bridge-utils, jwm (i686/pentium4 added, later reverted – libpangoft2/fontconfig symbol breakage on official archlinux32 i686 repos, external and unfixable locally; user is downgrading pango on affected machines), perl-http-daemon-ssl, cparser-git (verify only), wordgrinder, osl, gatotray-git (same pango issue as jwm, reverted), slock-git, x2x-git, tabula, mt-st-git, pdf2htmlex, lxc-templates, jxplorer, qt5-webengine (x86_64 only, skipped 32-bit – multi-hour Chromium build), wkhtmltopdf, aggregate, arch-diff, mtx-git (verify only), obextool, tcllib, tklib, bwidget, archlinux-java-run (already checked out and current, just needed registering), yed, mutt-ics (new, extended to pentium4 – pure Python, no compiled code), python-fangfrisch (existing stale checkout updated 1.9.0->1.9.2 via git pull), apachedirectorystudio (new, x86_64 only – prebuilt Eclipse RCP tarball, no 32-bit upstream build exists), miller-git (new, Go build, extended to i686/pentium4).

smallerc and oberon-risc-emu-git were separately extended to i686/pentium4 on explicit user follow-up after initially being built x86_64-only.

Regenerated the overview and republished the site once at the very end of this whole batch, per the deferred-regen convention for an explicit multi-package queue.

2026-08-19 openssl-1.0: extended to i686/pentium4

Local openssl-1.0 (local-install) checkout was byte-identical to the real upstream AUR PKGBUILD but declared arch=('x86_64') only, even though build() already carried a working i686 branch (openssltarget='linux-elf') from upstream itself – just never exposed via arch=(). Added a pentium4 case alongside it (same 32-bit target) and extended arch=('x86_64' 'i686' 'pentium4'). Built and published cleanly on all three arches on the first try; pkgrel 7 -> 7.1 (local-install, X.Y scheme). Note: check()’s OCSP test prints several Verification: FAILED lines – these are the test suite’s own intentional negative-result cases, not real failures (all six packages still got uploaded). Regenerated the overview and republished the site afterward.

2026-08-20 trojita-git/trojita-qt5-git mixup, fixed + gpgme dependency chain

Discovered and fixed a self-inflicted mess from earlier in the session: arch/maintained/trojita-git’s PKGBUILD had been overwritten with trojita-qt5-git’s content (both AUR pkgbases confusingly set pkgname=trojita-qt5-git internally, an upstream copy-paste bug that made this easy to miss). trojita-git is genuinely the Qt6 variant (WITH_WEBKIT=OFF), trojita-qt5-git the Qt5+WebKit variant – restored trojita-git from real upstream (pkgname corrected locally), found and fixed its own real missing deps (qt6-5compat, kitemmodels, qtkeychain-qt6, QGpgmeQt6 cmake path) – publishes cleanly for x86_64 (KF6/kitemmodels not on 32-bit archlinux32, i686 dropped).

For trojita-qt5-git, fixing qtkeychain-qt5 and a missing gpgmepp depend led to a genuine 32-bit dependency chain: qgpgme-qt5 needed gpgmepp>=2.1.0 (archlinux32 had none for 32-bit) which needed gpgme>=2.1.0 (archlinux32 only had 2.0.1) – built both gpgme and gpgmepp ourselves for i686/pentium4 (upstream’s git host, dev.gnupg.org, was also unreachable; switched to the official release tarball, re-hosted on our own src/ mirror). Both, plus qgpgme-qt5 extended to 32-bit, needed a legacy icu76 linked to archlinux32’s system Qt5Core. trojita-qt5-git itself then needed icu76 (for lconvert), a different legacy icu72, and libxml2-legacy (only available for i686, not pentium4) to satisfy its own qt5-webkit dependency’s stale ABI. Final blocker: a Qt5 private API symbol mismatch in libQt5Quick.so on i686 – an internal ABI inconsistency in archlinux32’s own Qt5 stack, not fixable with a legacy-compat package. Stopped there per user’s call; trojita-qt5-git publishes x86_64 only.

Also fixed a real infrastructure problem hit mid-chain: the repo host’s repo-add/repo-remove were extracting the package database into /tmp, a tiny 32M tmpfs that finally overflowed after this session’s cumulative package growth (Write failed: No space left on device). Redirected both to TMPDIR=/data/tmp (626G free) in arch/scripts/repo_lib.sh. Verified no earlier publish this session was silently lost by spot-checking several packages directly in the remote repo database.

Also added arch/scripts/repo_build_staged.sh: a new wrapper that stages arch/-sourced package builds under /data/INSTALL/<pkgname> instead of building in place, so downloaded sources/patches/logs persist for inspection instead of being swept up by repo_build.sh’s own untracked-file cleanup (which still exists, unmodified, for direct manual use). repo_release.sh now calls this wrapper instead of repo_build.sh directly; /data/INSTALL-only packages (no arch/ counterpart) pass through unaffected.

Regenerated the overview and republished the site afterward.

2026-08-20: cyrus-imapd2 renamed/fixed, dbmodel-qt4 re-verified

arch/adapted/cyrus-imapd2 was internally still named cyrus-imapd (directory/pkgname mismatch, same class as the earlier trojita-git mixup). Renamed to match the real AUR cyrus-imapd2 package: kept a _pkgname=cyrus-imapd var for the real upstream source references, set pkgname=cyrus-imapd2, renamed the .install file, added provides/conflicts/replaces=('cyrus-imapd') so it properly supersedes a plain cyrus-imapd install. While rebuilding, found and fixed a real 32-bit-only latent bug: imap/mboxevent.c declared a map_refresh()/ map_free() buffer-length local as unsigned long instead of size_t – harmless on x86_64 (same 8-byte type) but a hard incompatible-pointer-types error on i686 (size_t is unsigned int there). Added a small patch for it. Published cleanly for x86_64 and i686 (pkgrel 2.3); armv6h/armv7h skipped (no local chroots on this workstation, not a package issue).

Re-verified dbmodel-qt4: x86_64 still builds/publishes cleanly (pkgrel 7, unchanged). Confirmed directly on the repo host that the long-standing i686 failure is because qt4 itself was only ever published to archlinuxaba for x86_64 – not a chroot-visibility gap (i686 chroots do see archlinuxaba now, unlike when this was first investigated). Since qt4 isn’t a package this tree owns, not actionable here.

Regenerated the overview and republished the site afterward.

2026-08-20: gcc47 – real stage1-bootstrap fixes for x86_64, 32-bit blocked on a structural ABI conflict

Root-caused the actual mechanism behind the i686/pentium4 bootstrap failure precisely (previous attempts only diagnosed symptoms). Two real fixes landed for x86_64: --with-stage1-ldflags='-static-libstdc++ -static-libgcc' (the documented GCC configure option for statically linking stage1 host tools – a prior attempt via the make command line didn’t actually propagate through GCC’s recursive sub-configure structure) and --disable-nls (building libstdc++-v3’s translations ran the system’s real msgfmt, which itself needs a modern libstdc++/libgcc via libicuuc – but by that point the in-progress build-tree libstdc++.so.6 shadows the real one in the search path, breaking msgfmt; this also broke x86_64, which hadn’t hit it before). Published gcc47-4.7.4-2.6 for x86_64.

For i686/pentium4: the stage1-ldflags fix genuinely got much further (cc1 confirmed statically linked, build progressed to cross-building libstdc++-v3 target libraries) before hitting a deeper, structural issue – cc1 also transitively needs the system’s libgmpxx.so.4 (GMP’s C++ bindings, via PPL/CLooG), which needs the real system libstdc++.so.6/libgcc_s.so.1 with a GCC_7.0.0 symbol version that gcc-4.7.4’s own (2012-era) libgcc sources can never provide, and the build-tree’s own incomplete libgcc_s.so.1 shadows the real one in the search path for this unrelated consumer too. Not fixable via linker flags – the real fix would be bootstrapping with an intermediate host compiler (a prior maintainer already left a commented-out gcc49 escape hatch for exactly this), which would need gcc49 built for i686/pentium4 too. Reverted arch=() to x86_64-only; full diagnosis in memory/gcc47.md if revisited.

Regenerated the overview and republished the site afterward.

2026-08-21: full update cycle – 3 UPD packages (hfsfuse, thunderbird-esr-bin, linux-lts515)

Ran update_cycle.sh + check_aur_feedback.sh. STATES.txt flagged 3 packages; FEEDBACK.txt turned up one actionable AUR comment (python2’s Gentoo-patches URL now 404ing) that’s deferred pending user direction, plus routine/already-resolved items for litehtml0.9 and trojita-git.

hfsfuse: 0.435 -> 0.444, routine GitHub-tag bump (tarball existence confirmed first). Built+published clean via repo_release.sh.

thunderbird-esr-bin: 140.13.0 -> 140.14.0. First build attempt failed PGP verification on all 3 arches (unknown public key 678E455D76767AA3) – Mozilla rotated their release-signing subkey on 2026-08-06. Fixed by fetching the new subkey from hkps://keys.openpgp.org (the old SKS-era keyservers didn’t have it yet) and refreshing this package’s local keys/pgp/ cache via scripts/update_pgp_key_dir.sh; rebuild then passed cleanly on all 3 arches. Adopted running that script proactively before every build with validpgpkeys going forward, not just reactively after a failure. See memory/thunderbird-esr-bin.md.

linux-lts515: 5.15.215 -> 5.15.216, routine point release via update.sh (all 4 archs’ config diffs cosmetic-only). Built in the wrong place first – directly inside arch/maintained/linux-lts515 rather than staged under /data/INSTALL – and since the x86_64 kernel compile was already well underway by the time that was caught, let it finish rather than restart, then recovered by migrating the full result (source + all 12 built files) into /data/INSTALL/linux-lts515 (after rotating the previous, badly stale 2026-07-05 copy there aside to -old), git clean -fd-ing arch/maintained/linux-lts515 back to pristine, and signing+publishing straight from the staged copy. All 12 files (3 pkgnames x 4 archs) published cleanly. Generalized this recovery into a reusable 5-step procedure in memory/TOOLING_NOTES.md for any future in-place-build mistake.

Regenerated the overview and republished the site afterward (deferred until the end of this 3-package queue, per the batch-queue convention).