aurupdater

Updates — 2026-09-11

rxvt: expanded to all 7 archs, fixed aarch64’s ancient config.guess/config.sub (pkgrel 10 -> 11)

arch=() was i686/x86_64 only; expanded to the full 7-arch set (purely additive, no pkgrel bump for that part). Six archs built clean; aarch64 failed with configure: error: cannot guess build type – the bundled config.guess/config.sub are dated 2002-09-03, predating the aarch64 architecture entirely. Fixed with an arch-conditional prepare() step copying current copies from automake (base-devel, no new makedepends) into the autoconf/ subdirectory configure actually reads from – a first attempt copying to the wrong directory (. instead of autoconf/) failed identically, caught by checking the extracted source’s file timestamp directly on the build board. pkgrel 10 -> 11. All 7 archs now published. See memory/rxvt.md.

python2: fixed dead Gentoo-patches source URL (pkgrel 17 -> 18)

AUR repeatedly flagged this since 2026-08-21 (“Gentoo source is dead”): source=()’s dev.gentoo.org/~mgorny/... Gentoo-patches URL is a real 404. Our own builds kept succeeding only because a stale, untracked, already-downloaded copy of the tarball was sitting in the pkgdir, masking the break. Swapped the URL to the working AUR-community-confirmed mirror (mirrorservice.org, byte-identical content, no checksum change needed). Rebuilt all 4 archs: x86_64/i686/pentium4 published cleanly; aarch64 failed on an unrelated, pre-existing openssl-1.1 availability gap on that board’s repo. Also proactively refreshed the package’s PGP key cache (update_pgp_key_dir.sh) per an AUR-reported “unknown public key” comment. See memory/python2.md.

notion3: filled in remaining arch=() and fixed texlive doc-build conflict (pkgrel 6 -> 6.1)

arch=() already listed all 7 archs but only x86_64 had ever published. Building the rest surfaced a real blocker on pentium4/i686/i486: /usr/bin/ebb exists in both texlive-bin and texlive-basic (upstream Arch32’s extra repo has texlive-bin a full point-version behind texlive-basic – a packaging-split lag, not fixable here); armv6h failed separately with texlive-meta not even present in its extra. Root cause: rubber/latex2html/ texlive-meta are only needed to build the separate notion-doc HTML manual, not the window manager itself. Made doc building arch-conditional (_doc_archs=('x86_64' 'armv7h' 'aarch64'), doc-only makedepends_<arch> arrays, build()/package() guard the notion-doc steps) instead of dropping docs everywhere. Also added pentium4 to cyrus-imapd2’s arch=() (no pkgrel bump – purely additive). Rebuilt and published notion3 on all 7 archs.

Updates — 2026-09-10

trojita: real C++17 fix landed (pkgrel 16 -> 17)

Followed up on the C++17 blocker found during the full cycle below. Root cause: build()’s own -DCMAKE_CXX_STANDARD=14 in the PKGBUILD (not CMakeLists.txt, where an earlier attempted fix would have been silently overridden by this higher-priority -D cache variable) – bumped to 17. That alone would trade the original std::string_view error for a std::binary_function one, so also patched every other C++17-removed pre-C++11 relic found in a full source sweep: std::binary_function/std::unary_function (3+1 sites), std::bind2nd (3 sites, replaced with lambdas), and dynamic exception specifications (throw(Type)/throw(), 5 sites, replaced with noexcept or dropped). Built, signed, and published cleanly on x86_64 on the first real attempt after assembling the full patch. See memory/trojita.md.

eurobuild14 back up + remote-build board verified

User reported eurobuild14’s SSH keys were restored after maintenance. Found and fixed two gaps from the reimage that would have silently broken every remote build there: rsync and oksh were both missing from the board’s package set (installed via the existing passwordless sudo). Verified end-to-end with a genuine fresh build (cache-busted, not reused) of a2tools for aarch64 – built, signed, and published cleanly. Board is fully operational again.

Full check and rebuild cycle

Ran update_cycle.sh (cleanup, fetch+fast-forward all submodules, upstream version check, adoptable-package scan, dependency check) – all clean: 0 UPD packages, 0 adoptable candidates, 0/655 unresolved dependencies. Then repo_diff_local_remote.sh + repo_release_changed.sh for the actual NEW/CHANGED set (VCS/-git packages excluded by design, per established convention):

Separately, rebuilt local-install/bindfs (pkgrel 1 -> 1.1) after a user-reported fuse3 dependency conflict on another machine – built and published cleanly, though the exact pin mechanism the user saw couldn’t be reproduced/confirmed from this project’s own published package metadata. See memory/bindfs.md.

pdfalto: 0.6.2 -> 0.6.3, first successful build+publish ever

Found via routine UPD sweep. The libpng14/gcc12 external dependency gap that had blocked every prior attempt since 2026-07-07 is gone – both now resolve from the private repo itself. Bumped pkgver, updpkgsums, built and published cleanly on the first try. See memory/pdfalto.md.

cyrus-imapd2: fixed missing jansson dependency (pkgrel 2.4->2.5)

Added jansson to depends=(), closing the namcap E: Dependency jansson detected and not included finding from the rebuild just below. Cleaned a stale armv7h staging artifact first, then rebuilt and republished cleanly across all 4 archs. See memory/cyrus-imapd2.md.

optdb5.3 + cyrus-imapd2: content-free rebuilds for ARM coverage (pkgrel 6->6.1, 2.3->2.4)

Both requested as pure pkgrel-bump rebuilds to pick up arch coverage that had no local chroot before: optdb5.3 (private/, x86_64 + armv7h wished, only x86_64 ever published) and cyrus-imapd2 (adapted/, i686/x86_64/armv6h/armv7h wished, only i686/x86_64 ever published). Both are now covered by the eurobuild4/eurobuild5 remote ARM build boards. Both built and published cleanly on every wished arch. Hit and resolved a board collision along the way: both packages independently need armv7h, i.e. the same eurobuild5 board – killed cyrus-imapd2’s armv7h job (less sunk cost) to let optdb5.3’s finish, then retried cyrus-imapd2’s armv7h alone once the board was free. Also surfaced (not fixed) a real missing jansson runtime dependency on cyrus-imapd2 via namcap. See memory/optdb5.3.md and memory/cyrus-imapd2.md.

Removed duplicate arch/maintained/qt5-examples submodule

While investigating the qt5-doc AUR comment about struct_mutex.h, found maintained/qt5-examples was a duplicate submodule of the exact same AUR repo as maintained/qt5-doc (aur.archlinux.org/qt5-doc.git, same pkgbase=qt5-doc/pkgname=(qt5-doc qt5-examples)), just frozen 3 commits stale and never actually used (no memory note, no FEEDBACK.txt history). User confirmed and approved removal. git submodule deinit -f + git rm maintained/qt5-examples, staged (.gitmodules diff + the directory deletion) but not committed. See memory/qt5-doc.md.

Updates — 2026-09-09

qt5-doc: hardened then reverted the CDN-workaround curl logic in prepare() (pkgrel 2 -> 3)

Asked to look at the 2026-09-08 CDN-redirect workaround in prepare() (“suspicious package… what is happening”) as a security review: not malicious, but two real hardening gaps (mirror URL from parsed XML handed to curl with no scheme check and no -- before it; a no-op test -n guard) – fixed both. User then judged the whole curl+XML-parsing approach not worth keeping regardless (“looks suspiciously like a curl injection”) and asked for a full revert to commit 1fd84a17162e51079b1d88597518db5bfc004544 (the last commit before the workaround) – back to a plain pinned-URL source=(), no custom fetch logic. pkgrel kept moving forward to 3 (not reused as 1) since 2 was already live. Known tradeoff reinstated: someone building in a region with no local CDN mirror may hit the MirrorBrain XML stub again; accepted mitigation is a manual tarball download into the source cache, not a PKGBUILD-side fix.

Separately investigated an AUR comment about /usr/include/bits/struct_mutex.h in the build log – confirmed (against the last successful build’s own log) this is pre-existing, non-fatal qdoc noise: qdoc builds without libclang here (“QDoc will not be compiled, probably because libclang could not be located”), falls back to Qt5’s legacy heuristic parser, which throws “undeclared identifier” errors on real glibc headers it doesn’t fully understand – present in both the working 2026-09-08 build and this one, make docs completes regardless (“Documentation successfully generated”). Not something today’s changes caused or fixed.

Rebuilt (aborting one in-flight build mid-make docs first, cleanly, after the revert decision) and republished with MAKEFLAGS=-j8 (48m34s, any-arch, fanned out to all archs via symlink). See memory/qt5-doc.md for the full blow-by-blow.

qmc2: first successful build+publish (0.243-9, x86_64)

Previously deferred twice (2026-07-07, 2026-08-02) over a misidentified risk — the deferral notes worried about rebuilding qt5-webengine itself (a multi-hour Chromium checkout+build), but qmc2’s own build() just links against the already-installed qt5-webengine from core/extra, so this was an ordinary ~8.5min x86_64 build. No PKGBUILD change (pkgver=0.243 pkgrel=9 already current per STATES.txt); qmc2/qmc2-debug had no prior repo db entry so this was genuinely the first publish, not a rebuild. Built, signed, and published cleanly (x86_64-only per arch=()). See memory/qmc2.md.

pcmciautils: pkgrel 9 -> 10, all 4 Arch32 archs rebuilt, build times recorded

Rebuilt to populate per-arch build-time auto-recording (see memory/pcmciautils.md’s “Build times (auto-updated)” block), which the 2026-09-08 all-arch build predated. Initially bumped pkgrel to a plain 10 for this content-free rebuild — wrong per this project’s convention (a rebuild with no real content change should use 9.1 even under maintained/, see memory/PKGREL_VS_PKGVER.md’s new “Content-free rebuilds get X.Y too” section); caught only after 10 was already published across all 4 archs, and correcting back to 9.1 would have vercmp’d as a downgrade, so it was left as 10. Shortly after, a genuine content fix (dropped the dead pcmcia.html suffix from the upstream url=) landed on top, retroactively making 10 a legitimate whole-integer bump; rebuilt and republished all 4 archs + pcmciautils-debug again to embed the corrected URL. PGP key already current. OVERVIEW.md regenerated and site republished after.

Updates — 2026-09-05

linux-lts515: 5.15.219 -> 5.15.220, first build with MAKEFLAGS parallelism

Routine point release (cosmetic-only config diffs across all 4 archs). Notable for tooling reasons rather than packaging ones: this was the first real build to use the new per-arch build-time recording and opt-in MAKEFLAGS chroot-parallelism override added earlier the same day. x86_64 was already mid-build (serial) when those features landed, so it finished the old way (4h10m); the run was then cleanly killed and resumed for pentium4/i686/i486 with MAKEFLAGS=-j6 (each ~2.5-3h, vs. x86_64’s serial baseline) — including a mid-flight fix to the parallelism mechanism itself (makechrootpkg’s own config reload was silently discarding the override; see memory/linux-lts515.md and memory/TOOLING_NOTES.md for the full story). All 12 files (3 pkgnames x 4 archs) built, signed, and published cleanly; verified via direct remote listing.

Updates — 2026-09-04

brave-origin-bin: rebuild, 1.92.139 -> 1:1.94.119-1

User noticed an in-browser update prompt; not tracked under arch/, so handled as a local-install rebuild (fresh AUR re-clone, no local PKGBUILD edits needed). Built clean for x86_64 (local) and aarch64 (remote, eurobuild14), published to both archs. Added local-install/brave-origin-bin to arch/scripts/install_only_packages (wasn’t tracked there before). See memory/brave-origin-bin.md.

Updates — 2026-09-03

thunderbird-esr-bin: ESR-train switch 140.x -> 153.x, dropped i686/pentium4

Mozilla started a new ESR train with Thunderbird 153 “Meadow” (2026-07-21); 140.x ESR loses upstream support around mid-September

  1. Rebased thunderbird-esr-bin onto 153.2.0. Crucially, Mozilla no longer publishes Linux i686 builds for the 153.x train (only linux-x86_64/), so arch=() shrank from ('x86_64' 'pentium4' 'i686') to ('x86_64') and the source_pentium4/source_i686 arrays were removed. Built, signed, and published cleanly for x86_64. See memory/thunderbird-esr-bin.md.

thunderbird-esr140-bin: new package, forked from thunderbird-esr-bin at 140.15.0

Created to keep serving 32-bit users and anyone needing to stay on the old ESR now that thunderbird-esr-bin moved to 153.x (which dropped i686 entirely upstream). Forked at 140.15.0 (the newest 140.x point release), keeping arch=('x86_64' 'pentium4' 'i686'). Mutually exclusive with thunderbird-esr-bin (same install paths/binary name — conflicts added both ways), not side-by-side installable. Built, signed, and published cleanly for all three arches.

Not yet a real AUR package — prepared as a plain local directory under arch/maintained/, not a git submodule, since creating a brand-new AUR package is a real public action the user needs to do themselves (see memory/thunderbird-esr140-bin.md for the exact hand-off commands).

qt5-connectivity: added aarch64

User asked to add aarch64 support. depends/makedepends (qt5-base, bluez-libs, qt5-declarative, git) all resolve from the official extra repo, so no dependency packages needed building first. Added aarch64 to arch=() (pkgrel 1 -> 2, packaging-only), built via the remote-ARM mechanism on eurobuild14 — built and published cleanly on the first attempt for both x86_64 and aarch64. First qt5-family package in this tree with aarch64. See memory/qt5-connectivity.md.

cssh: rebuild against new upstream commit, cscp install collision fixed

User asked for a rebuild; upstream had moved to 6bd0546e (“implemented cscp both for SCP and TFTP…”). First attempt failed identically on every arch: src/CMakeLists.txt now installs the cscp symlink itself, colliding with the AUR PKGBUILD’s own leftover manual ln -s cssh cscp in package(). Removed the redundant line. Rebuilt and published cleanly on all 7 real archs (i486/i686/pentium4/x86_64/armv6h/armv7h/aarch64) at 0.0.1.r25.g6bd0546-1, 100% tests passing everywhere. See memory/cssh.md (also notes a near-miss: briefly ran two concurrent repo_release.sh invocations for the same package — caught and killed before any damage).

Updates — 2026-08-31

cssh: user fixed linenoise strcasecmp and armv6 sleep upstream, full 7-arch rebuild

User fixed both remaining local workarounds at the root, upstream in their own cssh repo: a real #include <strings.h> for strcasecmp() in the vendored linenoise, and the mock_sshd wait_for_port() sleep timing that was previously too tight for armv6h. Removed the now-unneeded local patch and the armv6h-only check() skip from the AUR PKGBUILD (user did this themselves and committed it). Rebuilt and published all 7 real archs (i486/i686/ pentium4/x86_64/armv6h/armv7h/aarch64) at 0.0.1.r24.gb31d3d4-1 — all built, tested (100% pass everywhere, including a clean 35s armv6h functional-test run), signed, and uploaded. See memory/cssh.md.

Updates — 2026-08-27

pacman-static, libarchive-static: bundled OpenSSL 3.6.3 -> 3.6.4

Bundled-dependency checks flagged OpenSSL for both. OpenSSL rotated to a new dedicated release-signing key (OpenSSL <openssl@openssl.org>, issued 2026-05-26) that neither PKGBUILD had yet — added its fingerprint to validpgpkeys in both. pacman-static pkgrel 15 -> 16, libarchive-static pkgrel 1 -> 2. libarchive-static’s rebuild also hit an unrelated download.savannah.gnu.org outage (hosts its attr/ acl bundled sources) — worked around via the Wayback Machine and the download-mirror.savannah.gnu.org mirror hostname, verifying checksums/signatures before use. Both built and published cleanly on x86_64/i686/pentium4/i486. See memory/pacman-static.md and memory/libarchive-static.md.

e1000e-dkms-lts515: verified DKMS-buildable against linux-lts515 (pentium4)

User asked whether this was buildable for a pentium4 machine. Since it’s a DKMS source package (arch=any, no real compile at package-build time), tested the actual module compile in a throwaway copy of the archlinuxaba-pentium4 chroot: installed dkms + linux-lts515 + linux-lts515-headers + the package, confirmed dkms status showed installed and the resulting .ko was a genuine 32-bit i386 ELF object built against the chroot’s own toolchain. No changes needed — already published at 3.8.7-3 for every arch including pentium4. See memory/e1000e-dkms-lts515.md (includes a reusable throwaway-chroot DKMS test recipe).

New local-install package: grub-legacy (first publish)

Built and published grub-legacy (0.97-30, matching AUR’s current version) for the first time — x86_64, i686, pentium4, i486. Existing /data/INSTALL/grub-legacy checkout (untouched since 2025-09-16, never finished a publish) carries local edits: arch=() expanded to include pentium4/i486, and lib32-glibc/lib32-gcc-libs moved into depends_x86_64 (multilib runtime libs only apply to the x86_64 build, not the native 32-bit archs). x86_64 initially failed (ld: cannot find libgcc_s.so.1) until lib32-gcc-libs was added alongside lib32-glibc. Also hit two transient SSH connection resets against euroweb.lan mid-run that silently dropped the x86_64 build and the i686 publish despite exit code 0 — recovered by re-running the affected steps directly once connectivity stabilized; all 4 archs verified present on the remote. Added local-install/grub-legacy to arch/scripts/install_only_packages. See memory/grub-legacy.md.

maintained/thunderbird-esr-bin: 140.14.0 -> 140.14.1

Routine version bump (x86_64, i686, pentium4). PGP key cache already current. Hit a transient SSH connection reset mid-publish that dropped the pentium4 upload despite the script exiting 0 (old version already removed from the pentium4 db, new package never uploaded) — recovered by re-running repo_publish.sh directly against the still-local package file once connectivity stabilized.

New local-install package: claude-code (first tracked publish)

claude-code was already on archlinuxaba (2.1.205-1) from an earlier, untracked build with no install_only_packages entry or memory file. Rebuilt to AUR’s current 2.1.247-1 (fresh clone, no local patches, no validpgpkeys), x86_64 only (no local aarch64 chroot even though upstream’s arch=() includes it). Added local-install/claude-code to arch/scripts/install_only_packages and memory/claude-code.md.

ffmpeg7.1: rebuild for libbluray soname bump (7.1.3-1 -> 7.1.3-1.1)

libbluray 1.5.0-1 in extra bumped its soname (libbluray.so=3), breaking the installed ffmpeg7.1 7.1.3-1 (linked against soname 2) and blocking pacman -Syu. AUR hadn’t bumped ffmpeg7.1’s pkgver, so this was a packaging-only rebuild: fresh clone from AUR into /data/INSTALL/ffmpeg7.1, pkgrel 1 -> 1.1, PGP key refreshed, built/signed/published via repo_release.sh (x86_64 only). Old 7.1.3-1 archived normally. See memory/ffmpeg7.1.md.

Updates — 2026-08-24

New local-install package: owncloud-client-6

Added owncloud-client-6 (legacy ownCloud-6.x-compatible desktop client, AUR-maintained by iyanmv, not us — conflicts=(owncloud-client), provides=(owncloud-client=$pkgver)). Fresh-cloned from AUR into /data/INSTALL/owncloud-client-6, PGP key refreshed (update_pgp_key_dir.sh), built (x86_64 only, ~48min Qt6/KDE ECM/CMake compile). makechrootpkg -C’s namcap QA pass choked on the 37 MB debug package (==> ERROR: Aborting..., empty namcap log for it) even though both packages had already built successfully — recovered by copying the finished .pkg.tar.zst files out of the chroot’s pkgdest by hand and running repo_sign.sh/repo_publish.sh directly instead of a full repo_release.sh rebuild. Published to os/x86_64/. Added local-install/owncloud-client-6 to arch/scripts/install_only_packages. See memory/owncloud-client-6.md.

bochs: 3.0 -> 3.1

Flagged UPD by check_for_updates_maintained.sh. First build attempt failed at prepare() for every arch: upstream’s 3.1 release tarball on SourceForge extracts to a bare bochs/ directory instead of bochs-3.1/ like every prior release, breaking the PKGBUILD’s cd "$srcdir/$pkgname-$pkgver". Fixed by normalizing the extracted directory name in prepare() (renames bochs/ -> bochs-$pkgver/ if present); pkgrel bumped 1 -> 2 for this packaging-only fix (per [[feedback_pkgrel_vs_pkgver]] — maintained/ gets a plain integer bump). Also confirmed the previously-noted gtk2 missing-dependency issue (memory/bochs.md, 2026-07-07) is resolved: gtk2 is now published in our own archlinuxaba repo. Built/signed/published for all 4 archs (x86_64/pentium4/i686/i486) via repo_release.sh.

linux-lts515: 5.15.216 -> 5.15.217

Flagged UPD. Routine point release via update.sh 5.15.217 — tarball confirmed on cdn.kernel.org first. Config reconciliation this time included one real (non-cosmetic) Kconfig change on the 32-bit archs: CONFIG_CAN_ESD_USB2=m -> not set. pkgrel stays 1 as usual for a pkgver bump. The repo host (euroweb.lan) dropped its SSH connection partway through repo_publish.sh (mid-linux-lts515-docs, before linux-lts515-headers even started) — 5 of 12 files got uploaded before the outage, the run’s own exit code still came back 0 so this needed catching by re-grepping the full log for Connection reset/Broken pipe/Connection refused, not just the UPLOADED/SIGNED lines. Recovered per the documented pattern (memory/linux-lts515.md, prior 2026-08-01 outage): no rebuild needed, the local .pkg.tar.zst/.sig were already good, so once the host came back just re-ran repo_publish.sh on the 7 missing files directly. Verified full remote state afterward (ls on os/<arch>/ on the repo host) before declaring this one done. Built/signed/published across all 4 archs via repo_release.sh.

Overview + site regenerated and republished after each package in this session (routine per-package cadence, not a batched queue).

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:

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).

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

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

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

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

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

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

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

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

Other findings

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

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

Script/tooling fixes made along the way

Not done in this pass

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:

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

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:

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)

Script fix

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

Targeted fix — 2026-07-15

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

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

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

optdb5.3 and notion3: published (x86_64)

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

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

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

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

Updates — 2026-07-18

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

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

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):

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:

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

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):

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).

2026-08-28: fluxengine-git rebuild (protobuf soname + mbedtls 4.x)

fluxengine-git: pkgrel 1.1 -> 1.2, two fixes in one release. Triggered by a local pacman -Syu reporting installing protobuf (36.0-1) breaks dependency 'libprotobuf.so=35.1.0-64' required by fluxengine-git – a plain rebuild against current protobuf. That rebuild then hit a second, independent break: Arch’s mbedtls jumped to 4.2.0 and dropped the old public API the vendored ImHex GUI plugin (dep/r/imhex/lib/libimhex/source/helpers/crypto.cpp) still uses. Fixed by switching depends from mbedtls to the mbedtls3 compat package (extra/3.6.7-1) and pointing PKG_CONFIG_PATH at its pkgconfig dir in build()/check(), since fluxengine’s own build system resolves mbedtls purely via pkg-config. Confirmed mbedtls is only used by the GUI target, nowhere else in fluxengine’s own code. Built and published cleanly on x86_64 (the package’s only arch). See memory/fluxengine-git.md for the full root-cause writeup.

Also, while investigating a reported AUR comment on pacman-static, found and fixed a real bug in scripts/check_aur_feedback.sh: a relative script_dir meant every aur_comments.py invocation failed silently (arch/arch/scripts/aur_comments.py, doubled path) whenever the script was run the normal way (from the toplevel dir). This means comment-fetching had been broken for an unknown period – only the RPC-based out-of-date flag checks were unaffected. Fixed by resolving script_dir to an absolute path up front. See memory/TOOLING_NOTES.md for the full writeup; a full historical re-check across all packages may be worth doing separately to surface anything missed while it was broken.

Regenerated the overview and republished the site afterward.

2026-08-29/30: full update cycle – linux-lts515, plus thruk prep

Ran update_cycle.sh: only linux-lts515 flagged (5.15.217 -> 5.15.219), check_dependencies.sh fully clean (0 unresolved across 640 entries). Also re-ran the now-fixed check_aur_feedback.sh across the whole tree – nothing new anywhere, confirming yesterday’s path-bug fix already caught everything.

linux-lts515: routine point release, all 4 archs built+published cleanly (multi-hour build as usual for this package). See memory/linux-lts515.md.

ARM cluster: confirmed down at the start of this session (ping to eurobuild3/4/5/14 all failed) – not needed for linux-lts515 (x86_64/ i686/pentium4/i486 only), but noted since repo_build.sh already degrades gracefully per-arch (a down/failed remote board doesn’t block signing/publishing the local archs that did build).

thruk (in progress): vendored mod_fcgid and perl-crypt-rijndael from AUR – the only 2 of thruk’s 18 dependencies not already official (down from the 2026-08-02 attempt’s larger cascade, since Arch’s own repos absorbed perl-plack/perl-log-dispatch since then). mod_fcgid’s known PGP-key blocker (see memory/mod_fcgid.md) still needs a real build attempt to get a current verdict – queued behind linux-lts515 (only one local chroot build at a time).

Also added a new Architectures column to OVERVIEW.md/the published site (per-package wished-vs-published status across every buildable arch), a legend explaining it, and a compact single-token rendering for arch=('any') packages instead of listing every arch individually. See memory/TOOLING_NOTES.md for repo_arch_diff.sh.

Overview/site regeneration deferred until thruk’s build sequence finishes (still mid-queue).

2026-08-30: cssh rebuild against new upstream commit

User asked for a rebuild after noticing cssh (their own upstream project) had moved past the published commit. Landed at 0.0.1.r22.g5892097-1 (was .r14.g6c92d89-2) after 5 build attempts, 3 real fixes needed: a missing #include <strings.h> in vendored 3rdParty/linenoise/linenoise.c (new standalone patch), two missing checkdepends (openssh for ssh-keygen, inetutils for hostname, both needed by the functional test), and a missing SSH identity for the test’s pubkey-auth round-trip (asked the user how to handle it since it’s about their own test suite’s assumptions, not a routine packaging gap – they chose generating a throwaway keypair in check()). See memory/cssh.md for the full writeup.

All 4 local archs published cleanly. ARM archs untouched – the eurobuild3/4/5/14 cluster was down for the entire session – still at the older r14 build there, a gap now visible via the Architectures overview column.

2026-08-30: mod_fcgid/perl-crypt-rijndael categorization fixes

User asked why these two (vendored yesterday to unblock thruk) ended up under maintained/ and checked AUR directly: neither is maintained or co-maintained by us there. Three iterations to land in the right place, each correcting the previous:

  1. maintained/ -> adapted/ (still as git submodules) – wrong, adapted/ packages are never submodules, and are specifically for a real local diff on top of upstream. Both were pristine, unmodified copies at that point.
  2. Moved out of arch/ entirely to the install_only_packages + /data/INSTALL/<name> plain-checkout pattern (local-install/ prefix, broadened slightly to also cover “AUR dependency pulled in to unblock another package’s build”, not just personal yay installs).
  3. While setting that up for mod_fcgid, found the user’s own prior 2026-08-05 work already sitting in /data/INSTALL/mod_fcgid: a local (never pushed) commit bumping pkgrel 5->6 and vendoring the Apache signing key that was blocking the build. User chose to revive it. That is a real local deviation, so mod_fcgid moved back into arch/adapted/ – this time correctly, as plain directly-tracked files, not a submodule. Rebuilt and published cleanly at 2.3.9-6. perl-crypt-rijndael stays in local-install/ (genuinely zero local changes).

Also fixed the root cause so this doesn’t happen again: scripts/add_maintained.sh’s logic moved into a new scripts/add_aur_package.sh <category> <pkgname>, with add_maintained.sh/new add_adapted.sh as thin wrappers. Adding under maintained now checks the package’s real AUR page (maintainer and co-maintainer, not just RPC’s primary-maintainer-only field) and refuses if we’re neither. Also fixed scripts/compare_packages.sh (existing but similarly-blind audit script) to be pkgname-aware (a package’s directory/pkgbase can differ from its AUR pkgname, e.g. keybinder2’s real pkgname is libkeybinder2 – checking the wrong name gave one false positive during today’s audit, since fixed) and co-maintainer-aware; a full re-run confirmed every other maintained/ package is correctly categorized. See memory/mod_fcgid.md, memory/perl-crypt-rijndael.md, and memory/TOOLING_NOTES.md (the arch/<category> taxonomy is now spelled out there explicitly) for the full detail.

2026-08-31: ARM cluster back up – cssh/perl-crypt-rijndael caught up

Cluster (eurobuild3/4/5/14) came back after being down the whole prior session. Prioritized cssh and thruk’s dependency chain per request; thruk itself (arch=('any')) and mod_fcgid (x86_64-only) needed nothing further, so the real work was:

cssh: rebuilt armv6h/armv7h/aarch64 from the stale r14 up to r22. armv7h was clean. aarch64 hit a real infrastructure issue on eurobuild14 – modprobe nbd failing because the running kernel didn’t match the already-installed linux-aarch64 package (a pending upgrade never booted into). Rebooted the board (user pre-authorized this for exactly this symptom), confirmed nbd loads post-reboot, retried – published cleanly. armv6h’s build succeeded but its functional test timed out waiting for the test’s own mock_sshd helper to start (a hard 5s wait, this being the slowest of the three boards) – user’s call: skip check() specifically on armv6h rather than patch the timeout or wait for an upstream fix. All 7 archs now published at r22.

perl-crypt-rijndael: built the armv7h/aarch64 it had been missing since the cluster was down during its original build. Clean, no issues. All 4 declared archs now published.

Also checked AUR comments across the tree per request: two independently-actionable items surfaced (a python2 PGP-key failure with a community-posted fix already available, and qt5-doc flagged out-of-date with its source download itself reported broken) – left for a future pass, not acted on this session. A third (pacman-static’s earlier OpenSSL-key thread) had already resolved itself via community help.

See memory/cssh.md and memory/perl-crypt-rijndael.md for the full detail, and memory/TOOLING_NOTES.md for the two cross-cutting findings (the NBD/reboot symptom, and REPO_BUILD_ONLY_ARCH not being an end-to-end single-arch guarantee for repo_publish.sh).