aurupdater

check_ssl_cert

Build times (auto-updated)

2026-10-20/21: routine bump 2.103.3 -> 2.103.4

Full update_cycle.sh UPD flag. Standard recipe, built cleanly on 5/6 archs first pass (x86_64/i686/pentium4/armv6h/aarch64). armv7h hit a real infrastructure failure, not a transient one: mkdir: ... Input/output error on eurobuild5, traced to its /data (NBD-backed ext4) hitting real I/O errors mid-build – dmesg showed EXT4-fs error, an aborted journal, and the kernel force-remounting /data read-only, all within the same build attempt (kernel uptime timestamps lined up almost exactly). Confirmed via a direct ssh write test (touch failed with “Read-only file system”). Not something to retry past or fsck unilaterally – flagged to the user, who checked the board physically and confirmed it back up (mount showed rw again, write test passed, df showed normal free space). Retried REPO_BUILD_ONLY_ARCH="armv7h" repo_release.sh maintained/check_ssl_cert alone once confirmed healthy – built and published cleanly, no further issues. All 6 archs now at 2.103.4-1. If eurobuild5 does this again, check dmesg/mount there first before assuming it’s the usual AUR-mirror-style transient flakiness – this one was the board’s own storage, not network.

Build times (auto-updated)

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

Only genuine UPD from a routine full check_for_updates_maintained.sh sweep this session. Standard recipe (bump pkgver, updpkgsums, regen .SRCINFO), no v2.103.2 tag exists upstream – jumped straight from .1 to .3. Cleaned a stale 2.103.1-1-armv6h leftover from 2026-09-12 in /data/INSTALL first.

armv6h/armv7h/aarch64 all built and published cleanly first try (the ARM cluster was up this session) – this package’s arch=() already listed them, and unlike gconf/gcc47/lacc-git/slimcc-git there was no dependency gap or codegen-target issue, just genuinely never had a version bump land while the cluster existed. i686/pentium4 also clean as always.

x86_64 hit a real infrastructure snag: the archlinuxaba-x86_64-build chroot’s base core/extra/multilib mirror (archlinux.lan.brgn.ch, a LAN mirror, distinct from archlinuxaba’s own dedicated archlinux32.andreasbaumann.cc server) was 404ing on extra.db specifically (core.db fetched fine) – confirmed via direct curl against the mirror’s real path (/archlinux/$repo/os/$arch, not the naive /​$repo/os/$arch guess tried first). Not transient – failed identically on a second attempt minutes later. Fixed (user-approved) by adding Server = https://geo.mirror.pkgbuild.com/$repo/os/$arch as a fallback right after the broken line, in both /etc/pacman.d/mirrorlist (host) and /var/lib/archbuild/archlinuxaba-x86_64/root/etc/pacman.d/mirrorlist (the chroot’s own separate copy – not bind-mounted/live-synced from the host, so both needed the edit). x86_64 built clean on retry.

This LAN mirror gap likely affects every local x86_64 chroot build going forward until archlinux.lan.brgn.ch itself is fixed upstream – the fallback line should keep builds working regardless, but worth knowing this isn’t check_ssl_cert-specific if another package’s x86_64 build ever hits the same extra.db 404 (also relevant to i686/pentium4 chroots, which weren’t checked – they succeeded this run without needing the fallback, so may be pulling extra from a different/working mirror already, or just got lucky on cache).

All 6 archs published at 2.103.3-1 for the first time simultaneously.