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