aurupdater

gconf

Build times (auto-updated)

Not tracked in arch/ — plain upstream AUR package, rebuilt from a fresh clone of https://aur.archlinux.org/gconf.git into /data/INSTALL/gconf. See arch/scripts/install_only_packages (local-install category) and [[feedback_local_install_rebuilds]].

arch=($CARCH) breaks repo_build.sh’s arch parsing

Upstream PKGBUILD uses arch=($CARCH), a shell-variable arch declaration rather than a literal arch name. repo_build.sh (and build_all_archs.sh) extract arch=() with a plain sed, not a real shell eval, so they see the literal text $CARCH — which matches nothing, meaning every arch (including any REPO_BUILD_ONLY_ARCH restriction) gets SKIPPED and the whole build aborts with “no arch built successfully” even though a real makepkg run would resolve $CARCH correctly at build time.

Fix applied 2026-08-14 (inline PKGBUILD edit, local-only, will NOT survive a fresh git clone from AUR — must be re-applied on future rebuilds): changed arch=($CARCH) to a literal arch=(x86_64) before building, since this project only builds x86_64 for this package anyway. If a future rebuild needs another arch too, just change the literal list instead of restoring $CARCH.

2026-08-14 build

Published x86_64 3.2.6+11+g07808097-15 (gconf + gconf-debug), built with REPO_BUILD_ONLY_ARCH=x86_64 originally intended but moot once arch=() was made literal.

2026-09-11: superseded by arch/adapted/gconf; test rebuild of the new remote build-time labels

The notes above (arch=($CARCH) parsing bug, local-install workflow) were about an older, untracked local-install clone at /data/INSTALL/gconf – this package is now tracked properly as arch/adapted/gconf (pkgrel 15.1, literal 7-arch arch=() already in place), and this memory file is shared between the two only because repo_record_build_time.sh keys by directory basename (gconf either way).

Rebuilt all 7 archs at the user’s request, specifically to verify the new remote-build parallelism labeling (remote_build.sh now reports its own effective MAKEFLAGS/serial back to repo_build.sh, see TOOLING_NOTES.md’s 2026-09-11 entry). Confirmed working as intended – see the Build times block above: armv7h/aarch64 (both real 4-core boards) show remote, MAKEFLAGS=-j4; x86_64 shows plain serial (no MAKEFLAGS set locally for this run).

pentium4/i686/i486/armv6h all failed identically and independently of this test: error: target not found: glib2-devel (a makedepends entry). x86_64/armv7h/aarch64 builds signed and published successfully; the 4 failing archs were left unpublished (no local .pkg.tar.* remained for them afterward, confirming they didn’t silently produce stale output).

Root cause, investigated 2026-09-11 on request: glib2-devel is in core, not extra – a fairly recent upstream Arch split of the glib2 package (glib2/glib2-devel/glib2-docs), not present in older glib2 builds. Checked each failing arch’s actual current core repo state directly against the local build chroots’ just-synced pacman dbs (archlinuxaba-<arch>/root) and the ARM board itself:

So this is the same shape of problem as notion3’s texlive-bin/texlive-basic lag (a secondary/embedded-arch build farm hasn’t rebuilt a package to match a newer split from upstream Arch yet) but a different package and, notably, not uniform across the 32-bit family – i486 is caught up while i686/pentium4 (usually the more actively maintained 32-bit archs) are not. Nothing to fix in this PKGBUILD: glib2-devel is a correct, real makedepends (only used for gconf’s own build, standard split). Revisit i686/pentium4/armv6h once their respective core/extra repos catch up with a newer glib2 – check with the same pacman -Sl core query against each chroot/board before assuming it’s fixed.