Updates — 2026-10-15 (libarchive-static, pacman-static, bacula7/bacula7-client, munin-libvirt-plugins)

libarchive-static, pacman-static: ARM builds for the zlib CVE fix, a real SSH-keepalive infra bug found+fixed, then a libarchive 3.8.10 bump across all 7 archs each

Once the ARM cluster (eurobuild4/5/14) came back up from the user’s reboot+update, picked up the two packages’ deferred ARM builds for 2026-10-14’s zlib CVE-2026-85091 fix (pkgrel 6/21). First attempt on libarchive-static failed on all three boards independently – Read from remote host <X>: Connection timed out / client_loop: send disconnect: Broken pipe, each at a different point in its own build. Root cause: remote_build_ssh() (scripts/remote_build_lib.sh) carries the entire multi-hour build over one SSH session with no keepalive – a quiet compile stretch lets an idle NAT/firewall timeout drop the connection, no fault on the board itself. Fixed by adding -o ServerAliveInterval=30 -o ServerAliveCountMax=6 to that one shared helper (used by every remote build, quick commands and the real build alike). Retried clean on both packages afterward: libarchive-static 3.8.9-6 and pacman-static 7.1.0.r9.g54d9411-21, all three ARM archs, confirmed via direct repo-db queries.

Then bumped libarchive-static’s own pkgver 3.8.9 -> 3.8.10 (upstream tagged this release on GitHub; pkgrel reset to 1) and, to match, bumped pacman-static’s bundled _libarchive_ver the same way (pkgrel 21 -> 22, packaging-only). Both rebuilt+republished across all 7 archs (i486/ i686/pentium4/x86_64 local, armv6h/armv7h/aarch64 remote) – confirmed live everywhere via direct repo-db queries both times. pacman-static’s armv6h leg alone took ~4h40m end to end (this package’s full bundled-dependency chain – nghttp2/curl/openssl/brotli/zlib/xz/bzip2/zstd/libarchive/ libgpg-error/libassuan/gpgme/libseccomp/pacman itself – compiled serially on that board), progress checked periodically via ssh <host> ps aux rather than waited out blind.

nvchecker exception, marked per user request: both packages’ bundled/ own libarchive version now runs ahead of Arch’s official core/libarchive package (still 3.8.9-1 as of this date) – pacman-static/nvchecker-deps.toml tracks it via archpkg (Arch’s own package), libarchive-static/.nvchecker.toml tracks libarchive’s real upstream directly, so the two deliberately diverge right now. Added an explanatory comment to the [libarchive] section of each file so a future session doesn’t mistake this for a regression and try to “fix” it by reverting – expected to self-resolve once Arch repackages 3.8.10 on their end. User’s call this round: don’t abort or hold up builds over this divergence. Full detail in each package’s own memory/*.md (2026-10-15 entries).

bacula7, bacula7-client: added armv6h/armv7h/aarch64 to arch=(), ARM build attempted and abandoned (real bug, not a hang)

Added the three ARM archs to both PKGBUILDs’ arch=() (armv6h already present in bacula7-client’s). Attempted the ARM build for bacula7 first (per explicit instruction: never run both packages’ ARM builds in parallel on the cluster) – failed on all three boards, but with real, reproducible build bugs, not a hang:

• armv6h/armv7h: identical compile error in src/findlib/fstype.c – error: narrowing conversion of '4283649346' from 'unsigned int' to 'int' [-Wnarrowing] (filesystem magic-number literals too large for a signed 32-bit int, hit because bacula’s Makefiles compile .c files with g++, so C++11’s stricter brace-init narrowing rules apply). Kills libbacfind.la, cascading into package_bacula7-common() failing outright. Did not reproduce on x86_64 earlier this session – likely a GCC-version/strictness difference between euronuc’s local chroot and these boards’ GCC 10.2.0.
• aarch64: unrelated – error: target not found: openssl-1.0 (dependency simply not available for aarch64 in this private repo).

Per the user’s explicit instruction (“if they fail, never mind… just continue with the plan and ignore bacula7 and bacula7-client”), not pursued further this session – no fix attempted, bacula7-client’s own ARM attempt was skipped entirely since it shares the same fstype.c code path. Both packages remain x86_64-only published. Full detail in memory/bacula7.md / memory/bacula7-client.md.

munin-libvirt-plugins: new maintained package, created/pushed/published same day

Side-tangent request: packaged Guido Günther’s munin-libvirt-plugins (4 Python3 Munin plugins for libvirt-managed VMs + a -detect autoconfig helper) – confirmed via the real AUR RPC API that no package by this or a similar name existed yet (a web-search summary falsely claimed one did; don’t trust that over the real API). Sourced from the exact git tag Debian itself packages (debian/0.0.7-1), since upstream only tags, never cuts GitHub Release tarballs.

Prepared PKGBUILD+.SRCINFO locally first (an AUR push is the user’s to do, never mine); user did the initial AUR push same day, making them maintainer of record. Converting the local plain directory to a proper git submodule hit a snag – the user had also independently run git submodule add themselves while setting up their own push, so a stale rm -rf of my plain directory nearly lost their submodule checkout; recovered cleanly with git submodule update --init, no data lost. First real chroot build then caught a genuine bug my earlier non-chroot makepkg -s test had missed: ERROR: Cannot find the git package needed to handle git sources – git was missing from makedepends (masked earlier only because git happened to already be installed on the host itself). Fixed, rebuilt clean, published 0.0.7-1 (an arch=any package, fans out to every arch automatically). Full detail in memory/munin-libvirt-plugins.md.

Updates — 2026-10-14 (libarchive-static, pacman-static)

libarchive-static, pacman-static: bundled zlib CVE-2026-85091 fix, Intel archs only

User asked for the zlib security patch upstream mentioned for these two static-recovery packages, both of which vendor-build their own zlib (_zlibver=1.3.2). zlib 1.3.1.2-1.3.2 has a heap buffer overflow in gz_vacate()/gz_write() reachable via gzprintf()/gzvprintf() after a non-blocking gzwrite() stall (CVE-2026-85091, CVSS 8.3) – there is no 1.3.3 tarball release fixing it, only an upstream git commit (df84af25dc1942490e1d1c899a07619152a46148). Confirmed this is the real, authentic fix (not a guess) by cloning Arch Linux’s own zlib packaging repo with pkgctl repo clone zlib: Arch applied the exact same commit as an unreleased-upstream patch, pkgrel-only bump (3 -> 4), and our downloaded patch’s sha512 matched their .SRCINFO byte-for-byte.

Added the patch (zlib-1.3.2-CVE-2026-85091.patch, committed locally in both package dirs) to source=()/checksums and applied it in prepare() right after each PKGBUILD’s existing openssl patch step. Packaging-only pkgrel bumps (libarchive-static 5 -> 6, pacman-static 20 -> 21), no pkgver change. Both PKGBUILDs have a case "${CARCH}" in i486|armv6h) block that hard-codes sha512sums array indices for git sources that can’t be sha512-checksummed on old pacman – inserting the new patch entry mid-array shifted every later index, so those overrides had to be bumped too (verified with paste against the regenerated .SRCINFO rather than counting by hand).

Built and published Intel architectures only per explicit request (REPO_BUILD_ONLY_ARCH="i486 i686 pentium4 x86_64") – the ARM build cluster (eurobuild4/5/14) is currently down; armv6h/armv7h/aarch64 deferred to a follow-up once it’s back up. libarchive-static built clean on the first pass, all 4 archs. pacman-static’s i686/pentium4 legs failed on a transient mirror.archlinux32.org connection timeout during chroot sync (unrelated to the PKGBUILD change – i486/x86_64 succeeded in the same run); retried just those two archs once mirror connectivity was confirmed back, succeeded immediately. Both packages confirmed live on all 4 Intel archs via a direct repo-db query (libarchive-static 3.8.9-6, pacman-static 7.1.0.r9.g54d9411-21). See memory/libarchive-static.md and memory/pacman-static.md for full detail.

Updates — 2026-10-14 (bacula7, bacula7-client)

bacula7 (renamed from bacula7-sd), bacula7-client: bumped to the final 7.4.x release, aligned versions, renamed the full-suite directory

Discussed with the user whether to chase current upstream Bacula (15.0.3 stable / 17.0.0 beta) – decided against it: the whole point of the bacula7-* naming is a frozen old major version for protocol/catalog compatibility with other 7.x Bacula installs, and a major-version jump would defeat that (and is a much bigger undertaking – protocol + catalog schema changes – than a point bump). Instead bumped both packages to 7.4.7, the final release of the 7.4.x branch (there is no 7.6/7.8; upstream jumped straight from 7.4 to 9.0 in 2017) – bacula7-client 7.4.3 -> 7.4.7, private/bacula7-sd (now private/bacula7, see below) 7.4.5 -> 7.4.7, so the two are no longer on different pkgvers. All existing patches (00-qmake4.patch, 01-basename.patch, 02-conio-termios.patch) and bacula7-client’s PGP signature re-verified clean against the new 7.4.7 tarball.

Also renamed private/bacula7-sd -> private/bacula7: its pkgbase was always bacula7 (a 7-subpackage split build: common/console/fd/sd/dir/+db backends), the directory name only ever matched the one subpackage (bacula7-sd) that happened to be the only one actually published – purely a repo-layout rename, no change to any published pkgname. Built + published both packages x86_64-only; publishing the new pkgver automatically archived/superseded the old 7.4.5/7.4.3 entries on the repo, so no separate depublish step was needed. User then removed private/bacula7-sd from git entirely (commit 311f134) now that private/bacula7 replaces it.

See memory/bacula7.md, memory/bacula7-client.md (new entries) and memory/bacula7-sd.md (superseded-pointer note, kept for its still-valid build-bug history) for full detail.

Updates — 2026-10-13 (bacula7-sd, bacula7-client)

bacula7-sd / bacula7-client: new private packages, ported from an old eurobuild3 local build

User asked to turn an old local Bacula 7 build sitting at /data/INSTALL/from_eurobuild3 (a bacula-sd full-suite build and a separate bacula-client client-only build) into proper private/ packages, build and publish them. Created private/bacula7-sd (split package: bacula7-common, bacula7-console, bacula7-fd, bacula7-sd, bacula7-dir, bacula7-dir-sqlite3, bacula7-dir-postgresql, from Bacula 7.4.5) and private/bacula7-client (Bacula 7.4.3 client-only bacula7-client, an alternative to bacula7-fd), renaming bacula/bacula-client -> bacula7/ bacula7-client to match this repo’s versioned-name convention for packages that would otherwise collide with a newer bacula from the AUR.

Hit and fixed three real, unrelated build bugs while getting these to build on this host (not just a rename): a stale --with-openssl=/usr/openssl-1.0 path (silently fell back to the system OpenSSL, breaking crypto.c – bacula7-sd), a missing #include <termios.h> in src/console/conio.c (broke bconsole linking in both packages – added 02-conio-termios.patch, reused in both), and a validpgpkeys fingerprint left over from an abandoned 9.0.4 upgrade attempt that didn’t match the actual 7.4.3 tarball signature (bacula7-client). Also dropped the never-actually-built bacula7-bat subpackage (upstream build() already passed --disable-bat), and, after an initial publish, added several runtime depends namcap flagged as missing (libcap, acl, openssl-1.0, zlib, perl, ncurses depending on the subpackage) across two follow-up pkgrel bumps.

Built and published clean for x86_64 only this round (per explicit request – i686 hit an unrelated 3+-hour chroot hang on the first attempt, see memory/bacula7-sd.md; arm/armv6h not attempted). See memory/bacula7-sd.md and memory/bacula7-client.md for the full detail on every fix above.

Updates — 2026-10-12 (hfsfuse)

hfsfuse: 0.466 -> 0.469

Found via a full check_for_updates_maintained.sh pass across all of maintained/ – the only real UPD flag out of 214 packages checked (rest were OK or unparsable version strings, unchanged from the last run). Routine upstream tag bump, no PKGBUILD changes needed. Built and published clean (x86_64). See memory/hfsfuse.md.

Updates — 2026-10-12 (qt5-nemo-qml-plugin-configuration)

qt5-nemo-qml-plugin-configuration: pkgrel 1 -> 2, drop /opt/tests to fix file conflict (AUR comment, Skaxen)

Found via a full check_aur_feedback.sh scan across maintained/private/owned/adapted. Skaxen reported a file conflict against the official (now Qt6) nemo-qml-plugin-configuration: both own identical paths under /opt/tests/nemo-qml-plugin-configuration-qt5/..., because upstream’s tests/tests.pro hardcodes that -qt5-suffixed path regardless of which Qt actually builds it. Fixed by dropping /opt entirely from package() rather than adding conflicts=/replaces= – these are upstream CI test files, not needed by any consumer, so removing them from packaging eliminates the collision outright. Packaging-only, pkgrel 1 -> 2. Built and published clean (x86_64). See memory/qt5-nemo-qml-plugin-configuration.md.

Updates — 2026-10-12 (freeimage)

freeimage: pkgrel 24 -> 25, jxrlib 1.4.4-3 header-layout fix (AUR comment, promano)

promano reported today that freeimage 3.18.0-24 fails against jxrlib 1.4.4-3: JXRGlue.h: No such file or directory. Confirmed jxrlib 1.4.4-3 (current extra/) moved its headers from /usr/include/jxrlib/ to /usr/include/libjxr/{common,glue,image,image/x86,test}/, and now ships a real JXRVersion.h there too (previously missing, which is why pkgrel 24 had a workaround synthesizing one).

Rather than hardcoding the new include paths as the commenter’s patch did, used jxrlib’s own libjxr.pc (it ships one, with correct Cflags/Libs, unused until now) via pkg-config --cflags/--libs ... libjxr in freeimage-unbundle.patch’s Makefile.gnu hunk – consistent with how that hunk already pulls in the other unbundled libs, and robust to any future jxrlib layout change. Removed the now-obsolete JXRVersion.h synthesis block from PKGBUILD (its path check would otherwise always fire again, since /usr/include/jxrlib/ itself is gone, needlessly shadowing the real shipped header).

Packaging-only fix (no pkgver change), pkgrel 24 -> 25 per [[feedback_pkgrel_vs_pkgver]]. Editing freeimage-unbundle.patch via the Edit tool stripped CRLF line endings from an unrelated hunk further down the file (one hunk intentionally mirrors PluginTIFF.cpp’s own CRLF, so patch can byte-match it) – first build attempt failed with “different line endings” / hunk FAILED on that hunk. Restored the original CRLF bytes for that block from git HEAD and recomputed the sha512sum; second build succeeded. Confirmed clean build via repo_release.sh maintained/freeimage (x86_64 only) and published without connection-failure strings in the full log. Did not reply on AUR – fix addresses the same root cause the commenter reported, matches [[feedback_obvious_fixes_no_aur_reply]].

Updates — 2026-10-12 (linapple-git)

linapple-git: new local-install package

Plain upstream AUR package (maintainer iyanmv), Apple IIe emulator. Built first as a trial (user’s request), confirmed clean (120/120 tests passed), then signed+published on follow-up. x86_64, 2026.10.10.g86bee1c2-1, no local edits. See memory/linapple-git.md.

Updates — 2026-10-12 (mod_maxminddb)

mod_maxminddb: new local-install package

Plain upstream AUR package (maintainer G4Zz0L1). An untracked checkout already existed in /data/INSTALL; backed up to -old, fresh-cloned, built+published clean, x86_64, 1.2.0-1, no local edits. See memory/mod_maxminddb.md.

Updates — 2026-10-12

nrpe: new adapted package, command-args + dont_blame_nrpe enabled

Forked the official Arch packaging-repo nrpe PKGBUILD (not currently synced to the live mirror; there’s also an unrelated AUR nrpe by someone else, deliberately not used). Added --enable-command-args to build() and a sed flipping dont_blame_nrpe=0 -> 1 in the shipped config, per explicit request – NRPE’s own SECURITY.md says both together are required and calls this a real security risk (arbitrary command arguments from clients). Verified on the actual published binary (nrpe --help’s security-risk banner + the packaged config), not just the build log. Built+published clean, x86_64, 4.1.2-1. See memory/nrpe.md.

Updates — 2026-10-11 (net-snmp-5.9.4)

net-snmp-5.9.4: new adapted package, pinned to the last release providing libnetsnmpagent.so.40.2.1

User needed libnetsnmpagent.so.40.2.1 specifically. Official net-snmp is now at 5.9.5.2 (.so.45.0.0) – a different soname. Bisected via git history alone (net-snmp’s Makefile.top sets the libtool version-info triplet explicitly per release, no actual build-bisection needed): 5.9.4 (2023-08-15) is the last real release providing this exact soname; the next release, 5.9.5, jumps straight to .so.45.

Confirmed with the user this should stay local-only (not a real new AUR submission, unlike the icu74-76 “legacy shim” packages) – created as adapted/net-snmp-5.9.4, a fork of the official Arch PKGBUILD pinned to the v5.9.4 git tag. package() keeps only the real versioned .so.40.2.1 library files (same “libraries-only coexistence” pattern as the icu7x shims) so it doesn’t conflict with the official net-snmp package.

First build: namcap caught a real missing dependency (libxcrypt). Fixed, pkgrel 1 -> 2, rebuilt+republished clean, x86_64, 5.9.4-2. See memory/net-snmp-5.9.4.md for the full soname bisection writeup.

Updates — 2026-10-11 (php74-redis + php74-igbinary)

php74-redis, php74-igbinary: new local-install packages

Both plain upstream AUR packages (maintainer tompear). php74-redis’s first build failed on a missing dependency, php74-igbinary (also not previously tracked) – built that first, then php74-redis built+published cleanly with its full Redis-backed test suite passing. Both x86_64, no local edits. See memory/php74-redis.md / memory/php74-igbinary.md.

Updates — 2026-10-11 (icu72/icu73)

icu72, icu73: new local-install packages

Both plain upstream AUR packages (maintainers a821 and hinanoaira), not previously tracked in arch/ – same local-install/ category as icu77.

• icu72: no prior checkout existed. Fresh AUR clone, PGP key refresh (validpgpkeys present), built+published clean, x86_64 only (upstream’s own arch=()), 72.1-2, no local edits.
• icu73: a stale 2024 checkout already had i486/i686/pentium4 (+debug) pre-built at 73.2-1 (upstream AUR is now at 73.2-7). Per explicit instruction, republished those existing builds as-is rather than rebuilding against the newer PKGBUILD – backed up to icu73-old, signed+published the existing packages, then moved back to icu73. Also built the missing x86_64 arch fresh (in a scratch dir, consolidated back into icu73 afterward). All 4 arches now published.

Both added to scripts/install_only_packages. See memory/icu72.md and memory/icu73.md.

Updates — 2026-10-11

http-parser: new local-install package

Not previously tracked in arch/ – a plain upstream AUR package (maintainer Caleb Maclennan), found already installed locally via yay. Added via the established local-install/ workflow: fresh clone from AUR, repo_release.sh, added to scripts/install_only_packages. Built+published cleanly first try, 2.9.4-2, x86_64 (upstream’s own arch=(), no local edits). See memory/http-parser.md.

Updates — 2026-10-10 (continued again)

lunduke-paint-git: root-caused and published

Investigated the 2 check() failures left open from the Lunduke batch above. Both are confirmed upstream test bugs, not packaging defects (verified by reproducing outside the chroot with a stock host build, and checked upstream’s GitHub directly – no fix there yet):

• test_release_binary bans the literal substring /workspace to catch a leaked CI build path, but the project’s own src/doc/workspace.cpp makes that substring appear in any build’s debug info – a false positive by construction, unrelated to our build.
• test_ora’s hand-crafted “animated GIF” test fixture has a malformed Global Color Table size that corrupts the GIF structure; Arch’s current gdk-pixbuf2 (glycin GIF decoder) correctly rejects it where the old loader tolerated it.

Excluded both from check() (same pattern as the existing test_text_box exclusion), pkgrel 2 -> 3. Built+published cleanly: r87.e451ff3-1. See memory/lunduke-paint-git.md for the full root-cause writeup.

Lunduke software: rebuild + publish, x86_64

Rebuilt the 3 Lunduke packages (maintained/lunduke*) at the user’s request:

• lunduke-edit-git (r35.eb30760-1): routine rebuild, clean (the 2026-10-05 corrupted-cache issue was indeed transient, plain retry worked).
• lundukecity-git (r37.933f826-1): upstream added 6 new UI tests that now hard-fail (not skip) without a real DISPLAY. Fixed in two steps, both confirmed with the user first: wrapped check() in xvfb-run (project precedent: python2’s PKGBUILD) + checkdepends=('xorg-server-xvfb') – recovered 4 of 6 tests. The remaining 2 (argv_open: a test-asset-path issue loading a saved city; ui_round7: no D-Bus session bus in the chroot) were excluded via meson test --exclude, both commented inline. pkgrel 1 -> 2. See memory/lundukecity-git.md.
• lunduke-paint-git: retried despite its known 2026-10-05 check() failure. Build succeeded but hit 2 different new test failures this time (test_release_binary: binary embeds a /workspace path; test_ora: multi-frame GIF/animation handling regression) – the old jpeg failure is gone. Not published – flagged back to the user rather than guessing at either fix. See memory/lunduke-paint-git.md.

Also hit intermittent DNS SERVFAIL on the repo host’s own hostname (archlinux32.andreasbaumann.cc) and mirror.init7.net mid-batch – resolved on retry each time, consistent with the LAN’s general flakiness earlier this session (euroweb.lan outage).

Full update cycle + 5 -git packages built and published, x86_64

Ran update_cycle.sh (cleanup, fetch/fast-forward, UPD check, adoptable-package scan, dependency check): 0 packages need a version bump (0 UPD lines, 129 OK, 81 ? with no .nvchecker.toml), 0 unresolved dependencies out of 747, no adoptable candidates.

repo_diff_local_remote.sh additionally flagged 22 -git/-svn packages as CHANGED-VCS (their locally-recorded pkgver is stale, not a trustworthy signal – see that script’s own header) and 4 never-published packages (libisl, linux-lts510, linux-lts510-headers, linux-lts510-docs). Reported to the user; left untouched per their explicit choice (linux-lts510 in particular has a standing memory note to check with the user before touching it).

Built and published 5 of those -git packages at the user’s explicit request, x86_64 only:

• slimcc-git (r1156.374082f-1): routine rebuild, clean.
• tnylpo-git (r239.6bf0106-1): routine rebuild, clean on x86_64; i686/pentium4 failed on local mirror timeouts, armv7h/armv6h/aarch64 failed because the remote boards’ shared NBD server (eurobuild3) was unreachable – infra, not package bugs. See memory/tnylpo-git.md.
• trojita-git (0.7.r1020.gd4a87c61-1): routine rebuild picking up real new upstream commits, clean.
• vhd2vl-git: rebuild recomputed to the same version already on the repo (no real new upstream content) – republished anyway, clean.
• xxdiff-git (r552.b455827-1): routine rebuild, clean on x86_64; same infra failures as tnylpo-git on the other archs.

Running all 5 repo_release.sh calls in parallel caused two transient publish-lock collisions (slimcc-git, tnylpo-git) – recovered by re-running repo_publish.sh directly on the already-signed files once the lock cleared. See memory/feedback_no_parallel_publish.md (cross-session memory) for the process note.

Overview/site regeneration still pending: the repo host (euroweb.lan) is currently unreachable on the LAN (ping/ssh both fail with “No route to host” / “Destination Host Unreachable”) – a real network-level outage, not a script issue. All 5 packages are already built, signed, and published (verified in each release log); only generate_overview.sh/generate_site.sh/ publish_site.sh are blocked until that host is reachable again. Will retry.

Full -git batch: build+publish all VCS packages, x86_64 only

User asked to build and publish every -git package across the tree. Scope (confirmed with user): the 41 -git submodules tracked under arch/maintained/+arch/adapted/, plus the 7 genuine local-install/*-git packages (bare upstream AUR checkouts, re-cloned fresh each run) – 48 packages total, x86_64 only (REPO_BUILD_ONLY_ARCH=x86_64), via repo_release.sh per package (these are explicitly skipped by the routine repo_release_changed.sh cycle – see that script’s own header comment – so this was the “release them explicitly” path it points to).

43 of 48 published this session (40 clean on the first pass + 3 more after a targeted fix+retry). 5 left broken, 2 of those permanently out of our control.

Fixed and republished

• jwm-git (s1685.r187.ba12b4f-1): Arch’s automake bumped to 1.19; PKGBUILD hardcoded /usr/share/automake-1.18/... paths for config.guess/config.sub/etc. Bumped the paths to -1.19, pkgrel 2->3.
• tnylpo-git (r239.6bf0106-1): upstream replaced their plain Makefile with build.sh+makefile.mk; build() now runs sh build.sh instead of bare make. Verified by compiling standalone before touching the PKGBUILD. pkgrel 1->2.
• lunduke-edit-git (r16.a756576-1): transient corrupted-cache download (pacman self-healed by deleting it); plain retry succeeded, no PKGBUILD change.
• adtpro-git (2.1.0.r17.g3580637-3): our own vendored jdk10 (EOL Oracle JDK, provides java-environment=10) was winning the java-environment tie-break over modern OpenJDK, and current ant can’t classload under it (ClassNotFoundException: org.apache.tools.ant.ExitStatusException). Pinned jdk21-openjdk in makedepends (user’s call) so it’s already satisfied before ant installs. pkgrel 2->3.
• llvm-mos-git (r601853.0f031168a7cc-1) – first successful publish ever for this package. Root cause: Arch’s host CFLAGS/CXXFLAGS/LDFLAGS (-march=x86-64, -flto, etc.) were leaking via the environment into CMake’s cross-compilation sub-build for the freestanding 6502 mos-unknown-unknown target, which rejects those flags outright. Fixed with unset CFLAGS CXXFLAGS CPPFLAGS LDFLAGS before the cmake invocation. pkgrel 2->3. Retry (user’s call, ~1h50m) confirmed the fix.
• lunduke-paint-git (r74.9c081cb-1): test_text_box (jpeg write/preview) started failing after +22 upstream commits; cause not investigated. User’s call: skip just that test (meson test ... $(meson test -C build --list | grep -v ':text_box$')) rather than block the rebuild on it. pkgrel 1->2.

Left broken (not fixable in this tree)

• fluxengine-git: upstream migrated their entire build system to Bazel back in September; already a known, deliberately-unresolved break per the 2026-09-08 decision. Re-confirmed, no new action.
• odin-git: Odin’s build_odin.sh only accepts LLVM 17-22; Arch’s extra/llvm is already at 23.1.1 with no versioned fallback binaries. Confirmed even AUR’s current odin-git PKGBUILD hasn’t addressed this. Not patchable here – local-install/ packages re-clone upstream’s PKGBUILD fresh every cycle, so any local fix would be wiped immediately. Self-resolves whenever odin-lang bumps its supported LLVM range.

A mid-session hazard worth remembering: launching 3 retry builds concurrently is safe for the build step (makechrootpkg’s own chroot lock serializes them), but not for the final repo-add step – that lock fails fast instead of waiting, so 2 of the 3 publishes raced and had to be retried by hand afterward (repo_publish.sh again on the already-built, already-signed local package files). No data lost, just required noticing the lockfile errors and rerunning repo_publish.sh directly.

The other 34 tracked + 6 local-install packages built and published cleanly with no PKGBUILD changes needed. Overview + site regenerated and republished twice (once after the main 48-package pass, once more after the 3 retries).

Full update cycle: 1 UPD package (linux-lts515), routine point release

update_cycle.sh flagged only linux-lts515 (5.15.221 -> 5.15.222) as needing an update; every other maintained package was OK or ? (stalled by check_exceptions). scan_adoptable_packages.sh found 4 new adoption candidates (buildbtw-poc, haskell-generic-data, netfilter-fullconenat, vkcheck) – left for manual review, not acted on (adoption is a human sign-off step per project policy). check_dependencies.sh found 0 unresolved dependencies across all 743 checked.

linux-lts515: routine point-release bump via update.sh 5.15.222. All 4 archs’ config diffs were cosmetic (version header + a toolchain CONFIG_PAHOLE_VERSION string bump only), pkgrel stayed at 1. Before updating, checked whether 5.15.222’s upstream changelog fixes the known 5.15.221 boot regression flagged in our own 2026-09-24 AUR comment (root filesystem fails to mount, void-packages#62643) – it does not: no ext4/mount-related commits in 5.15.222 at all, so the regression (suspected cause: ext4 commit 7461c60b9c6a) almost certainly carries forward. Proceeded with the build anyway since this is a routine version bump regardless. Built+published via repo_release.sh (MAKEFLAGS=-j6) across all 4 archs – all 12 files (3 pkgnames x 4 archs) uploaded cleanly, confirmed via full-log grep (no connection-failure strings, no real build errors – the handful of “Segmentation fault” lines were a harmless fakeroot self-upgrade glitch during chroot sync, unrelated to the actual package build) and repo_arch_status.sh showing all 4 archs published (5.15.222-1). Build times this run were notably faster than the prior 5.15.221 cycle (x86_64 1h18m vs 2h3m) – not investigated further, just noted. See memory/linux-lts515.md.

Updates — 2026-10-02

ladybird: simdjson ABI rebuild uncovered a Rust 1.99 toolchain break, both fixed

eurobuild6 hit libsimdjson.so.33: cannot open shared object file – simdjson is vendored via vcpkg (not a system depends()), and eurobuild6 had updated to simdjson 5.0.1-1 (soname bump) while the build host (euronuc) was still on 4.6.11-1. Fixed by updating euronuc first, then rebuilding so vcpkg re-vendors the matching simdjson – no PKGBUILD change needed for this part.

That same system update also bumped Arch’s rust/cargo package to one shipping Rust 1.99.0, which deprecated Atomic::fetch_update (now try_update) – broke Ladybird’s own LibWeb/Rust crate at 3 call sites, unrelated to simdjson. Confirmed upstream hadn’t fixed this yet (too recent, Rust 1.99 is 4 days old). Added 3 small patches renaming fetch_update -> try_update (identical semantics). pkgrel 1 -> 3 across both fixes (packaging-only). Rebuilt clean, published 20260918-3 for x86_64 (1h43m). Still needs real-world confirmation that eurobuild6 now launches cleanly. See memory/ladybird.md.

Also investigated (not fixed, by user’s call) a third SIGILL report on eurox, a 2008 Core2 Duo that doesn’t clear even x86-64-v3’s -v2 baseline – documented only, see memory/ladybird.md.

Update: the simdjson/Rust fixes above didn’t actually fix eurobuild6 – the real cause was that package() never shipped vcpkg’s vendored shared libraries at all (confirmed via ldd directly on the build host itself, not just eurobuild6). Fixed properly: bundled all of vcpkg_installed/.../lib into usr/lib/ladybird/ + patchelf --add-rpath on all 6 binaries. pkgrel 4, published 20260918-4, verified for real this time (210 .so files shipped, ldd fully clean on both Ladybird and WebContent). See memory/ladybird.md.

Updates — 2026-10-01

Full update cycle: 3 UPD packages, routine version bumps

update_cycle.sh flagged mdcat (2.17.0 -> 2.18.0), thunderbird-esr-bin (153.3.1 -> 153.4.0), and thunderbird-esr140-bin (140.16.0 -> 140.17.0). All three were routine point-release bumps – PGP keys checked proactively (unchanged), FEEDBACK.txt threads already answered, no new AUR comments. All built+published cleanly. mdcat’s dependency tree has grown substantially since the last build (now pulls in SVG/image rendering via resvg/tiny-skia/ratatui-image, ~300+ crates). See memory/mdcat.md, memory/thunderbird-esr-bin.md, memory/thunderbird-esr140-bin.md.

(Operational note: the session’s backgrounded-bash task mechanism got killed repeatedly for thunderbird-esr140-bin’s build for unknown reasons – worked around with a detached nohup ... & disown process polled directly by PID, used for every long build this session afterward. See memory/thunderbird-esr140-bin.md.)

pacman-static + libarchive-static: bundled openssl 3.6.4 -> 3.6.5, all 7 archs each

User-requested bundled-dependency bump, packaging-only (pkgrel bumps). Both built+published cleanly across all 7 archs (i486/i686/pentium4/ x86_64 local + armv6h/armv7h/aarch64 remote via eurobuild4/5/14). libarchive-static’s first pass hit a transient network blip reaching the private repo host for 3 of the 4 local archs (i686/pentium4/x86_64) – retried cleanly once connectivity recovered. armv6h took ~5h38m (pacman-static) and ~3h38m (libarchive-static), both matching historical baselines for this board – not a hang. See memory/pacman-static.md, memory/libarchive-static.md.

ladybird: recovered from accidental deletion, rebased to fix a real SSL bug

arch/adapted/ladybird had been deleted by cleanup_all.sh (moved there from local-install/ earlier but never git added, so it looked like untracked build cruft) – recovered from the surviving /data/INSTALL/ladybird build checkout; still needs git add adapted/ladybird adapted/README to stop this happening again.

Separately, user reported a runtime SSL CA-cert error (Problem with the SSL CA cert, curl error 77) – root-caused to a known upstream Ladybird bug (Landlock sandbox blocking the real, symlinked CA bundle on Arch/Fedora/openSUSE, ladybird#10241). A real fix had already landed upstream (PR #12092, merged 2026-09-18) but postdated our pinned commit (2026-09-01). Rebased the pin to df15885 (2026-09-18, the fix commit) rather than latest master, to scope the jump to just the known fix. pkgver 20260901 -> 20260918, pkgrel reset to 1. All 3 local patches applied cleanly against the new commit despite 17 days of upstream churn; built+published clean for x86_64 (2h31m). Actual symptom fix still needs real-world confirmation from the user. See memory/ladybird.md.

Updates — 2026-09-16

thunderbird-esr140-bin: 140.15.0 -> 140.16.0, published on all 3 archs

Routine point release for the Mozilla binary package (updpkgsums, no bespoke checksum logic). Built+published cleanly across x86_64/pentium4/i686. First real build to exercise the new site build-status instrumentation end-to-end. See memory/thunderbird-esr140-bin.md.

oksh + cssh: removed ancient generic arm subarch, rebuilt+published all 7 archs each

User committed packaging-only changes dropping the never-buildable arm entry from both PKGBUILDs (pkgrel bumps only). Rebuilding oksh’s ARM archs (armv6h/armv7h/aarch64) surfaced a real bug in repo_build_remote.sh: all three boards had rebooted with /data unmounted, and the per-board build lock’s own mkdir (under /data/INSTALL/) ran before the existing mount-ensure step, so the resulting ENOENT got misreported as “already building something else” – indistinguishable from real contention on every retry. Fixed by reordering the mount-ensure step before the lock acquisition. Both oksh (7.9-3) and cssh (0.0.1.r25.g6bd0546-2) then built and published cleanly across all 7 archs (4 local + 3 ARM remote). See memory/oksh.md, memory/cssh.md, and memory/TOOLING_NOTES.md’s 2026-09-16 entry for the full bug story.

linux-lts515: 5.15.220 -> 5.15.221, published on all 4 archs

Routine point release. update.sh 5.15.221 got interrupted by an unrelated 10-minute command timeout partway through (x86_64/i686/i486 config reconciliation already done, pentium4 not yet started) – finished pentium4’s reconciliation and the script’s remaining checksum/.SRCINFO steps by hand rather than rerunning it (which would have short-circuited on the already-bumped pkgver). All 4 archs’ config diffs cosmetic-only (version header only), pkgrel stayed at 1. Built +published via repo_release.sh with MAKEFLAGS=-j6 on every local arch: x86_64 2h3m, pentium4 2h21m, i686 2h23m, i486 2h31m. All 12 files (3 pkgnames x 4 archs) uploaded cleanly, confirmed via full-log grep (no connection failures) and repo_arch_status.sh against the live remote repo. See memory/linux-lts515.md.

Full AUR update-check cycle (update_cycle.sh)

Ran cleanup_all.sh + fetch_ff_maintained.sh + check_for_updates_maintained.sh

• scan_adoptable_packages.sh + check_dependencies.sh. Only linux-lts515 (above) needed a version bump. Dependency check clean (655 entries, 0 unresolved). 3 adoption candidates flagged by the buildmaster checker (jupyter-nbclassic, jupyter-server-mathjax, mathjax2) all already have live AUR pages (checked directly against aur.archlinux.org, HTTP 200) – the checker’s own daily-cached page was stale, not real candidates, no action taken.

New site page: “Currently Building”

Added a live-ish build-status page to the site (static-status-file + republish-on-interval design): repo_build.sh now writes/clears a small file per running (package, arch) build under the new toplevel build_status/ dir; generate_site.sh --current-builds is a fast path that re-renders just site/current-builds.html from those files (self-healing – a dead-PID entry is dropped, not shown); new scripts/watch_current_builds.sh loops that fast path + publish on an interval while a build is in progress. Verified against synthetic status entries (table rendering, elapsed time, stale cleanup, empty state) before relying on a real build – which then surfaced a real gotcha: editing repo_build.sh while an invocation of it already had the file open meant that entire invocation (all 4 linux-lts515 archs, not just the one in progress at edit time) ran the pre-edit code for its whole ~8.5h lifetime, so this feature’s first real exercise is still pending, next build onward. See memory/TOOLING_NOTES.md.

Updates — 2026-09-13

git-wd40: armv6h doc-skip + armv7h PATH fix published, recovered a mid-session data-loss incident

Both fixes confirmed in a real release: armv6h’s doc/man skip (RAM-OOM avoidance) and armv7h’s pod2man PATH fix (remote_build.sh now adds core_perl/vendor_perl/site_perl to PATH, general fix for non-interactive ssh sessions). Also recovered from a self-inflicted mid-session incident – a second concurrent repo_build_staged.sh invocation for this package wiped the first one’s not-yet-published i486/x86_64/aarch64 output; fixed structurally with a new per-package staging lock in repo_build_staged.sh (mirrors the per-board remote lock added the same session). Final state: i486/x86_64/armv6h/armv7h/ aarch64 published at pkgrel=2; i686/pentium4 still blocked by an unrelated upstream glib2 lag. See memory/git-wd40.md and memory/TOOLING_NOTES.md.

Updates — 2026-09-12

setserial: expanded to all 7 archs

Was x86_64/i686 only. Portable C, regenerates its own configure via aclocal/autoconf every build (no stale-config.guess exposure like rxvt). Purely additive, no pkgrel bump. All 7 archs built and published cleanly. See memory/setserial.md.

shmux: filled in i686/armv6h publish gap

User noticed arch=() (set in 2019) didn’t match what was actually published – only x86_64/armv7h/aarch64 were live, i686/armv6h never built through this pipeline at all (no failure on record, just never attempted). Built both with REPO_BUILD_ONLY_ARCH="i686 armv6h", no PKGBUILD changes needed. All 5 declared archs now published. See memory/shmux.md.

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

• PASS: litehtml0.9, python2, qt5-webview.
• FAIL: adapted/linux-lts510 (same pre-existing missing-patch blocker as 2026-07-07/08-02, not a new regression – see memory/linux-lts510.md) and maintained/trojita (a genuinely new blocker: gpgmepp’s headers now require C++17 for std:: string_view, but trojita’s own code uses std::binary_function, removed in C++17 – a real fix needs a C++17 bump plus a source rewrite, not a one-line patch; an initial “just add the missing include” attempt was tried, found not to work, and cleanly reverted rather than left half-fixed. See memory/trojita.md).

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

2026. 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:

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

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

2026-09-17: basic256 extended to i686

basic256: PKGBUILD already declared arch=('i686' 'x86_64') but i686 had never actually been built/published. First i686 build failed linking with undefined icu76-suffixed symbols – same root cause already seen on qgpgme-qt5/trojita-qt5-git: the i686 chroot’s system Qt5Core.so needs the legacy icu76 soname, undeclared anywhere in the chain. Fixed with makedepends_i686=('icu76'), pkgrel 3 -> 4, and regenerated a stale .SRCINFO (still listing pkgrel=2 and a since-removed espeak depend). Hit a transient outage of the private repo host mid-rebuild (unrelated to the fix); retried once it came back. Both i686 and x86_64 now built, signed, and published at 2.0.99.10-4. See memory/basic256.md for detail.

Further extended to i486/pentium4 (pkgrel 5): pentium4 built and published cleanly with the same icu76 makedepend. i486 hit a different, unresolvable-for-now blocker – its system Qt5Core.so needs icu72 specifically, and no icu72 package exists for i486 in any configured repo.

User decided not to chase building against such an old Qt/icu72 combination for i486 – removed i486 from arch=() entirely (pkgrel 6) instead of leaving it declared-but-broken. Rebuilt and republished i686/x86_64/pentium4 at 2.0.99.10-6; all three confirmed published. Final supported archs: i686, x86_64, pentium4.

2026-09-18: basic256 upstream moved to Qt6 – split into basic256 + basic256-qt5

AUR flagged basic256 out-of-date with a comment pointing at a new “v2.2.0” release. Verified against real upstream rather than trusting the comment: the project moved off SourceForge entirely to github.com/uglymike17/basic256, switched its build system from qmake to CMake, and made Qt6 mandatory (Qt5 no longer supported, confirmed across every GitHub tag including the earliest one) – license also changed GPL2 -> GPL3.

basic256: rewritten for v2.2.0 – GitHub source, CMake build, Qt6 deps, GPL-3.0-or-later. Handles upstream’s Modules/ runtime lookup (resolved relative to the executable’s own directory, not a system data dir) by installing it next to the binary. Built and published for x86_64 only so far, per explicit user decision – i686/ pentium4 not yet attempted for the Qt6 line (Qt6 packages do exist for both on archlinux32, so it should be viable later).

basic256-qt5 (new package): a Qt5 fallback for systems without Qt6, per user request. Turned out to be exactly the old basic256 package verbatim (SourceForge 2.0.99.10, qmake, Qt5) just renamed – checked GitHub’s full tag history and confirmed there’s no newer, still-Qt5 commit to bisect down to; SourceForge’s 2.0.99.10 already is the last Qt5 release. provides/conflicts basic256 (can’t coexist with it). Built and published on i686/x86_64/pentium4 at 2.0.99.10-1, first try, no new issues. Not yet an AUR submodule – exists only in this tree/our private repo until the user submits it to AUR themselves.

See memory/basic256.md and memory/basic256-qt5.md for full detail.

2026-09-19: icu74/icu75/icu76 LICENSE checksum fix; new icu77 local-install

icu74: AUR comment (nanoka, 2026-09-18) reported the LICENSE checksum failing again – third recurrence of the same bug (Feb/May 2025). Root cause: source= fetched icu74-LICENSE from GitHub’s moving main branch instead of a pinned ref, so the checksum goes stale whenever upstream touches that file. Fixed by pointing at the same release tag already used for the source tarball (raw/release-${pkgver//./-}/LICENSE), which self-updates on every version bump and can’t drift again. pkgrel 10 -> 11, built + published x86_64. No AUR reply posted (obvious fix, matches how the prior recurrence was handled).

icu75, icu76: same exact bug (identical source= line, copied across all three) – both were already silently broken before anyone reported it, caught by checking the siblings after fixing icu74. Same tag-pinning fix applied. icu75 pkgrel 9 -> 10, icu76 pkgrel 1 -> 2, both built + published x86_64.

icu77 (new, local-install/icu77, not maintained/): icu77 is already taken on AUR by a different maintainer (hinanoaira), so this does NOT extend the icu74/75/76 “we own this shim” pattern. Per user request, built and published anyway via the local-install workflow: fresh clone of the real AUR icu77.git, arch=(x86_64) expanded to arch=(x86_64 i486 i686 pentium4), pkgrel 3 -> 3.1. Built + published clean on all 4 archs (+ debug variants).

Tooling findings (not fixed, flagged for later): (1) repo_build.sh’s arch parser only matches a single-line arch=(), so icu74/75/76’s multi-line arrays were silently falling back to “any (via x86_64)” – meaning their other declared archs (i486/i686/pentium4/armv6h/armv7h/aarch64) have likely never actually been built via this pipeline. (2) repo_build_staged.sh’s staging rsync has no --delete, so a stale source file removed from a tracked arch/ pkgdir can silently survive in /data/INSTALL/<pkg> and get reused on the next build – hit this directly with icu75/ icu76’s stale LICENSE files, which had to be removed by hand before the fixed PKGBUILD would actually take effect.

See memory/icu74.md, memory/icu75.md, memory/icu76.md, memory/icu77.md for full detail.

2026-09-19: full update cycle – thunderbird-esr-bin 153.2.0 -> 153.3.1

Ran update_cycle.sh (cleanup, fetch/fast-forward every maintained/ submodule, upstream version check, adoptable-package scan, dependency check). Only one UPD flag: thunderbird-esr-bin. Routine bump, updpkgsums + repo_release.sh, no issues, published x86_64. No new AUR feedback on this package. See memory/thunderbird-esr-bin.md.

2026-09-19: android-file-transfer (new package, maintained/android-file-transfer)

Created from scratch from whoozle/android-file-transfer-linux, v4.5 stable release. Fills the gap between the existing android-file-transfer-git (VCS, maintained by someone else) and the orphaned android-file-transfer-cli (stable, CLI-only): this is the stable-release Qt GUI + CLI + FUSE-mount

• MTPZ build. Test build (namcap) needed readline/file added to depends. Built + published clean on x86_64 (+ debug package); aarch64 skipped this round – remote board eurobuild14 failed with “NBD server eurobuild3 is not reachable”, an infra issue, not a package problem. Retry aarch64 once that’s back.

Note: the AUR git repo for this pkgname wasn’t empty – it held real abandoned history from an unrelated old package (yaroslav’s android-file-transfer 2.4, delisted from AUR’s DB but not purged from git). Per user’s decision, kept that history and added ours as a new commit on top rather than rewriting it. Git commit/push (both inside the submodule, to actually create/revive it on AUR, and in the superproject to record the new submodule) is still pending – left for the user, per project policy. See memory/android-file-transfer.md.

2026-09-19: android-file-transfer-git (new, local-install/android-file-transfer-git)

Companion to the above: the VCS/git build of the same upstream, maintained on AUR by someone else (FabioLolix) – built+published unmodified via the local-install workflow (not vendored as maintained/ or adapted/, since we don’t maintain it and it wasn’t already locally installed). x86_64 built + published clean (4.5.r7.g8892693-1 + debug). i686 failed: the i686 chroot’s qt6-tools (uic/rcc/lrelease) are linked against libicui18n.so.75, missing/ mismatched in that chroot – an ICU/Qt6 ABI problem in the chroot itself, not a PKGBUILD bug, so left unbuilt for i686. Added to scripts/install_only_packages. See memory/android-file-transfer-git.md.

2026-09-19: jmtpfs (new, local-install/jmtpfs)

Plain AUR package maintained by someone else (miki), built+published unmodified via local-install – x86_64 only, per user’s note the ARM cluster is down (REPO_BUILD_ONLY_ARCH=x86_64, skipping the declared armv7h arch rather than let it fail/hang against a dead board). Built + published clean (0.5-3 + debug). namcap flagged a real missing dep (file/libmagic) in their PKGBUILD – not fixed, since this is vendored as-is, not ours to patch; noted for reference. Added to scripts/install_only_packages. See memory/jmtpfs.md.

2026-09-21: botan2, lib32-sdl2-compat (new, local-install/)

Two packages yay -Qu flagged as outdated on euronuc that weren’t tracked under arch/; rebuilt+published unmodified via the local-install workflow.

botan2 (Ľubomír Kučera’s AUR package): x86_64 only, no local edits. Its pkgver tracks a pinned upstream git commit via git describe rather than a tagged release, so it’ll show up in yay -Qu again whenever the AUR maintainer next advances the pin – expected, not a problem. Built + published clean (2.19.5.r22.g409ab81-1 + debug). Hit an operational snag mid-session (an orchestrating repo_release.sh got killed by mistake while its child build kept running to completion as an orphan, so sign+publish had to be finished by hand afterward) – no package-level issue, see memory/botan2.md.

lib32-sdl2-compat (HurricanePootis’s AUR package): x86_64 only, no local edits, validpgpkeys present (Sam Lantinga’s key, already trusted). First build attempt failed outright – its lib32-sdl3 dependency lives in the official multilib repo, which the archlinuxaba-x86_64 build chroot’s pacman config never enabled. Fixed with the user’s go-ahead by adding a [multilib] section to arch/config/pacman.conf.d/archlinuxaba.conf (confirmed this only affects the x86_64 chroot – i486/i686/pentium4 each have their own override file, untouched by this change). Retried and published clean (2.32.72-1 + debug). See memory/lib32-sdl2-compat.md for the full writeup, including an open question about how a different lib32 dependency (grub-legacy’s, back in August) resolved before this fix existed.

Both added to scripts/install_only_packages.

2026-09-24: regexxer (rebuild+publish, maintained/)

Not update-flagged (STATES.txt already had it OK at 0.10/0.10) – just a requested rebuild+publish of the current PKGBUILD. x86_64 only, no PKGBUILD changes. Built clean via repo_release.sh: 0.10-15 + debug, replacing a stale 0.10-13 that was live on the repo. Found and removed a leftover stale 0.10-13 package file in the /data/INSTALL/regexxer staging dir before building. See memory/regexxer.md.

2026-09-24: downgrade (new, local-install/)

Plain AUR package (Patrick Brisbin), first-ever publish to archlinuxaba – requested directly, not yay -Qu-flagged. /data/INSTALL/downgrade held a stale yay checkout+build at 12.0.2-1; backed it up to -old, fresh-cloned upstream (12.0.3-1, arch=('any'), no local edits/patches), built+signed+ published clean via repo_release.sh. As an any-package it built once and got symlinked into every other arch’s repo db. Removed the -old backup after publish succeeded. Added to scripts/install_only_packages. See memory/downgrade.md.

2026-09-28: ARM cluster back up — openssl-1.1 (armv7h+aarch64), lacc-git (i486/i686/pentium4 added)

With eurobuild4/5/14 + their NBD server (eurobuild3) confirmed reachable again, surveyed the whole tree for arm-arch backlog. Also fixed a real bug in scripts/repo_diff_local_remote.sh along the way: its arch-suffix regex never matched armv6h/armv7h/aarch64, so any arm-arch query reported bogus NEW verdicts for packages already published there (doesn’t affect the routine x86_64 changed-only release cycles, which never pass an arch arg).

openssl-1.1 (adapted/): first-ever armv7h+aarch64 build attempt. Both legs were reported FAILED by repo_build.sh, but that verdict was wrong – root-caused to a second, more interesting bug: this PKGBUILD’s pkgver=${_ver/[a-z]/.${_ver//[0-9.]/}} line broke remote_build.sh’s naive sed-based pkgver extraction (used only to name the live build-log file), producing a literal unexpanded string with embedded slashes as the log filename. tee couldn’t open that path and failed, and since pipefail is intentionally on to catch real makepkg failures, that masked an otherwise fully successful build (check() included) on both eurobuild5 and eurobuild14. Fixed remote_build.sh to extract pkgver/pkgrel via makepkg --printsrcinfo, matching how pkgname was already handled. Verified the two already-built artifacts directly before trusting them, then signed+published by hand rather than re-running the ~70-minute armv7h build (openssl’s own test suite is what made it slow). See memory/openssl-1.1.md.

lacc-git (maintained/, local-install category): asked to rebuild and publish; found an uncommitted local PKGBUILD edit already staged (the user’s own change, as lacc-git’s upstream AUR maintainer) bumping pkgrel 1->2 and extending arch=(x86_64) to add i486/i686/pentium4. Built as-is. The earlier worry that build()’s hardcoded --build=x86_64-linux would make 32-bit builds meaningless didn’t pan out – that flag only feeds autoconf’s build-triple detection, not a forced codegen target, and each chroot’s native toolchain still produced real 32-bit binaries (confirmed via compiler warnings showing size_t resolving to 32-bit on the i486/i686/pentium4 builds). All four archs built and published cleanly on the first try, debug packages included. See memory/lacc-git.md.

The android-file-transfer/python2 aarch64 backlog (also surfaced by this sweep, both previously blocked only by the cluster being down) is still queued for this session.

2026-09-28: slimcc-git – x86_64 published, 32-bit arch=() reverted

Asked to “build and publish”; found an uncommitted local PKGBUILD edit already staged (user’s own change, upstream maintainer): pkgrel 1->2, arch=(x86_64) -> arch=(x86_64 pentium4 i686 i486), plus a Maintainer-line email format tweak. Cleaned a stale May 5 leftover .pkg.tar.zst from /data/INSTALL first.

x86_64 built+published cleanly (r1146.9778925-1). pentium4/i686/i486 all failed in check(): platform/linux-glibc-generic.c’s platform_search_dirs() hardcodes an x86_64-only glob to find GCC’s libgcc path, so the freshly-built compiler can’t link its own test binaries on 32-bit – confirmed architectural (upstream’s own pkgdesc says “for x86-64 Linux/BSD”; same class of issue as chibicc-git’s i686 failure), not a packaging bug. Flagged to the user, who chose to revert arch=() back to (x86_64) rather than skip check() on 32-bit. pkgrel kept at 2, .SRCINFO regenerated – no rebuild needed, the published x86_64 package already matches. See memory/slimcc-git.md.

2026-09-28: lacc-git correction – i486/i686/pentium4 were functionally broken, reverted + unpublished

Follow-up to the same-day lacc-git rebuild above. User tried the published package and hit Unable to resolve include file 'gnu/stubs-64.h' – the 32-bit-compiled lacc binary was still targeting x86_64 internally. Root-caused to upstream’s own configure: there is no 32-bit x86 backend in this project at all (only x86_64 and arm64 exist), so --build=x86_64-linux was never really the bug – no --build= value would have produced a working 32-bit target, since configure’s host-detection case only branches on arm64/aarch64-vs-everything-else. This confirms the original 2026-08-19 memory note (x86_64-only, deliberately) was correct, and this session’s earlier “confirmed genuinely 32-bit” check (GCC warnings during lacc’s own self-build) answered the wrong question – it showed lacc compiles as a real 32-bit ELF, not that its codegen targets 32-bit.

Reverted arch=() to (x86_64), pkgrel unchanged at 2, .SRCINFO regenerated. Removed the already-published i486/i686/pentium4 lacc-git+lacc-git-debug packages from the live repo (repo-remove

• file deletion on each arch, user-approved) – verified clean afterward. See memory/lacc-git.md.

2026-09-28: lundukecity-git (new, maintained/)

New AUR submission requested directly, following the same meson+gtkmm3 pattern as lunduke-edit-git/lunduke-paint-git (Bryan Lunduke’s LCOS project). Only direct dep is gtkmm3 (bundled Micropolis engine + dlopen’d optional PulseAudio, so optdepends=('libpulse: sound effects') rather than a hard dep). Verified before building that a $srcdir-path packaging warning (baked-in build-tree asset path) is harmless – the binary’s own runtime fallback correctly resolves the installed /usr/share/lunduke-city/micropolis-assets path instead. Built + published cleanly first try, x86_64 only, r14.b5272fb-1 (+ debug), both check() tests passing. User asked about extending to the project’s other supported archs, then said to leave it x86_64-only for now. See memory/lundukecity-git.md, which also notes why the two sibling packages stay x86_64-only (one genuinely blocked on a custom-maintained x86_64-only dependency, the other likely just never tried elsewhere).

2026-09-28: mdcat – already current, fixed a stale nvchecker config

Routine check requested; upstream’s real tags (BIRSAx2/mdcat, the active fork) top out at 2.17.0, matching the published pkgver exactly – no rebuild needed. Along the way found .nvchecker.toml still pointed at the original abandoned upstream (swsnr/mdcat), so the update check was silently comparing against a dead repo frozen at 2.7.1 rather than real current upstream – it only happened to read “OK” because our version is numerically ahead of that stale target. Fixed to track BIRSAx2/mdcat; re-checked, now correctly reports 2.17.0 2.17.0. Also added a missing STATES.txt entry (never had one – vendored after the last full check run). See memory/mdcat.md.

2026-09-28: ARM queue closed out – python2 aarch64 published

Last item of the original 3-package ARM backlog (openssl-1.1, android-file-transfer, python2, all queued earlier this session once the cluster came back up). First successful aarch64 build for python2 ever – the two prior attempts (2026-09-11, 2026-09-21) both failed on infrastructure, not packaging. This attempt hit the known stale-sync-db issue (needed openssl-1.1, published for aarch64 earlier in this same session, but eurobuild14’s pacman hadn’t refreshed yet – fixed with pacman -Sy), then completed cleanly at the existing pkgrel=19 (~1h build, PGO run_profile_task on a MAKEFLAGS=-j1 board). All four archs now published at the same pkgrel for the first time since the arch extension. See memory/python2.md.

2026-09-29: check_ssl_cert 2.103.1 -> 2.103.3, first build across all 6 archs

Only genuine UPD from a full routine update sweep this session (everything else was already current). Standard recipe (bump pkgver, updpkgsums, regen .SRCINFO). ARM cluster being up meant armv6h/armv7h/ aarch64 – already listed in this package’s arch=() but never actually built – went clean on the first try, alongside the usual i686/pentium4.

x86_64 hit a real infra issue: the local network’s Arch mirror used by the build chroot’s base core/extra/multilib repos was genuinely 404ing on extra.db (confirmed via direct curl, not transient). Fixed (user-approved) by adding a fallback mirror (geo.mirror.pkgbuild.com) to both the host’s and the chroot’s own separate /etc/pacman.d/mirrorlist copies – x86_64 then built clean. This is an infra fix that should help any future local x86_64 build, not something specific to this package – see memory/TOOLING_NOTES.md’s 2026-09-29 entry.

All 6 archs published simultaneously at 2.103.3-1 for the first time. See memory/check_ssl_cert.md.

2026-10-07: freeimage pkgrel 23 -> 24

AUR comment (jose1711) reported a clean-chroot build failure: extra/jxrlib 1.4.3 ships JXRGlue.h including JXRVersion.h but never installs that header. Applied the commenter’s own workaround – prepare() now synthesizes a minimal local JXRVersion.h when the system one is missing, no-op once/if jxrlib ever ships it. Packaging-only, no pkgver change. Built+published (x86_64) cleanly. See memory/freeimage.md.

2026-10-09: ncurses5-compat-libs pkgrel 2 -> 3, source host revert

Per user request, reverted source=() from invisible-island.net back to ftp.gnu.org (the original host before a 2026-06/07 AUR-comment-driven switch), after further AUR comments (#1077621, #1087567) argued for gnu.org on trust/availability grounds. Same upstream tarball/sha256, only the host and the signature file’s extension (.asc -> .sig) changed; PGP key (Thomas Dickey) refreshed via update_pgp_key_dir.sh first. Packaging-only, pkgrel bump. Built (i686+x86_64, plus -debug split) and published cleanly; i686 chroot threw unrelated segfaults in its own post-transaction hooks during the glibc upgrade step, not in the actual ncurses build. See memory/ncurses5-compat-libs.md.

2026-10-16: tmog-bin added (local-install, first build)

New local-install/tmog-bin entry – precompiled proprietary task manager, not maintained by us (AUR maintainer maci). Fresh clone from AUR, built and published x86_64 only (upstream ships only an x86_64 binary) for the first time. namcap flagged a genuine missing hicolor-icon-theme dependency in upstream’s own PKGBUILD – not fixed, since this is their PKGBUILD verbatim. See memory/tmog-bin.md.

2026-10-17: linux-lts515 5.15.222 -> 5.15.223

Routine point release, all 4 archs (x86_64/pentium4/i686/i486). Hit two separate mirror.archlinux32.org outages along the way for i686 and i486; resolved by polling the mirror and retrying each affected arch individually. Config diffs cosmetic-only as usual. See memory/linux-lts515.md.

2026-10-17: thunderbird-esr-bin 153.4.0 -> 153.5.0

Routine bump, x86_64 only. PGP key unchanged, tarball confirmed first. Published cleanly. See memory/thunderbird-esr-bin.md.

2026-10-17: pacman-static curl 8.22.0 -> 8.23.0, pkgrel 22 -> 23

User-requested curl bump (per nvchecker -c nvchecker-deps.toml), explicitly Intel archs only (x86_64/i686/pentium4/i486) that session – ARM deliberately left at pkgrel 22. pentium4 needed a retry for the same mirror flakiness as linux-lts515 above. See memory/pacman-static.md.

2026-10-19: cyrus-imapd2 and perl-crypt-ssleay rebuilt for perl 5.44 ABI bump

User found both packages still owned files under the old perl-5.42 versioned path. Content-free rebuilds, x86_64 only that round: cyrus-imapd2 pkgrel 2.5 -> 2.6, perl-crypt-ssleay pkgrel 8 -> 8.1. Running both repo_release.sh calls concurrently caused a repo-db lockfile collision on x86_64 – one publish needed a manual repo_publish.sh retry. While investigating, found maintained/obexftp also ships a compiled perl XS module needing the same treatment, but its rebuild attempt failed on an unrelated, pre-existing swig/python2 incompatibility (swig 4.5.1 dropped Python-2 wrapper support) – left as-is per user decision; noted as a possible future swig-fork target in memory/obexftp.md. See memory/cyrus-imapd2.md and memory/perl-crypt-ssleay.md.

2026-10-19: ii and hashcash catch-up bumps (cluster ahead of archlinuxaba)

User found via pacman -Qqo that a cluster node had newer locally-installed versions than archlinuxaba served for both packages, with no corresponding upstream (AUR for ii; azon’s AUR package for hashcash) release to explain it – most likely untracked local rebuilds on that node at some point. Bumped forward past the already-live versions per the established “never go back to what would’ve been ideal” precedent: ii pkgrel 1 -> 2.1, hashcash pkgrel 5.1 -> 29.1. See memory/ii.md and memory/hashcash.md.

2026-10-19/20: ARM catch-up for pacman-static, cyrus-imapd2, perl-crypt-ssleay

Once the remote ARM build boards (eurobuild4/5/14) were confirmed back online, ran the armv6h/armv7h/aarch64 builds deliberately deferred above: pacman-static to pkgrel 23 (all 7 archs now current), cyrus-imapd2 to 2.5.17-2.6 (armv6h/armv7h), perl-crypt-ssleay to 8.1 (armv6h/armv7h/aarch64). All built and published cleanly, no board collisions this round.

2026-10-20: full update cycle (update_cycle.sh + AUR feedback + yay)

AUR’s git/SSH host was unusually flaky (~20-25% random connection resets); converged via several retry passes to 258/259 submodules confirmed current (one, pacman-static, has an unpushed local commit ahead of its AUR remote – not a conflict). Found 2 genuine UPD flags (mdcat, check_ssl_cert), 0 unresolved dependencies, and a handful of archlinux32-adoptable candidates (informational only). AUR comment check surfaced a real unanswered build failure on kjots (CMake can’t find KPim6Mime) for the user’s attention. Local yay -Qu was clean.

2026-10-20: mdcat 2.18.0 -> 2.19.0

Routine UPD bump, x86_64 only (i686 still blocked by archlinux32’s own stale rust package, unchanged since last checked). See memory/mdcat.md.

2026-10-20/21: check_ssl_cert 2.103.3 -> 2.103.4

Routine UPD bump, all 6 archs. armv7h hit a real infrastructure failure on eurobuild5 (NBD-backed /data threw I/O errors, ext4 journal aborted, kernel force-remounted read-only) – not a transient flake, flagged to the user rather than retried blindly. Once the user confirmed the board physically healthy again, retried armv7h alone and it published cleanly. See memory/check_ssl_cert.md.

2026-10-21: thunderbird-esr-bin 153.5.0 -> 153.5.1

Another routine point release caught by the STATES.txt refresh right after the mdcat/check_ssl_cert session. Same standard recipe, x86_64 only, published cleanly. See memory/thunderbird-esr-bin.md.