aurupdater

cloog

Build times (auto-updated)

Category: adapted/ (moved from local-install/ 2026-09-25 – the pentium4 addition and the TEXI2DVI patch below were already real local deviations, not an unmodified upstream copy; see [[feedback_local_adaptions_go_in_adapted]]). Dependency of gcc47 (depends=('cloog' ...)) and needs osl (also adapted/) as its own dependency.

Library that generates loops for scanning polyhedra.

Build notes (2026-08-17)

2026-09-25: aarch64/armv6h added (gcc47 ARM chain); i686/pentium4 hung on a stuck local chroot

pkgrel 1.2 -> 1.3, added aarch64/armv6h to arch=() (armv7h was already upstream-declared but never actually built/published until this pass either). Needs osl and libisl built for the same new archs first – see [[osl]] and [[libisl]].

i686 and pentium4 chroot builds both hung indefinitely (55+ min, zero I/O) at the exact same step: pacman -S --asdeps osl inside the chroot, after successfully downloading/verifying the package – stuck specifically in “Processing package changes… installing osl” with no forward progress. x86_64 (same host, same package) and the remote ARM boards were unaffected. Root cause: a completely unrelated, independently-running build job on this same host (extra-staging-i686-build, not ours – someone else’s official Arch 32-bit staging rebuild, observed running continuously for over an hour via ps aux) sharing the same /var/cache/archbuild32 bind mount that every local i686/pentium4 chroot uses – real disk/cache contention, not a bug in osl/cloog themselves. Confirmed by manually reproducing outside the pipeline (systemd-nspawn ... pacman -S osl directly): hung once under a timeout 60, then completed cleanly in ~20s on a subsequent attempt with no changes on our end – purely timing-dependent on that other job’s I/O pattern, not deterministic.

Fixed by: sudo kill -9 on the specific stuck pacman PIDs (found by checking /proc/<pid>/io for all-zero rchar/wchar after several minutes – a genuine hang shows literally zero I/O, not just “slow”). repo_build.sh’s per-arch loop treats the resulting failure like any other and moves on to the next arch automatically – no restart of the whole pipeline needed. Do not use pkill -P <backgrounded-PID> to target a stuck child buried inside a long chain of nohup’d processes – that backgrounded PID is the top of the entire oksh/makechrootpkg/pacman chain (this project’s background jobs are never truly detached from the launching shell), so -P only reaches its immediate child, not the actual stuck leaf process; find and kill the specific stuck PID directly instead (via ps//proc/<pid>/io).

Update 2026-09-25 (later, during gcc47’s own build): the exact same hang pattern recurred TWICE more, now on gcc47 itself, again only on i686 – once installing cloog+ppl together (6.5 hours stuck, not just 55 min), confirmed hung via the same zero-I/O check plus /proc/<pid>/stack showing futex_do_wait (blocked on an internal libalpm/curl condition variable, not visibly a DNS/connect issue – both mirror.archlinux32.org and our own repo host were directly reachable from the host at the time). This happened well after the earlier extra-staging-i686-build contention job had already finished, so that job was not the (sole) root cause – revise the earlier theory: this looks like a genuine, recurring flakiness specific to this host’s archlinuxaba-i686 (and archlinuxaba-pentium4) chroot’s package-installation path, not (only) shared-cache contention with unrelated jobs. Root cause still not nailed down – three occurrences now, all on 32-bit chroots, all zero I/O, all recovered cleanly by sudo kill -9 on the specific stuck pacman PIDs. If a 32-bit chroot install step exceeds ~5 minutes with a static log tail, check /proc/<pid>/io immediately – don’t wait an hour “just in case” like the first occurrence did.

Separately: after killing the stuck i686 build, this run’s repo_release.sh log went silent right after “proceeding to sign/publish the 3 arch(s) that did succeed” – no step 2/3 (sign/publish) output ever appeared, even though repo_build.sh itself always exit 0s in that situation (by design, see its own comment) and the build artifacts were correctly copied back to arch/adapted/cloog/ by repo_build_staged.sh. Cause not fully root-caused (something about the nohup’d background chain’s stdout/log stopped flushing further output, possibly connected to the same-session kill/pkill activity above disturbing the wrong process group) – worked around by manually running scripts/repo_sign.sh + scripts/repo_publish.sh directly against the already-built *.pkg.tar.* files sitting in the pkgdir, exactly mirroring what repo_release.sh would have done. If a repo_release.sh log ever goes silent after a partial-failure WARNING with no sign/publish following, check whether the pkg files already exist unsigned in the pkgdir before assuming the whole run needs a full retry – signing/publishing by hand from existing artifacts is faster and doesn’t risk re-triggering the same chroot contention.