Cross-package tooling notes

• A single generic pacman.conf doesn’t cover both x86_64 and the 32-bit arches – the [core]/[extra] mirrorlist differs, not just $arch inside it. Built 2026-08-13, wiring archlinuxaba-<arch>-build up for i486/i686/pentium4 (previously x86_64-only, see memory/REPO_PUBLISH_DESIGN.md). The existing arch/config/pacman.conf.d/archlinuxaba.conf is a copy of devtools’ generic extra.conf: Architecture = auto, Include = /etc/pacman.d/mirrorlist (the plain 64-bit Arch mirror). Assumed this would “just work” for every arch since pacman substitutes $arch in Server = lines at read time – wrong assumption: devtools32 ships separate extra-i486.conf/extra-i686.conf/extra-pentium4.conf files (/usr/share/devtools/pacman.conf.d/) with an explicit Architecture = <arch> and, critically, Include = /etc/pacman.d/mirrorlist32 (mirror.archlinux32.org) instead – 32-bit packages live on an entirely different mirror network, not just a different $arch subdirectory of the same one. Building archlinuxaba-i486-build etc. with the generic config failed immediately at fresh chroot creation (error: failed retrieving file 'core.db' – 404 against the 64-bit mirror, which has no i486/i686/pentium4 trees at all). Fix: added archlinuxaba-i486.conf/archlinuxaba-i686.conf/ archlinuxaba-pentium4.conf, each the corresponding stock extra-<arch>.conf with our [archlinuxaba] section spliced in ahead of [core] (same pattern as the original archlinuxaba.conf vs. extra.conf). archlinuxaba-archbuild’s existing per-arch config resolution (prefers ${repo}-${arch}.conf over ${repo}.conf, see the script’s own header comment) picked these up with no code change. Lesson for wiring up any new arch here in the future: check whether devtools ships an arch-specific base config before assuming the generic one is arch-agnostic – it usually isn’t for anything outside the “one real mirror network” x86_64 case.

• A build/publish/rebuild cycle for the same pkgver-pkgrel within one session can poison the local pacman package cache for the next build. Same 2026-08-13 session: rebuilt+republished libstroke 0.5.1-11 twice in a row while iterating on the fix above (each build gets a fresh SOURCE_DATE_EPOCH, so the two builds are not byte-identical even though the version string is). A later fvwm x86_64 build then failed installing libstroke as a dependency – pacman: “file … is corrupted (invalid or corrupted package (checksum))” – because a stale copy from the first libstroke build was sitting in the build chroot’s package cache and no longer matched the checksum of what got published second. Not specific to archlinuxaba/fvwm/libstroke; any same-version rebuild-and-republish during a single working session can leave this trap for the next package that depends on it. Fix is just a bare retry of the affected arch (the stale cache entry doesn’t survive a fresh chroot sync) – no need to hunt down and manually clear the cache file.

• A report script that only prints “what’s new since last run” must never be invoked with > truncation, and ideally shouldn’t let the caller choose. Built 2026-07-22 (scripts/check_aur_feedback.sh): first run redirected with > ../FEEDBACK.txt, correctly printed all 429 then-current AUR comments across every maintained package. Second run (after fixing an unrelated pkgname-resolution bug) was invoked the same way, > again — its own dedup logic correctly suppressed re-printing the 396 comments already marked “seen” from run 1, which is exactly what dedup is supposed to do, but since > truncated the file first and nothing else on disk held a copy of run 1’s text, that entire history was gone with no way to reconstruct it (the comments still exist on AUR, but re-fetching them would just re-trigger the same dedup and print nothing). Any script with this “print only the diff since last time” shape needs the report file itself to be append-only across runs, not just the in-memory dedup state – otherwise dedup working correctly is exactly what destroys the history. Fix applied: the script now takes the output path itself (default ../FEEDBACK.txt) and appends a dated ## <timestamp> section internally, skipping the write entirely if there’s nothing new to report – there is no >-redirect invocation path left for a caller to get wrong.

• check_aur_feedback.sh ANSWERED/REOPENED tracking (2026-09-07). Before this, a comment thread you’d already replied to on AUR looked identical in FEEDBACK.txt to one nobody had touched – the .seen-file dedup only stops a comment being re-printed, it never recorded whether it had actually been addressed. aur_comments.py lists comments newest-first (matches the AUR page’s own layout), so the script now checks, per package, whether the current newest comment is authored by AUR_USER_NAME (sourced from config/global.conf) – if so the thread is “answered as of now”. State lives in aur_feedback_state/<pkgbase>.answered (the reply’s date, or empty), and an ANSWERED/REOPENED line is printed only on a state transition (mirrors the existing FLAG/UNFLAGGED OutOfDate pattern right below this script’s other dedup logic) – REOPENED means someone commented again after your reply. Narrow by design: doesn’t catch the reporter self-resolving their own thread (e.g. pacman-static’s “tnx. solved.” case) – that’s still visible in the plain COMMENT line, just not tracked as a state change. Also never fires when a request is resolved by fixing the PKGBUILD directly without ever replying on AUR – confirmed real case: duckie_xyz asked for aarch64 on qt5-connectivity (2026-08-31), user added it straight to the PKGBUILD the next day with no AUR reply (“some small changes are just obvious, I don’t comment them” – user’s own words, 2026-09-07). That thread will show as open/ unanswered by this heuristic forever, even though it’s fully resolved – always check the actual PKGBUILD/repo state before treating an “unanswered” FEEDBACK.txt entry as still needing work. Companion convention (not code): whenever a session acts on, or explicitly decides not to act on, AUR feedback for a package, log a one-line dated note in that package’s own memory/<pkgname>.md – the ANSWERED/REOPENED machinery tracks whether AUR itself shows a reply, not why a decision was made, and that reasoning belongs in the per-package memory file the same as any other packaging decision (see memory/qt5-doc.md’s 2026-09-07 entry for a worked example: a real open upstream-download bug, reproduced by a second reporter after an initial “cannot reproduce”, left open pending a decision on the suggested prepare()-based fix).

• AUR RPC maintainer checks must include co-maintainers, not just primary maintainer. scripts/compare_packages.sh queries rpc/v5/search/<user>?by=maintainer, which only returns packages where <user> is the primary maintainer — packages held as co-maintainer are silently excluded, and show up as false “local dir not on AUR” diffs. Confirmed 2026-07-20: nagircbot, pacman-static, and trojita all looked like AUR-maintainer mismatches from the by=maintainer search alone, but by=comaintainers (same endpoint, different by value) showed all three are legitimately co-maintained by this account (primary maintainers are other people) — not orphan or drift situations at all. Any future “is this package actually ours on AUR” check needs both by=maintainer and by=comaintainers unioned before concluding something’s missing/mismatched. rpc/v5/info/<pkgname> also exposes this per-package via the CoMaintainers array field (absent entirely if there are none).

• nvchecker’s include_regex/exclude_regex use re.fullmatch, not re.match or re.search (nvchecker/core.py’s apply_list_options: re_pat.fullmatch(str(x))). An anchored-prefix-only pattern like "^5\\." matches nothing – fullmatch requires the whole version string (e.g. "5.7.7") to match, and "^5\\." only ever matches the literal 2-char string "5.". Need a trailing .* ("5\\..*" – fullmatch already anchors both ends, no need for ^/$). Confirmed 2026-09-08 fixing a false UPD flag on qt5-quickcontrols-nemo (upstream moved to Qt6 tags this package deliberately doesn’t track – see that package’s own memory file); the first attempt ("^5\\.") silently produced “include_regex matched no versions” / no-result instead of the intended filter. Always verify a new include_regex/exclude_regex with a direct nvchecker -c .nvchecker.toml --logger json run before trusting it.

• Dependency-resolution checks need pacman -Si + a real Provides scan, not pacman -T. Built 2026-07-26 (scripts/check_dependencies.sh, after finding maintained/lxappearance-obconf-gtk3 depended on lxappearance-gtk3, which never existed anywhere – see memory/lxappearance-obconf-gtk3.md). Three separate bugs surfaced while building the checker, in order:

  1. pacman -T (deptest) only checks installed packages, not the sync databases – dkms (real package in [extra], just not installed on this build host) came back “unsatisfied” even though pacman -Si dkms finds it immediately. Use -Si for an install-state-independent existence check.
  2. pacman -Si alone still doesn’t see Provides – virtual/group deps (sh, pkgconfig, java-runtime, ttf-font, initramfs, fuse, atk) and soname deps (libobrender.so, from openbox) are essentially never named after the package that actually provides them, so a plain -Si lookup flagged nearly all of them as broken. There’s no pacman -S* query that does a provides-only lookup without an actual transaction; the fix was tar -xOf on every configured repo’s sync db (pacman-conf --repo-list, $(pacman-conf DBPath)sync/<repo>.db) parsed for raw %PROVIDES% fields directly.
  3. comm needs LC_ALL=C to match a LC_ALL=C sort-ed input – this host’s locale is en_US.UTF-8, and a locale-default comm against C-locale-sorted files silently mis-diffs (“input is not in sorted order” printed to stderr, but the command still exits 0 and produces wrong output that looks plausible). Net effect for any future resolution primitive: verify it against both a known-installed-and-real name and a known-not-installed-but- real name before trusting its output, and assume Provides needs handling explicitly – pacman’s own name-lookup commands don’t do it for you outside a real transaction. As of 2026-07-26 (right after the lxappearance-obconf-gtk3 fix), a full run across all 544 unique dependency entries in arch/ resolves cleanly – 0 BROKEN.

• Policy notes, split out since they apply broadly rather than to one package: HOST_INSTALL_POLICY.md (never install packages on this host to fix a build — chroots exist for that; GPG key imports for source verification are the one exception), PKGREL_VS_PKGVER.md (packaging- only fixes bump pkgrel, not pkgver), ARCHIVE_APPEND_ONLY.md (never remove/move anything out of the private repo’s archive/ dir).

• This machine can currently only build packages for x86_64, pentium4, i686, and i486 — it has local extra-<arch>-build archbuild chroots for exactly these four. Any other arch that shows up in a PKGBUILD’s arch=() — notably aarch64, arm, armv6h, armv7h, riscv64 — cannot be built here yet; that would need either QEMU user-mode emulation (to run a foreign-arch chroot on this x86_64 host) or SSH access to a real build machine of that architecture, neither of which is set up. The repo_build.sh script (see REPO_PUBLISH_DESIGN.md) already treats this as expected: it skips and reports any arch with no local extra-<arch>-build instead of failing the whole build.

• Some existing PKGBUILDs contain pre-existing invalid-UTF-8 byte sequences in comments (e.g. libarchive-static’s # Tomáš Mráz maintainer-key comment, which is already mojibake’d to a raw Latin-1 0xE1 byte in git history). My Edit tool and any full-file rewrite (Perl scripts like updpkgsums, makepkg --printsrcinfo, etc.) treat the file as UTF-8 text and silently replace such invalid bytes with U+FFFD on save, corrupting them further even in lines I didn’t intend to touch.

  • After editing a PKGBUILD, diff the full file content against the last git revision (git -C <pkg> show HEAD:PKGBUILD) to catch unintended byte-level drift outside the lines you meant to change, not just the lines you meant to change.
  • Use LC_ALL=C grep -a / byte-level tools when inspecting such lines; UTF-8-locale grep can silently fail to match corrupted byte sequences.

• archbuild scripts (extra-<arch>-build) pass args after -- straight into their internal makechrootpkg_args array without inserting a separator — so to get args through to makepkg inside the chroot you need a double --: sudo extra-i686-build -- -- --nobuild --skippgpcheck. A single -- makes makechrootpkg itself choke on the makepkg flags (“illegal option – -”).

  • --nobuild is the cheap way to run just prepare() (extract + patch + any config/version reconciliation) inside a chroot without doing the full compile — much faster than a full build when you only need to check/update generated files like kernel configs.
  • The chroot’s working-copy build tree lives at /var/lib/archbuild/<repo>-<arch>/<local-copy-user>/build/<pkgname>/src/... (default local-copy name is your own username) — files placed there by prepare() (e.g. a reconciled .config) can be sudo cp’d back out and chown’d to your user.
  • namcap inside these chroots is broken (ImportError: libalpm.so.14: cannot open shared object file) and checkpkg always says “target not found” since there’s no local repo — both are known-harmless environment issues, not build failures.

• Intra-tree dependency ordering — fixed 2026-07-07 for x86_64. extra-<arch>-build chroots resolve depends/makedepends only against the official Arch mirrors (whatever pacman.conf in the chroot points at) — never against other packages built earlier in the same repo_release_all.sh run, and never in build-order at all (packages are processed in plain alphabetical order). Any package here whose depends/makedepends names another custom package from this tree (not an official Arch package — e.g. the Qt5/KDE5 rebuild stack, or arduino-builder needing arduino-ctags) used to fail with error: target not found: <pkg> regardless of run order. See memory/kdstatemachineeditor.md for the original diagnosis.

  • Fix: scripts/archlinuxaba-archbuild (symlinked as scripts/archlinuxaba-x86_64-build) is a copy of the system /usr/bin/archbuild (devtools32), changed in exactly one place: it resolves pacman_config from this project’s own arch/config/pacman.conf.d/ first (falling back to the system location), and arch/config/pacman.conf.d/archlinuxaba.conf is a copy of the stock extra.conf with our own private repo (archlinuxaba, SigLevel = Optional TrustAll) added ahead of [core]/[extra]. This mirrors devtools32’s own *-with-build-support config pattern (bootstrap/staging repos layered on top of the base config the same way). It uses its own separate chroot (/var/lib/archbuild/archlinuxaba-x86_64), so the stock extra-x86_64 chroot is untouched. Never modifies anything under /usr — everything new lives under arch/.
  • repo_build.sh now resolves the build command per-arch via a _build_cmd helper: archlinuxaba-x86_64-build for x86_64, plain extra-<arch>-build for everything else (only x86_64 is wired up so far, per explicit scope).
  • Verified against a real case: arduino-builder needs arduino-ctags (a package in this tree, already published) — failed under plain extra-x86_64-build, succeeded under archlinuxaba-x86_64-build once retried.
  • Caveat: this only helps once a dependency has actually been built+published before the package that needs it is attempted — repo_release_all.sh still processes the tree in plain alphabetical order with no dependency-graph awareness, so a package needing an alphabetically-*later* custom dependency will still fail on a single top-to-bottom pass and needs a manual retry afterward (see memory/gcc-ia16.md, memory/fvwm.md for pending examples).

• This build box’s GPG keyring is missing some upstream signing keys referenced by validpgpkeys in various PKGBUILDs, causing --skippgpcheck-less real builds (as repo_build.sh does, unlike build_all_archs.sh’s own test-build convenience flag) to fail source verification with unknown public key <ID> regardless of anything about the package’s own PKGBUILD/source correctness. First seen 2026-07-07 for key 95FA6F43E21188C4 across maintained/arduino and maintained/arduino-builder. Unlike installing a package on the host (never do that — see memory/feedback_no_host_installs.md’s original, narrower rule), importing a signing key needed purely for source verification is a normal, expected part of doing the build and is fine to do on the host: gpg --recv-keys <ID> (from hkps://keys.openpgp.org or keyserver.ubuntu.com if the PKGBUILD doesn’t specify one). Done for 95FA6F43E21188C4 on 2026-07-07 — both packages should be retried.

• A third missing-dependency class, distinct from environment drift and intra-tree ordering: real AUR-only dependencies this tree doesn’t maintain at all (e.g. dbmodel-qt4 needing qt4, adtpro-git/p2c- style needing cc65/gcc14). Unlike the KDE5/Qt5 stack (custom packages that live in this tree, just not resolvable mid-run — fixed by archlinuxaba-x86_64-build, see above), these depend on packages that were never part of arch/maintained/private/adapted/owned in the first place. Building them would mean also building/vendoring a package this tree doesn’t own. Per the user (2026-07-07): note these and move on, don’t try to resolve them now — revisit once there’s an actual plan for out-of-tree AUR dependencies.

• CMake in this build environment refuses cmake_minimum_required versions below 3.5 (Compatibility with CMake < 3.5 has been removed from CMake.), which will hit any older/unmaintained CMake-based package whose CMakeLists.txt still declares an ancient minimum version. First seen 2026-07-07 on kdiagram5 (see memory/kdiagram5.md). CMake’s own suggested workaround is -DCMAKE_POLICY_VERSION_MINIMUM=3.5 passed to the cmake invocation in the PKGBUILD’s build() — not applied yet to any package as part of this pass; expect this to recur across other older CMake-based packages in the tree.

• Modern GCC’s default warnings-as-errors trip older/unmaintained C/C++ sources on genuinely harmless issues like an unused-but-set variable (error: variable 'X' set but not used [-Werror=unused-but-set-variable=]). Seen 2026-07-07 on modest (memory/modest.md) and newsboat-og (memory/newsboat-og.md). Not fixed for either; would need a source fix or relaxing that specific -Werror in the PKGBUILD’s CFLAGS. Expect this to recur on other old C/C++ packages in the tree.

• Long-running builds (e.g. kernel compiles via archbuild) started as a plain backgrounded Bash tool call die with the session (SIGHUP) if the session is closed early. To survive session termination, launch them in a detached screen session instead: screen -dmS <name> bash <script>.sh (or -e^Xy for a custom escape sequence). Check on it later with screen -r <name> or by tailing the chroot’s own build log at /var/lib/archbuild/<repo>-<arch>/<user>/logdest/<pkg>-<ver>-<arch>-build.log.

• Danger: manually replicating repo_build.sh’s git-status-driven post-build cleanup (git status --porcelain -- . → rm -rf every ?? entry not matching *.pkg.tar.*/.sig) can delete a brand-new source file you just added, not just real build byproducts. That cleanup’s own assumption is “an untracked file after a successful build is either a release artifact or something makepkg generated” — true when running it via the real pipeline on an already-committed package tree, but this project’s own standing rule is never git commit (see CLAUDE.md). So a genuinely new file you add to a maintained/ package (a new local patch, a new config) — something you fully intend to keep — will always show as ?? untracked, indistinguishable from a downloaded tarball or a .log file, for as long as this session lives. Hit this for real 2026-07-16 on akonadi-notes: a newly-written akonadi-notes-24.08.3-kmime-26.04-api.patch got deleted by exactly this cleanup snippet run by hand right after a successful publish. Recovered only because a scratch copy of the diff still existed to regenerate it from.

  • How to apply: before running (or hand-replicating) this cleanup after a build, check git status --porcelain -- . yourself first and make sure every ?? entry it’s about to remove is something you actually expect to be disposable (a downloaded source tarball, a *.log file, a VCS clone dir) — not a patch/config file you just added as the actual fix. When in doubt, copy the new file somewhere safe (or note its content) before letting any cleanup step run near it.
  • Confirmed 2026-07-31 that this isn’t just a manual-replication risk — the real, automated repo_release.sh → repo_build.sh pipeline does this too, every time, to every new uncommitted patch file. On kdiagram5: wrote kdiagram-2.8.0-ecm-project-version.patch, wired it into prepare(), ran the normal repo_release.sh maintained/kdiagram5 (not a hand-replicated cleanup), build succeeded, and the patch (plus the unrelated pre-existing PKGBUILD~ backup) was silently rm -rf’d by this exact cleanup step since neither was git-tracked. Recovered only because the patch content was still in this session’s own context to rewrite verbatim (checksum matched, confirming an exact recreation) — a fresh session with no memory of the patch’s content would have lost it for good. Since this project’s assistant never runs git commit (see CLAUDE.md), every single new patch file written in any session is on a countdown to deletion the moment the next successful repo_release.sh/repo_build.sh run touches that package directory — there is no “safe” window. Until/unless this cleanup step gets a *.patch exception (not done as of this note — would need explicit user sign-off, since a stray downloaded .patch source file some PKGBUILDs also legitimately fetch via source=() complicates a blanket exclusion), treat any newly-written patch as needing the user to git commit it (or add it to .gitignore’s inverse / otherwise mark it tracked) before the first build, not after.

• repo_publish.sh’s filename-derived arch/pkgname parsing had no validation, and it silently corrupted the remote repo layout twice. Found 2026-07-26 while investigating a user-reported bogus directory os/x86_64pkg.tar.zst/ on the repo host. Root cause: _pkg_arch()/_pkg_name() stripped an expected .pkg.tar.<ext> suffix and then took “whatever’s after the last -” as arch/pkgname, with no check that the strip actually matched anything. Two real incidents from this: (1) m68k-elf-gcc, built via a separate ad-hoc /data/INSTALL/-based flow (not this repo’s arch/ tree) with a misconfigured PKGEXT missing its leading dot, produced ...x86_64pkg.tar.zst – the unguarded strip left it untouched, and ${_base##*-} grabbed the whole x86_64pkg.tar.zst tail as “arch”, publishing into a bogus top-level dir with its own orphaned repo-add database. (2) zoom, built by a separate concurrent session, produced a filename missing its -<pkgrel>- segment (zoom-7.1.5.4332_orig_x86_64.pkg.tar.xz), so the only hyphen left after the (successful, this time) extension strip put 7.1.5.4332_orig_x86_64 in as “arch”. Both bogus dirs sat unnoticed on the repo host for over a week (m68k-elf-gcc: 2026-07-16 to 2026-07-26; zoom: 2026-07-22 to 2026-07-26) since nothing about publishing failed loudly – mkdir -p/repo-add happily created a whole new “repo” at the bogus path. Fixed: _pkg_stripped_base() now aborts (non-zero exit, ERROR: to stderr) if the .pkg.tar.* strip didn’t change anything, and _pkg_arch() additionally rejects any result containing a . (real arch names never have one; both incidents above did). Both stale directories were removed from the repo host after confirming a correct copy of m68k-elf-gcc already existed in os/x86_64/ (zoom had no other copy – removing its bogus dir removed the package from the repo entirely, done with explicit user confirmation). Lesson for any future filename-parsing helper: validate that an expected-pattern strip actually matched before trusting what’s left over, don’t just chain more stripping operations on a possibly-untouched string.

• archive/ reorganized to be per-arch, 2026-07-26. Was previously one flat directory shared across all archs (deliberate original design – filenames embed pkgver+arch so they can’t collide there either way). User asked for it to mirror os/’s per-arch layout instead. _archive_old() in repo_publish.sh already received the package’s arch as _pkgarch; changed it to create/move into ${ARCHIVE_DIR}/${_pkgarch}/ instead of flat ${ARCHIVE_DIR}/. The existing 73 files were migrated in place on the repo host with a one-off script that reused the same _pkg_arch() parsing logic (not a second implementation) to classify each file, then mkdir -p+mv per arch – verified file count (73) and total byte size (830534379) matched exactly before and after, nothing lost. Result: archive/{any,i686,pentium4,x86_64}/.

• **Routine per-package publishes go through repo_diff_local_remote.sh

  • repo_release_changed.sh, not a hand-chained extra-x86_64-build -> repo_sign.sh -> repo_publish.sh sequence – even for just one or two UPD-flagged packages.** Went off this rail 2026-07-27 while updating i686-elf-binutils/x86_64-elf-binutils (2.45/2.46.0 -> 2.47): after editing both PKGBUILDs, ran extra-x86_64-build directly to test-build, then repo_sign.sh and repo_publish.sh by hand for each. That produced a correct result (both published fine, verified against the remote repo and site afterward), but skipped the actual sanctioned tooling: repo_diff_local_remote.sh would have confirmed both read as CHANGED once the PKGBUILDs were bumped, and repo_release_changed.sh builds+signs+publishes exactly that detected set (also handles the “already up to date, skip” and multi-package cases uniformly, and keeps the REPO_BUILD_ONLY_ARCH convention and per-package logfiles under repo_release_logs/ consistent with every other routine cycle). repo_release.sh <pkgdir> (single-package build->sign->publish) is the right manual escape hatch when a package needs individual attention outside the diff-driven flow (e.g. re-testing after a build fix) – reaching for the three lower-level scripts directly should be rarer still, reserved for cases where even repo_release.sh’s ordering doesn’t fit (e.g. republishing an already-built artifact without rebuilding it).

• Recovering an in-place build into the /data/INSTALL staging layout, after building directly inside arch/<category>/<pkgname> by mistake (e.g. via build_all_archs.sh run there instead of repo_release.sh/repo_build_staged.sh from the start – don’t do this; see the entry above and the “build staged by default” habit note). If the build already ran and especially if it was expensive (a kernel compile across 4 archs, hours of chroot time), don’t throw the work away and restart staged – migrate the result into the layout repo_build_staged.sh would have produced:

  1. If /data/INSTALL/<pkgname> already exists (a previous release’s staged build), move it aside first – never overwrite/delete it. Follow the existing rotation convention already in use for linux-lts510 (-old, -older, -oldest as each new one bumps the previous aside): mv /data/INSTALL/<pkgname> /data/INSTALL/<pkgname>-old (or -older/-oldest if -old is already taken).
  2. rsync -a --exclude=.git -- arch/<category>/<pkgname>/ /data/INSTALL/<pkgname>/ – same invocation repo_build_staged.sh itself uses, just run after the build instead of before. This carries the tracked PKGBUILD/patches/etc and the untracked build byproducts (downloaded sources, produced *.pkg.tar.*, logs) into the staged location together in one shot.
  3. git clean -fd inside arch/<category>/<pkgname> to drop every untracked byproduct from the tracked tree, restoring it to exactly the pre-build state (verify with git status --short – must be empty). This is the actual goal of staging: arch/ never carries build output.
  4. Sign + publish from the /data/INSTALL/<pkgname> copy directly (repo_sign.sh/repo_publish.sh there) rather than copying package files back into arch/ first – no need, they’re not needed there.
  5. Leave everything else in /data/INSTALL/<pkgname> as-is afterward (downloaded tarball, per-arch build/package/namcap logs, the package files themselves) – don’t try to replicate repo_build.sh’s own post-build cleanup (which deletes everything untracked except the release artifacts) by hand here. That cleanup is driven by git status --porcelain inside build_dir, but rsync --exclude=.git means these staged copies have no working .git (confirmed against the existing linux-lts515-old staged dir: git status there fails with “fatal: not a git repository”), so repo_build.sh itself silently skips that cleanup step too when running the normal way – leaving the full build state in /data/INSTALL/<pkgname> permanently is the actual established behavior, not an oversight to fix. First done 2026-08-21 for linux-lts515 5.15.216 (see its own memory file for the specific run) – generalize this same five-step recovery to any other package caught mid-build in place.

• Remote ARM build machines (2026-08-27): armv6h/armv7h/aarch64 no longer always SKIPPED. repo_build.sh previously had no way to build any arch this host (x86_64) lacks a local chroot for. eurobuild4/eurobuild5/eurobuild14 are real dedicated boards (login build@<host>, passwordless sudo) for armv6h/armv7h/aarch64 respectively – no chroot/devtools tooling on them at all, just a plain makepkg -s run natively. Wired up via arch/config/remote_build.conf (arch->host map) + arch/scripts/remote_build_lib.sh (config loader, missing file is NOT fatal – an additive fallback path) + arch/scripts/ repo_build_remote.sh (local-side driver: push pkgdir, ssh-build, pull back *.pkg.tar.* + a combined build log) + arch/scripts/remote_build.sh (the agent script itself, redeployed fresh to each board on every invocation so the three boards can’t drift out of sync with git). repo_build.sh’s per-arch loop falls back to this only when it has no local build command for that arch; sign/publish are completely unaffected either way. A package file already sitting in pkgdir for the exact current pkgver-pkgrel-arch is reused instead of triggering another remote build – these boards are slow (eurobuild4 is single-core/423Mi RAM) and a real build can take 40+ minutes.

  • /data on each board is a mounted NBD block device (/root/ mount_data.sh, root-owned, board’s own tiny SD-card rootfs is 2-8GB and not meant to take real build I/O) served by a separate NBD server host, eurobuild3 – confirmed 2026-08-27 that server has to be up too, not just the target board itself, or the mount fails regardless. remote_build.sh auto-runs mount_data.sh (with a nbd-client -d /dev/nbd0 retry for a stale/dead prior connection – seen once on eurobuild4: “nbd0 already in use”, mount then fails to read the superblock) if /data isn’t already mounted. repo_build_remote.sh also pings the target board and REMOTE_BUILD_NBD_SERVER before attempting anything – fails fast with a clear message instead of a long ssh/rsync connect timeout if either is down. Don’t attempt an arm remote build if any of eurobuild3/4/5/14 aren’t up – ping from this host (euronuc) to check first if in doubt.
  • makepkg’s automatic key import from a package’s keys/pgp/*.asc (the validpgpkeys convention) didn’t reliably trigger on these boards for a key never seen there before, even with the .asc file right there – remote_build.sh now explicitly gpg --imports everything in keys/pgp/ before building. Not package-specific, fixed once at the agent-script level.
  • eurobuild4 (armv6h) runs pacman 6.0.1, long EOL (ArchLinux ARM dropped armv6h support entirely a while back, so this can’t be fixed by upgrading – there’s nothing left to upgrade to for this arch) – it can’t compute a checksum for a git+... source at all, reporting NOT FOUND rather than treating a real sha512sums entry as unhashable the way SKIP would. Any PKGBUILD with a real hash (not SKIP) on a git source needs a case "${CARCH}" in i486| armv6h) sha512sums[N]='SKIP' ;; esac-style per-arch override for that source’s index – see memory/libarchive-static.md’s 2026-08-27 entry for a worked example (and a cautionary tale: a similar-looking guard already existed there and was completely dead, patching the wrong array indices).
  • eurobuild4’s bash (5.1.16) also parses if [[ ... ]] then (no ; before then) as a hard syntax error, where bash 5.3.15 (eurobuild5/14) accepts it – a real grammar difference between those versions, confirmed with pacman-static’s upstream PKGBUILD. If a PKGBUILD fails to even source on an armv6h remote build (“syntax error near unexpected token”), check for this exact idiom before assuming it’s the checksum issue above. Fix is always just adding the missing ; – safe on every bash version.
  • remote_build.sh now runs makepkg -s -C --noconfirm (-C/--cleanbuild, added 2026-08-27) – without it, a prior partial/failed attempt at the same pkgver-pkgrel can leave $srcdir (“src/”) already-extracted-and-prepare()-mutated, so a retry’s patch calls can fail with “already exists” even though nothing is actually wrong (hit this on eurobuild4 with pacman-static’s pacman-reproducible-builds.patch, after ruling out the checksum/bash issues above as the cause). -C only removes the ephemeral src/ working copy – persistent VCS clone caches and already-downloaded tarballs at the top level of pkgdir are untouched, so this doesn’t reintroduce the slow-refetch problem repo_build_remote.sh’s no---delete rsync push was meant to avoid.
  • /data-mount ordering bug, fixed 2026-08-27: the mount-ensure check originally lived only inside remote_build.sh (the agent, which only runs after repo_build_remote.sh has already mkdir’d and rsync’d into REMOTE_BUILD_ROOT, i.e. under /data). On a freshly-rebooted board (confirmed with eurobuild4 after the user rebooted it to clear a stuck build) /data isn’t mounted yet at that point, so the mkdir itself failed – Permission denied (the bare unmounted mountpoint dir is root-owned). Fixed by moving the mount-ensure+stale-nbd-retry check into repo_build_remote.sh, running before its own mkdir/rsync steps – removed the now-redundant duplicate from remote_build.sh, single source of truth.
  • More generally: these boards accumulate real leftover build state across sessions (the user’s own prior manual work, or an earlier failed automated attempt) in ways a fresh rsync push doesn’t clean, because VCS source checkouts and $srcdir extractions live entirely on the remote board, never touched by the push/pull steps that only move PKGBUILD/patches/*.pkg.tar.*/logs. If a remote build fails with something that looks like stale state (a file “already exists”, a corrupted git ref, etc) rather than a real build error, ssh in and look at what’s actually sitting in REMOTE_BUILD_ROOT/<pkgname>/ before assuming it’s a new bug – hit both a corrupted brotli git clone (fatal: bad object refs/remotes/origin/test_902775910, fixed with rm -rf to force a fresh clone) and the $srcdir case above for pacman-static on eurobuild4/5/14 in the same session, both pre-existing from before this session touched these boards at all.
  • Stale local sync db right after publishing a dependency (2026-09-06): i686-elf-pcc-git (aarch64) failed with error: target not found: i686-elf-pcc-libs even though i686-elf-pcc-libs-git (which provides=(i686-elf-pcc-libs)) had just been built+published to archlinuxaba successfully, ~25s earlier. Confirmed via ssh build@eurobuild14 "pacman -Ss i686-elf-pcc-libs" – not visible until a manual sudo pacman -Sy was run, after which it resolved immediately (and the built package’s own .PKGINFO did have the right provides line all along – not a PKGBUILD bug). archlinuxaba’s Server = line points straight at archlinux32.andreasbaumann.cc (no separate mirror), so this reads as either a CDN/reverse-proxy cache TTL on archlinuxaba.db.tar.gz in front of that host, or just pacman’s ordinary “sync db isn’t auto-refreshed on every -S” behavior combined with these boards’ sync db legitimately being minutes stale from whenever they last ran -Sy on their own. Either way: when a queued build depends on a package published to the same remote-arch earlier in the same session, don’t assume an immediate retry failing on a missing/unresolvable dep means a real problem – ssh in and force sudo pacman -Sy on that board first, or just leave a minute or two of gap between publishing a dependency and building something that needs it there.

• Build concurrency: local archs (i486/i686/pentium4/x86_64) share this one euronuc host and must run one at a time; the three remote ARM boards are physically separate single-board machines and are safe to build on in parallel with each other (and with whatever’s running locally). Confirmed by the user 2026-08-27. Don’t launch two local chroot builds concurrently on euronuc (e.g. two repo_release.sh/repo_build_staged.sh invocations that both reach a local archlinuxaba-<arch>-build) – not a supported pattern here.

  • repo_build.sh now does this automatically within one invocation (fixed 2026-08-27, same session): its per-arch loop still runs local archs one at a time (blocking, as before), but each remote-arch dispatch is launched in the background immediately (output captured to a per-arch log under a mktemp -d tmpdir) and all of them are wait-ed on together after the loop, so they run in parallel with each other and with whatever local chroot sequence is still going. This is the preferred way to get parallelism now – don’t manually split a single package’s build into several REPO_BUILD_ONLY_ARCH-scoped repo_release.sh invocations launched concurrently (that was the old workaround, e.g. done for pacman-static/libarchive-static earlier this same session before this fix landed) unless deliberately re-testing one specific arch in isolation.
  • Still true, unrelated to the above: two invocations of repo_build_staged.sh/repo_release.sh for the same package at once (e.g. one from a human, one from an agent, run by mistake) would share one local staging dir (/data/INSTALL/<pkgname> on euronuc) and can still race – this fix doesn’t change that, it just removes the need to do that manually for parallelism.

• eurobuild4’s bash (5.1.16) parses if [[ ... ]] then (no ; before then) as a hard syntax error; bash 5.3.15 (eurobuild5/14, and this host) accepts it. Confirmed 2026-08-27 via pacman-static’s upstream PKGBUILD, which has exactly this idiom in its _git_patch_level_commit check – PKGBUILD: line N: syntax error near unexpected token 'then' on eurobuild4 only, everything else (including local i486, also 32-bit) built fine. Reproduced directly: bash -c 'if [[ 1 != 2 ]] then echo yes; fi' fails on 5.1.16, succeeds on 5.3.15 – a real bash grammar change between those versions, not a chroot/toolchain quirk. Fix is always the same and always safe: add the missing ; before then – valid on every bash version, no behavior change. If a different package’s PKGBUILD fails to even source on an armv6h remote build with a “syntax error near unexpected token” message, check for this exact idiom (grep -n ']] then$' or similar) before assuming it’s the git-checksum issue above or something board-specific.

• repo_publish.sh couldn’t publish a package with an epoch in pkgver (fixed 2026-08-27, found via eclipse-java-bin’s 2:4.40-1) – the resulting filename has a literal : before the first / (e.g. eclipse-java-bin-2:4.40-1-x86_64.pkg.tar.zst), which rsync parses as host:path remote syntax; since the destination arg is also remote, it fails with “The source and destination cannot both be remote.” Fixed by prefixing pkgfile/sigfile with ./ before the repo_rsync call whenever they don’t already start with / (prepending it to an already-absolute path would wrongly root it at $PWD instead). Affects any package with an epoch, not just this one.

• repo_build.sh’s untracked-cleanup could delete a staged build’s own fresh logs (fixed 2026-08-28, found via cssh) – the cleanup at the end of a real build is meant only for the git-tracked arch/ tree (per its own header comment), and normally skips a /data/INSTALL staged copy automatically since git status fails there (“fatal: not a git repository”). That protection was only incidental, though: cssh’s staged dir happened to already be a real git checkout (a leftover stand-alone AUR clone predating repo_build_staged.sh ever touching it), so the cleanup ran there too and deleted that run’s own -prepare.log/-build.log/ -package.log right after makechrootpkg created them (it always passes --log to makepkg itself, so these are produced unconditionally for every chroot build, independent of anything in /etc/makepkg.conf’s BUILDENV). Fixed by skipping the cleanup outright whenever pkgdir is under /data/INSTALL, rather than relying on it accidentally not being a git repo.

• scripts/repo_arch_status.sh <pkgdir> (added 2026-08-28) prints a per-arch table (machine / published version / best-effort “building” flag) for one package – see the script’s own header for exactly what the “building” heuristic can and can’t detect (local: any chroot build for that arch, not necessarily this package; remote: precise, via a live makepkg process’s cwd on the mapped board). Queries the live repo db (curl + bsdtar on os/<arch>/<reponame>.db.tar.gz) for the published-version column, so it reflects reality even across separate sessions, not just this one’s own job logs. Skips any arch with no local build command and no mapped remote host (never actually attempted by repo_build.sh either – always SKIPPED there) – catches a leftover generic arm entry some PKGBUILDs still carry alongside the real armv6h/armv7h/aarch64.

• scripts/check_aur_feedback.sh silently never fetched a single comment when invoked the normal way – fixed 2026-08-28. The script computed script_dir=$(dirname "$0") (left relative, e.g. arch/scripts) and then cd’d to ${script_dir}/.. – fine for the RPC-info/flag part, which only used the now-absolute $(pwd). But the later python3 "${script_dir}/aur_comments.py" ... call still used the original relative script_dir string, now resolved against the new cwd – doubling the prefix (arch/arch/scripts/aur_comments.py, “No such file or directory”). Every single comment-fetch call failed this way and was swallowed into aur_feedback_state/aur_comments.err (python3: can't open file ...), so check_aur_feedback.sh always printed “Nothing new to report” for comments (RPC-based OutOfDate flags were unaffected, since that part never depended on script_dir after the cd). Reproduces on any invocation with a relative $0 from outside arch/scripts/ – i.e. exactly the normal arch/scripts/check_aur_feedback.sh invocation from the toplevel dir. Caught by chasing why a genuinely new (2026-08-28) pacman-static AUR comment thread never showed up in FEEDBACK.txt despite the script reporting success. Fix: resolve script_dir to an absolute path up front, script_dir=$(cd "$(dirname "$0")" && pwd), before the cd "..". Unknown how long this was broken for – treat any pre-2026-08-28 “nothing new” comment result from this script with suspicion; the aur_feedback_state/*.seen files may be missing a real backlog for packages that got few/no other RPC-flag changes to mask the failure. Consider a one-time full re-check across every package now that the fix is in, to surface anything swallowed while it was broken.

• scripts/repo_arch_diff.sh (added 2026-08-28) is the multi-arch counterpart to repo_diff_local_remote.sh’s single-arch check: for every local PKGBUILD, compares its wished arch=() set (read from .SRCINFO’s arch = lines – note these are tab-indented under pkgbase, so the awk match must NOT anchor with ^, unlike the ^pkgbase =/^pkgname = lines it also reads; got this wrong on the first pass, silently making every package look like arch=any) against what’s actually published per arch, across every arch this project can actually build (same local-build-command-or-mapped- remote-host filter repo_arch_status.sh already uses, so a leftover unbuildable arch=() entry like a stray arm doesn’t show up as a false gap – pacman-static’s PKGBUILD has exactly this, confirmed harmless). Fetches each buildable arch’s remote package-name set ONCE via the same lightweight repo_ssh + ls repo_diff_local_ remote.sh already uses (not per-package – 7 ssh round-trips total, not 7×~250), so it stays cheap enough for generate_overview.sh to call on every run. Feeds the Architectures column there (✅ wished and published, ❌ wished but missing, ➕ published but no longer wished). arch=('any') is resolved to “every buildable arch” before comparison – no special-casing needed beyond that substitution, since repo_publish.sh’s own any-package fan-out (upload once to os/x86_64, symlink every other arch’s os/<arch> dir at it) means the per-arch ls listing already picks the symlinks up like any other file. Scope matches repo_diff_local_remote.sh: the arch/ tree only, not the install_only_packages /data/INSTALL gap-fillers (those get - in the Architectures column).

• A validpgpkeys-related “unknown public key” build failure may just need a plain gpg --recv-keys <fingerprint> as the build user on euronuc (host, outside any chroot) – try that before assuming a deeper chroot-keyring infrastructure fix is needed. Resolved a multi-week mod_fcgid blocker this way 2026-08-30 (the key wasn’t fetchable from hkps://keys.openpgp.org but was from hkps://keyserver.ubuntu.com); see memory/mod_fcgid.md for the full investigation and the remaining uncertainty about exactly why this works (a host-side gpg --recv-keys shouldn’t, in principle, reach the ephemeral per-build chroot user’s own keyring, but empirically it did here).

• scripts/add_maintained.sh used to add every vendored-from-AUR package under maintained/ unconditionally – fixed 2026-08-30 after it silently mis-categorized mod_fcgid/perl-crypt-rijndael (vendored to unblock thruk; neither is actually maintained or co-maintained by AUR_USER_NAME, see memory/mod_fcgid.md’s dated entry for the discovery and the after-the-fact git mv fix). Logic moved into a new shared scripts/add_aur_package.sh <category> <pkgname>, with add_maintained.sh/new add_adapted.sh as thin wrappers (exec add_aur_package.sh <category> "$1"). Adding under maintained now checks the package’s real AUR HTML page (not the RPC API’s Maintainer field, which only ever exposes the primary maintainer – AUR renders co-maintainers as “PrimaryName (andreas_baumann)” in the same table cell, so RPC alone would also wrongly refuse a package we’re legitimately a co-maintainer of, e.g. pacman-static) for whether config/global.conf’s AUR_USER_NAME appears anywhere in the Maintainer table cell, and refuses (not just warns) to add under maintained/ if not, pointing at add_adapted.sh instead. No check for adapted/owned/private – adapted is explicitly for packages we don’t maintain upstream, the other two don’t carry the same implication. A fetch failure (network hiccup, or the package genuinely doesn’t exist on AUR) warns and proceeds rather than blocking, since git submodule add itself will fail loudly right after for a nonexistent package anyway.

• arch/<category> taxonomy, spelled out plainly after getting it wrong twice in one session (mod_fcgid, perl-crypt-rijndael, 2026-08-30 – see their memory files for the full story):

  • maintained/ – git submodule, AUR git remote. We are the AUR maintainer or co-maintainer (able to push there). Added via scripts/add_maintained.sh, which now enforces this.
  • adapted/ – plain, directly-tracked files, never a submodule. For a package with a real local diff on top of someone else’s upstream (patches, PKGBUILD edits) – every single entry in arch/adapted/README.md names one. Not a submodule because we’re diverging from their history, not tracking it. A package we don’t maintain but also haven’t modified at all does NOT belong here – there’s nothing to diff.
  • owned/ – git submodule, AUR git remote, but the upstream software itself is the user’s own project (e.g. cssh) – unlike maintained/, the actual source isn’t AUR-native, just packaged there.
  • private/ – mixed: some are submodules pointing at a private (non-AUR) git remote the user created, specifically to preserve commit history for a package that was later deleted from AUR (gsoap287, notion3); others are plain directly-tracked files, same as adapted/. Which one depends entirely on that package’s own history, not a blanket rule.
  • Anything else (someone else’s package, zero local modifications, not installed locally for personal use either – just a dependency we need built once) – doesn’t belong under arch/ at all. Use the install_only_packages + /data/INSTALL/<name> plain-checkout pattern (local-install/ prefix) instead.

• scripts/install_only_packages – what it is and how it’s read (moved here from the file’s own header comment 2026-08-31, to keep that file a plain scannable list rather than prose): lists packages with no PKGBUILD under arch/<category>/<name>/ – either moved out entirely (upstream absorbed the local patch and the arch/ copy was deleted, or it never had one checked in to begin with) – that should still show up in OVERVIEW.md via generate_overview.sh’s /data/INSTALL fallback. One <category>/<name> per line, blank lines and # comments ignored. <name> must exist as /data/INSTALL/<name>/PKGBUILD – generate_overview.sh warns and skips (doesn’t abort) any entry where it doesn’t. An entry for a package that’s since moved back into arch/<category>/<name>/ PKGBUILD is also silently skipped (normal discovery already covers it), so a stale line is harmless – no need to rush to delete one.

  • The local-install/ prefix specifically covers plain, unmodified upstream AUR packages – not maintained/adapted/owned by us, just periodic rebuilds of someone else’s PKGBUILD kept out of arch/ on purpose (no local diff to track, so adapted/ doesn’t fit either – see memory/mod_fcgid.md’s 2026-08-30 entry for the mistake this convention now prevents). Two origin stories so far: most were installed via yay on the local machine for its own use and rebuilt here so archlinuxaba carries them for the cluster too; a few (e.g. perl-crypt-rijndael) were pulled in purely as AUR dependencies to unblock another package’s build (thruk) and never installed locally at all – both count. (mod_fcgid was briefly here too, but moved to adapted/ once it turned out to need a real local deviation – a vendored PGP key – see memory/mod_fcgid.md.)

• A remote ARM board can be up (pingable, SSH-reachable) but still fail modprobe nbd – check whether it’s just waiting on a reboot after a kernel package upgrade before assuming a deeper problem. Hit on eurobuild14 2026-08-31 (cssh/perl-crypt-rijndael ARM catch-up after the whole cluster had been down): modprobe: could not insert 'nbd': Unknown symbol in module, root cause uname -r (7.2.0-2) not matching the installed linux-aarch64 package (7.2.2-2) – /lib/modules/ only had dirs for 6.10.5-3 and 7.2.2-2, nothing for the actually-running 7.2.0-2 anymore (a pending upgrade already pacman -Syu’d but never booted into). User has authorized rebooting these boards whenever this exact symptom (/data mount failing because of an nbd module mismatch) shows up – ssh build@<host> "sudo reboot", wait for it to come back (ping + a real SSH command succeeding, not just ping – see memory/cssh.md’s 2026-08-31 entry for the wait-loop shape used), then sudo modprobe nbd to confirm before retrying the build.

• REPO_BUILD_ONLY_ARCH restricts what repo_build.sh attempts to build, not what repo_publish.sh ends up publishing. The publish step still globs every *.pkg.tar.* sitting in the pkgdir regardless – for a package with older, already-built files for other archs still present there (e.g. a /data/INSTALL-direct package, which – unlike an arch/-staged one – never gets its old artifacts swept by repo_build_staged.sh’s defensive pre-clean), those get re-uploaded too. Harmless when the version hasn’t changed (identical bytes, redundant re-publish), but don’t treat REPO_BUILD_ONLY_ARCH as an end-to-end “only touch this one arch” guarantee. Noticed 2026-08-31 rebuilding perl-crypt-rijndael’s armv7h alone – i686/x86_64 got silently re-uploaded too.

• repo_build.sh supports an opt-in MAKEFLAGS="-jN" override for local chroot build parallelism (added 2026-09-04) – but getting this right took two attempts; the first one silently didn’t work. Initial (wrong) understanding: a plain sudo --preserve-env=MAKEFLAGS around the local build commands would be enough, since the host’s /etc/makepkg.conf seemed to play no role (confirmed at the time: systemd-nspawn binds nothing from /etc into the chroot). That was incomplete – makechrootpkg itself (not the chroot) calls load_makepkg_config() (from /usr/share/makepkg/util/config.sh) once per invocation, which unconditionally re-sources the HOST’s /etc/makepkg.conf on the host side, and MAKEFLAGS is NOT among the vars that function preserves across that reload (PKGDEST/ SRCDEST/PACKAGER/etc. are, MAKEFLAGS isn’t – see its restore_envvars list). So our exported MAKEFLAGS survived through sudo --preserve-env only to get silently clobbered right back to the host’s own value a few lines later, before makechrootpkg’s separate step (the one that actually bakes MAKEFLAGS into the chroot copy’s /etc/makepkg.conf) ever ran. This was caught, not assumed: a real linux-lts515 pentium4 build was launched with MAKEFLAGS=-j6, left running for ~5 minutes, and only then checked by grepping the actual chroot copy’s baked /etc/makepkg.conf (/var/lib/archbuild/<repo>-<arch>/build/etc/makepkg.conf) – it showed MAKEFLAGS='-j1' (the host’s value), not -j6. Always verify this way (grep the live chroot copy’s own makepkg.conf during a real build) rather than trusting the sudo --preserve-env/printenv chain alone – that chain looked correct in isolation but missed this internal reload.

  • Fix: load_makepkg_config() also honors a MAKEPKG_CONF env var naming an alternate file to source instead of /etc/makepkg.conf. When the caller sets MAKEFLAGS, repo_build.sh now also generates a scratch copy of the host’s /etc/makepkg.conf with just its MAKEFLAGS= line commented out, symlinks <scratch>.d to the real /etc/makepkg.conf.d (load_makepkg_config also globs $MAKEPKG_CONF.d/*.conf for e.g. rust.conf/fortran.conf – a relocated path without this symlink would silently lose those), exports MAKEPKG_CONF pointing at the scratch copy, and preserves both MAKEFLAGS and MAKEPKG_CONF through the local sudo calls. Confirmed working against the real chroot afterward: baked MAKEFLAGS='-j6'.
  • This still never touches the real host /etc/makepkg.conf – the scratch file is generated fresh per invocation and cleaned up via an EXIT trap – so the safety property the user asked for (can’t affect the separate, unrelated Archlinux32 builder daemon also running on this host, since that’s its own process tree with its own environment) still holds. Only the mechanism for reaching that goal changed, not the goal or the constraint.
  • Only affects the local chroot build path. Remote-board builds (repo_build_remote.sh, plain makepkg -s on the board, no chroot) are unaffected either way – recorded with a fixed remote parallelism label regardless.

• repo_build.sh now times every arch it actually builds (local or remote; not REUSED/SKIPPED) and records it via the new scripts/repo_record_build_time.sh <pkgname> <arch> <seconds>, which upserts a <!-- BUILD-TIMES:START/END -->-delimited “Build times (auto-updated)” block near the top of memory/<pkgname>.md (added 2026-09-04, at the user’s request, so a future rebuild of the same package can get a rough ETA from the last measured duration instead of an unknown wait – e.g. linux-lts515’s multi-hour x86_64 compile). <pkgname> here is the package directory’s basename, same key generate_site.sh already uses to link a package to its memory note (so a split package’s timings land on the shared pkgbase/ dirname note, not any one of its sub-pkgnames). The block only tracks the last measured duration per arch, not a history – intentional, it’s for ETAs, not a build-time log; the existing hand-written prose entries below the block remain the place for that. If the memory note doesn’t exist yet, the script creates a minimal one (just the title + block) rather than skipping – still gets filled in properly by hand afterward per the usual per-package-memory convention.

  • Each recorded line also carries the parallelism used (added same day): repo_record_build_time.sh takes an optional 4th arg, rendered as (<when>, <parallelism>). repo_build.sh derives it itself per build path – local chroot builds: MAKEFLAGS=-jN if the caller exported MAKEFLAGS (see the sudo --preserve-env=MAKEFLAGS note below), else serial; remote-board builds: a fixed remote label, since that board’s own local config governs its parallelism, not anything this project controls.
  • The block’s closing <!-- BUILD-TIMES:END --> is followed by a --- (Markdown thematic break) before whatever content already followed the title line (e.g. many notes have a - Path: ... bullet right after the title). Confirmed directly against lowdown: two bullet lists separated only by a blank line get merged into one continuous <ul> per CommonMark’s own list rules – without the ---, the auto-generated Build-times list silently swallowed the very next unrelated bullet (e.g. - Path: ...) into the same rendered list, misrepresenting it as a build-time entry. The --- is only ever inserted the one time the block is first created; a later in-place update of an existing arch’s line never touches anything outside the START/END markers, so it’s undisturbed on every subsequent rebuild. If a future template/lowdown-invocation change ever alters list-merging behavior, re-check this with lowdown -s -o out.html in.md on a memory note that has both a Build-times block and a - Path: ... line right after it.

• generate_overview.sh and check_for_updates_maintained.sh were slow (a full run: 20-30+ min) despite the --only <category>/<pkgname> scoping mechanism already documented in generate_overview.sh’s own header – the scoping just wasn’t being used for routine single- package publishes. Fixed/improved 2026-09-10:

  • Use --only <category>/<pkgname> after every routine single- package build+publish, not a full run – it skips both slow phases below entirely and takes a few seconds. Requires OVERVIEW_CACHE.tsv to already exist (any prior full run writes it). A full run is still needed after anything a --only run can’t reconcile: a deleted/renamed package (confirmed removing arch/maintained/qt5-examples, a duplicate submodule, needed one to purge its stale row – see memory/qt5-doc.md).
  • check_for_updates_maintained.sh’s main loop parallelized (bounded batches of 8, POSIX-portable – no wait -n/bashisms, each job in its own subshell writing to its own temp file so cds and output can’t race, concatenated back in original order afterward): a full ~126-package nvchecker sweep dropped from several minutes serial to 34s measured clean.
  • generate_overview.sh’s own /data/INSTALL gap-filling loop parallelized the same way: mostly ~2-3s/package serially, but a few entries with large generated PKGBUILDs (php74’s arch-phpbs-generated PKGBUILD, hundreds of variables) cost 50s+ of pure fork/CPU time each and dominate a serial run. Not yet cleanly re-measured – the one test run so far (24m30s, barely better) was contaminated by unrelated concurrent package builds (optdb5.3/cyrus-imapd2) hammering the same 8-core host at the same time; re-measure in isolation before trusting that number.
  • Real correctness bug found and fixed while testing the above, pre-existing and unrelated to the parallelization itself: a --only run on any package outside maintained/ (i.e. private//adapted//owned/, where check_for_updates_ maintained.sh legitimately produces zero output by design) hit a GNU awk 5.4.1 quirk: the merge awk’s FNR==NR {next} {...} idiom, given a truly zero-byte first file argument, silently produces zero output for the second file too – not the “just skip the empty file” behavior every other awk (and other gawk versions) gives. Confirmed directly: awk 'FNR==NR{next}{print}' emptyfile realfile prints nothing on this host, but works the instant emptyfile has even one blank line. This silently dropped the row for the touched package and fell back to its stale cached entry – caught testing --only private/optdb5.3 right after a real rebuild, where the report kept showing the old pkgrel/arch coverage. Fix: force upstream_file to have at least one line (test -s "${upstream_file}" || printf '\n' >"${upstream_file}") right after check_for_updates_maintained.sh writes it – the merge awk’s own NF < 3 guard already discards a blank line harmlessly, so this changes nothing for the maintained/ case where the file was never empty to begin with.

• repo_build.sh’s local (euronuc) chroot builds now write a live log into pkgdir as the build happens, 2026-09-10 – requested directly: “It would be nice if I could live review the logfile in a place I am familiar like /data/INSTALL/.” Before this, archbuild/makechrootpkg builds inside an ephemeral chroot filesystem and only copy their own <pkgname>-<pkgver>-<pkgrel>- <arch>-build.log (plus -prepare/-package logs) back into pkgdir once the whole build finishes – confirmed directly with a real build stuck at 73%/79% progress with zero *.log files in pkgdir yet. The remote ARM boards already tee their own build output live (remote_build.sh), but only onto their own filesystem – that doesn’t reach euronuc’s /data/INSTALL/<pkg> live either, only once the whole remote build finishes and gets rsynced back (confirmed with the user 2026-09-10: the ARM-board case is already fine as-is, since they can just log into the board directly and tail -f there – only euronuc’s local path needed fixing).

  • Fix: both local-build call sites in repo_build.sh (the arch=any branch and the per-arch loop) now do set -o pipefail; sudo ... "${_cmd}" 2>&1 | tee -- "${_livelog}" instead of a bare sudo ... "${_cmd}", where _livelog is a new _live_build_logfile <arch> helper: <pkgname>-<arch>-live- build.log. set -o pipefail (confirmed working in oksh directly: false | true reports exit 1 with it, 0 without) is needed so the real build command’s exit status survives the pipe instead of tee’s own (always-0) status winning – set +o pipefail immediately after, in both the success and failure branches, so it doesn’t leak into the rest of the script.
  • Deliberately a different filename from archbuild’s own log, not a reuse of the same name: the tee’s file handle stays open (appending) for the whole build, while archbuild’s own copy-back writes its differently-named log once, synchronously, right before the sudo command returns. Reusing the same name would mean two writers racing one path at the exact moment the build finishes. Confirmed both coexist cleanly with a real test build (bochs-gdb- stub, build-only via REPO_BUILD_ONLY_ARCH=x86_64 repo_build.sh <tmp-pkgdir>, no publish): the live log (172592 bytes) and archbuild’s own bochs-gdb-stub-2.8-1-x86_64-build.log (146208 bytes) both ended up present and intact, no corruption, no race – they just capture slightly different scope (the live one includes the outer chroot-sync noise the wrapper prints; archbuild’s own is scoped to just the inner makepkg phases).
  • No cleanup logic needed for the new file: /data/INSTALL-staged builds already keep every build byproduct around for inspection (repo_build.sh’s own end-of-run cleanup explicitly skips anything under /data/INSTALL, see this file’s own private_repo_publish_ design-adjacent notes), and a direct in-place arch/<category>/ <pkg> build’s existing git-status-driven untracked-file cleanup picks the live log up automatically like any other build byproduct.

• pkgname= extraction via a naive sed -n 's/^pkgname=\(.*\)$/\1/p' breaks on a split package’s array-with-variable-interpolation form, found 2026-09-10 building gcc10 for aarch64. gcc10’s PKGBUILD has pkgname=("${pkgbase}" "${pkgbase}-libs" "${pkgbase}-fortran") – completely standard, correct split-package syntax, not a PKGBUILD bug. The sed just grabs the raw line text verbatim, without evaluating shell arrays/variables, so it produced a literal (${pkgbase} ${pkgbase}-libs ${pkgbase}-fortran) as the “pkgname” – visible directly as a garbled live-build-log filename on eurobuild14 (user caught it: “this looks like a variable substitution bug”). Same fragile pattern existed in 3 places across 2 scripts: remote_build.sh’s own live-tee logfile naming (where the user actually saw it), and both repo_build.sh helpers added/ touched this session (_live_build_logfile, the pre-existing _existing_pkg_file). A 4th occurrence, in repo_arch_status.sh, turned out to already be correct – useful confirmation the fix below matches an already-proven pattern in this codebase, not a new invention.

  • Fix, all 3 broken spots: prefer pkgbase= (always a plain scalar by Arch packaging convention for a split package) over pkgname=, falling back to pkgname= only when no pkgbase= line exists at all (a non-split PKGBUILD). repo_build.sh got a shared _pkgbase_or_pkgname() helper for both its call sites; remote_build.sh (a separate deployed file, self-contained) got the same two-step fallback inlined. Verified directly against gcc10’s real PKGBUILD (resolves to plain gcc10, not the garbled array text) before relying on it for a real build retry.
  • The pkgbase-preference fix above wasn’t actually general enough – hit a second variant of the same bug on the very next build. cmake2 (built immediately after gcc10 in the same session) has no pkgbase= line at all (not a split package) and a plain-scalar-but-interpolated pkgname: _pkgname=cmake; pkgname=${_pkgname}2. The pkgbase-preference fallback still hits the same raw-text pkgname= sed for this case, producing a literal ${_pkgname}2 – visible again as a garbled live-log filename (${_pkgname}2-x86_64-live-build.log), this time caught directly rather than pointed out by the user.
  • Real fix, superseding the pkgbase-preference patch: no sed pattern against raw PKGBUILD text generalizes to every variable/array shape pkgbase=/pkgname= can take. Switched to makepkg --printsrcinfo | awk -F' = ' '$1 == "pkgbase" { print $2; exit }' – --printsrcinfo already fully evaluates the PKGBUILD (same tool this project’s own scripts use to regenerate .SRCINFO), so its output’s first line is always the correctly- resolved pkgbase = <name>, split or scalar, array or plain, interpolated or not. No network access, no source download – confirmed side-effect-free. Verified directly against both gcc10 (gcc10, not the garbled array text) and cmake2 (cmake2, not the garbled ${_pkgname}2) before trusting it. Applied to both repo_build.sh’s shared _pkgbase_or_pkgname() helper and remote_build.sh’s separate inlined copy.
  • The narrower single-element-array gap (pkgname=('foo')) this note originally flagged as “worth fixing if it ever causes a real incident” is now moot – the --printsrcinfo-based fix handles that case correctly too, same as every other shape, since it’s real evaluation rather than pattern-matching against specific textual forms.

2026-09-11: remote-board build times now label MAKEFLAGS/serial, not a bare “remote”

repo_record_build_time.sh’s “Build times” block in each package’s memory note already labeled local chroot builds with their actual parallelism (MAKEFLAGS=-jN or serial, derived from repo_build.sh’s own MAKEFLAGS env var), but remote ARM-board builds (eurobuild4/5/14) just got a fixed remote – no indication of whether that board built serially or with some -jN. User asked for parity with the local labels.

Fix: scripts/remote_build.sh (the agent script deployed to and run on the board) now resolves its own effective parallelism the same way makepkg itself would – MAKEFLAGS from the environment if exported (it currently isn’t, in the non-interactive ssh session this runs under), else parsed out of the board’s own /etc/makepkg.conf (last uncommented MAKEFLAGS= line, quotes stripped) – and echoes it as REMOTE_BUILD_PARALLELISM: MAKEFLAGS=-jN (or ...: serial) to stdout before starting the build. That line lands in the ssh output repo_build_remote.sh returns, which repo_build.sh already captures per-arch into ${_remote_tmpdir}/${arch}.log; on a successful build, repo_build.sh now greps that line back out and passes "remote, ${label}" (e.g. remote, MAKEFLAGS=-j2, remote, serial) to repo_record_build_time.sh instead of the bare remote. Falls back to plain remote if the line isn’t found (e.g. an older/unpatched remote_build.sh still cached on some board before its next self-deploy refresh).

No pkgdir files involved – the label rides through stdout/the existing log capture, not a synced-back sidecar file, so no new stray-file cleanup concern (cf. feedback_check_stale_artifacts_before_build.md).

2026-09-11: use MAKEFLAGS=-j6 for local euronuc builds going forward

Local chroot builds (x86_64/i686/pentium4/i486 on euronuc) have always been single-threaded by default (/etc/makepkg.conf’s MAKEFLAGS="-j1"), since repo_build.sh’s MAKEFLAGS passthrough (added 2026-09-04) is an opt-in the caller has to set, not a default. Came up when asked whether local archs could build in parallel with each other – they can’t, safely, as-is: every local arch’s chroot binds the same host pkgdir as both /startdir and /srcdest (no per-arch isolation the way the remote-board path already has, where each board gets its own rsynced copy), so two local archs building at once would race on the same src/ extraction. Cross-arch parallelism would need real staging work (isolate each local arch into its own copy, mirroring the remote pattern) – not done.

The safe, immediate win instead: set MAKEFLAGS=-j6 when invoking repo_release.sh/repo_build_staged.sh for local builds, so each (still-sequential) arch build at least uses multiple cores to compile. -j6 (not -j8, euronuc’s full core count) leaves headroom for the separate Archlinux32 builder daemon that also runs on this same host – same reasoning repo_build.sh’s own MAKEFLAGS mechanism was built around in the first place (never touches the real /etc/makepkg.conf, see the 2026-09-04 entry above). Adopted as a standing convention going forward, not a one-off.

2026-09-11 (same day, follow-up): MAKEFLAGS=-j6 baked in as an actual script default

Per direct follow-up request, the convention above is no longer just a “remember to pass it” habit – scripts/repo_build.sh now has : "${MAKEFLAGS:=-j6}" + export MAKEFLAGS right after its REPO_BUILD_ONLY_ARCH default. Still fully overridable by an explicit caller-set MAKEFLAGS (e.g. MAKEFLAGS="-j1" for the old serial behavior). The explicit export matters: if a caller never sets MAKEFLAGS at all (now the common case), := alone would only create a local shell variable that sudo --preserve-env=MAKEFLAGS further down couldn’t see.

Verified end-to-end against a real chroot build, not just an env-passthrough test (see this file’s 2026-09-04 MAKEFLAGS entry for why that alone isn’t trustworthy): ran scripts/repo_build_staged.sh adapted/gconf with no MAKEFLAGS set, confirmed MAKEFLAGS=-j6 + the scratch MAKEPKG_CONF in the actual running makechrootpkg/sudo processes’ environment via /proc/<pid>/environ, and confirmed the auto-recorded build time picked up the new label (memory/gconf.md: x86_64 41s, MAKEFLAGS=-j6, down from a prior serial run’s 55s).

Gotcha hit while verifying: repo_build_staged.sh copies built .pkg.tar.* back into the git-tracked arch/<category>/<pkg>/ dir by design (so repo_release.sh can find them to sign/publish) – calling it directly for a build-only test, with no follow-up repo_release.sh, leaves those files sitting in the git tree; cleaned them up manually afterward. Not a bug, just something to remember when testing the build step in isolation.