aurupdater

mod_fcgid

2026-08-30: resolved – built and published cleanly on x86_64

Re-vendored fresh from AUR (the whole package had been removed from arch/maintained/ at some point between 2026-08-02 and now, along with perl-plack/perl-log-dispatch – no longer needed as separate vendored packages since Arch’s own repos absorbed both since the first attempt). Confirmed via pacman -Si that only mod_fcgid and perl-crypt-rijndael still needed AUR vendoring out of thruk’s 18 declared dependencies – see memory/thruk.md.

Before rebuilding, re-read /usr/share/makepkg/integrity/verify_signature.sh to double check the 2026-08-02 finding that makepkg never auto-fetches a missing validpgpkeys entry (confirmed still true – it’s a plain gpg --verify against whatever’s already in the keyring, hard error otherwise, no keyserver fallback anywhere in that code path). Manually confirmed the key (5B5181C2C0AB13E59DA3F7A3EC582EB639FF092C) is fetchable from hkps://keyserver.ubuntu.com today (unlike hkps://keys.openpgp.org, which still has no data for it) via a plain gpg --recv-keys on the host (build user, euronuc) as part of this investigation.

Then just ran the real build (repo_release.sh) to get a current verdict rather than theorizing further – it passed: the log shows a genuine mod_fcgid-2.3.9.tar.bz2 ... Passed under “Verifying source file signatures with gpg”, not a skip. Built, signed, and published (mod_fcgid + mod_fcgid-debug, x86_64) with no PGP error at all.

Root cause of the original failure vs. this success is still not fully pinned down – the earlier investigation’s claim that the chroot’s ephemeral build-user keyring is fully isolated from the host’s may be incomplete (no /home bind mount or persistent .gnupg was found in the base chroot template on inspection), or the determining factor may simply be that the host’s own build user keyring already had this key from the gpg --recv-keys done moments before this rebuild, and that does somehow reach the chroot. Either way: if a validpgpkeys-related build failure recurs on any package, try a plain gpg --recv-keys <fingerprint> as the build user on euronuc (host, not inside any chroot) before assuming a deeper infrastructure fix is needed – that alone may be sufficient, as it was here.

2026-08-30: moved maintained/ -> adapted/ (wrong category at add time)

Vendored via scripts/add_maintained.sh, which is hardcoded to always add under maintained/ – but this project’s maintained/ means we are the AUR maintainer (or at least co-maintainer) of that package, and neither is true here: AUR shows mod_fcgid’s maintainer as sergej, last packager arojas, no mention of andreas_baumann anywhere (checked the actual package HTML page, not just RPC’s Maintainer field, which only ever shows the primary maintainer and would miss co-maintainer status too – see e.g. pacman-static’s page showing Morganamilo (andreas_baumann), the parenthetical being AUR’s co-maintainer notation). Since we have no push access and are just tracking sergej’s current AUR PKGBUILD as-is to unblock thruk, adapted/ is the correct category (wrong – see the next entry). git mv maintained/mod_fcgid adapted/mod_fcgid (submodule path + .gitmodules section name both updated) – no rebuild needed, the private repo publish itself doesn’t care which local category directory a package lives under. See memory/TOOLING_NOTES.md for the scripts/add_*.sh fix that should prevent the maintainer-check part of this going forward.

2026-08-30: adapted/ was also wrong – moved to local-install/

Two things caught this, both from the user directly: (1) adapted/ packages are never git submodules – confirmed against memory/private_repo_publish_scope.md: “private/ is a mix: some… are submodules, others… are tracked directly… same as all of adapted/”. (2) More fundamentally, adapted/ is specifically for a package with a real local diff on top of upstream – every entry in arch/adapted/README.md names one. I’d claimed mod_fcgid “now genuinely qualifies… it has the real strcasecmp patch” – false, that patch was for cssh (a completely different package this same session), not mod_fcgid. Actually diffed arch/adapted/mod_fcgid’s PKGBUILD against a live fetch of AUR’s current mod_fcgid PKGBUILD: zero differences. The GPG-key fix earlier this session was entirely external (gpg --recv-keys on the host, see the entry above) and never touched the PKGBUILD at all.

So: deinit’d and removed the submodule entirely (git submodule deinit -f + git rm -f + stripped the .gitmodules section – the .git/modules/maintained/mod_fcgid internal storage was still nested under the old pre-move path since git mv doesn’t relocate that, which made a first deinit attempt warn/fail to unset core.worktree; harmless, git rm still cleaned the index fine afterward). /data/INSTALL/mod_fcgid (from the original build) became its only home, added to scripts/install_only_packages as local-install/mod_fcgid.

Found something while doing this: /data/INSTALL/mod_fcgid wasn’t a fresh checkout – it already existed from the user’s own prior work, with a local-only commit from 2026-08-05 (“updated local PGP key”) that bumped pkgrel 5 -> 6 and added keys/pgp/5B5181C2C0AB13E59DA3F7A3EC582EB639FF092C.asc – the exact same key fingerprint identified independently this session. Never pushed (no push access upstream anyway; live AUR is still pkgrel=5). This session’s repo_build_staged.sh run rsync’d the pristine pkgrel=5 PKGBUILD from arch/ over this checkout’s working tree, so the file now reads pkgrel=5 again while commit 28b2889 (the pkgrel=6 bump) still sits in the local git history, unreferenced by the working tree.

2026-08-30: revived pkgrel=6 – this is a real local deviation, belongs in adapted/ after all

User chose to revive 28b2889 rather than leave it orphaned, and pointed out the obvious consequence: a vendored PGP key + pkgrel bump is a genuine local difference from upstream’s pkgrel=5 PKGBUILD – exactly the kind of thing adapted/ is for, unlike the zero-diff case that sent this package to local-install/ in the first place. diff between git show 28b2889:PKGBUILD and the pristine pkgrel=5 version confirmed the only changes are the pkgrel line and the new key file – no other content touched (the 2026-08-05 build logs already sitting in /data/INSTALL/mod_fcgid showed that pkgrel=6 attempt had compiled and packaged successfully at the time, good sign it’d work again).

Extracted the pkgrel=6 PKGBUILD + keys/pgp/*.asc from that commit (not by git checkout-ing the /data/INSTALL working tree in place – that directory stays a separate build-staging copy, not the source of truth) into a fresh plain, directly-tracked arch/adapted/mod_fcgid/ (PKGBUILD, the two upstream patches, keys/pgp/5B5181...asc, regenerated .SRCINFO – git add shows individual file adds, confirming no submodule got created this time). Added an arch/adapted/README entry. Removed the local-install/mod_fcgid line from scripts/install_only_packages (has a real arch/ PKGBUILD again; perl-crypt-rijndael stays there, it’s still a genuine zero-diff case).

Built and published cleanly on x86_64 at 2.3.9-6 – no PGP failure, no connection issues. Confirmed via repo_arch_status.sh: x86_64 euronuc published (2.3.9-6).