aurupdater

cyrus-imapd2

Build times (auto-updated)

2026-10-19: content-free rebuild for perl 5.44 ABI bump, x86_64 only, pkgrel 2.5 -> 2.6

User found via pacman -Qqo '/usr/lib/perl5/5.42' that this package (and perl-crypt-ssleay) owned files under the old perl-versioned path on this host. Real current perl is actually 5.44.0-1 (the archbuild chroot already syncs to it; the host’s own pacman -Si was just reporting a stale cached sync db until a plain pacman -Sy). Content-free rebuild, no PKGBUILD edit beyond the adapted/ X.Y pkgrel bump (per the established rule: content-free rebuilds always get X.Y, not a plain integer, even where the current rebuild has no actual content change). x86_64 only, per explicit request – i686/pentium4/armv6h/armv7h untouched, still at 2.5.17-2.5.

Publish raced with a concurrently-running perl-crypt-ssleay rebuild: launched both repo_release.sh calls at once (different packages, thought independent), but repo_publish.sh’s repo-add step takes a lockfile on the shared remote archlinuxaba.db.tar.gz for a given arch – both hit x86_64’s db at the same time, one lost the race (ERROR: Failed to acquire lockfile ... Held by process <pid>). Build+sign+ upload still succeeded for the losing side, just the db-add step failed, so the package sat uploaded but not actually in the repo index (repo_arch_status.sh showed not published despite the file existing remotely). Fixed by rerunning scripts/repo_publish.sh directly on the already-signed local .pkg.tar.zst/.sig files once the other publish finished – no rebuild needed. Lesson: don’t run two repo_release.sh invocations concurrently even for unrelated packages if they might publish to the same arch’s db around the same time – serialize them, or accept needing this exact recovery step.

While investigating, found this is NOT the only package in this project’s own tree with perl XS bindings needing the same treatment – maintained/obexftp also ships a compiled OBEXFTP.so under vendor_perl/auto (built via its -DENABLE_PERL=YES SWIG bindings). Found by enumerating every locally-installed package owning a .so under /usr/lib/perl5/5.42/vendor_perl/*/auto/ and cross-checking against arch/{maintained,adapted,private,owned} – everything else in that list (graphicsmagick, imagemagick, net-snmp, the various official perl-* XS packages, rrdtool, subversion, xmms2, etc.) comes straight from upstream Arch repos, not tracked here, so Arch’s own perl-rebuild cycle covers those.

2026-10-20: ARM catch-up to 2.5.17-2.6 (“the cluster is up”)

Once the remote build boards were confirmed back online, ran the armv6h/armv7h rebuild that was deliberately deferred above: REPO_BUILD_ONLY_ARCH="armv6h armv7h" repo_release.sh adapted/cyrus-imapd2. Built and published cleanly on both (armv6h 40m29s, armv7h 15m24s). Note: the eurobuild5 board’s perl is still 5.42 (its perl bindings installed under /usr/lib/perl5/5.42/site_perl/...), not 5.44 like the local x86_64 chroot – each remote board syncs its own packages independently, so ARM and local-arch perl versions can legitimately differ; not a bug. i686/pentium4 remain at 2.5.17-2.5, untouched – outside this round’s scope (x86_64 + ARM only).

Build times (auto-updated)

2026-08-20: renamed pkgname to match the real AUR package; fixed a real 32-bit-only pointer-type bug

Requested alongside private/optdb5.3 – pure rebuild-for-coverage, no PKGBUILD content change. armv6h/armv7h were skipped in the 2026-08-20 build above for lack of a local chroot; now covered by the eurobuild4/eurobuild5 remote-build boards. pkgrel 2.3 -> 2.4 (the existing adapted/ X.Y rule, unconditional regardless of content-change status – see memory/PKGREL_VS_PKGVER.md).

Board collision with private/optdb5.3’s own armv7h build, same session: both packages requested together, and repo_build.sh launches all of a package’s remote archs concurrently with each other (by design, they’re independent boards) – but optdb5.3 and cyrus-imapd2 both need armv7h, i.e. the same board (eurobuild5). optdb5.3’s armv7h job had a ~2min head start when cyrus-imapd2’s own armv7h job launched on the same board (eurobuild5 is single-core/low-RAM, per remote_build.conf’s own comment – running two builds on it at once was a real risk, not just theoretical). Killed cyrus-imapd2’s armv7h remote job (the repo_build_remote.sh/ssh process pair, confirmed no orphaned process left on the board afterward) while leaving optdb5.3’s alone (further along) and cyrus-imapd2’s own armv6h (a different board, eurobuild4) untouched. repo_build.sh handled the killed job gracefully – reported armv7h FAILED, still signed/published the 3 archs that did succeed (i686/x86_64/armv6h). Retried armv7h alone afterward via REPO_BUILD_ONLY_ARCH=armv7h ./scripts/repo_release.sh adapted/cyrus-imapd2 once eurobuild5 was confirmed free – built and published cleanly. Takeaway for next time: check arch=() overlap across all remote-mapped archs, not just whether two packages are literally the same package, before launching multiple repo_release.sh runs concurrently – the collision is per-board, not per-package.

New finding, unrelated to the rebuild itself: namcap flagged a real missing runtime dependency during this build – cyrus-imapd2 E: Dependency jansson detected and not included (libraries ['usr/lib/libjansson.so.4'] needed in files ['usr/lib/libcyrus_imap.so.0.0.0']). Pre-existing (not introduced by this rebuild, depends=() wasn’t touched), not fixed this round – next real edit to this PKGBUILD should add jansson to depends=().

2026-09-10 (same day): fixed the jansson dependency, pkgrel 2.4 -> 2.5

Added jansson to depends=() (real content change, plain adapted/ X.Y bump). Cleaned a stale leftover armv7h build artifact in /data/INSTALL/cyrus-imapd2 first (left over from the earlier armv7h-only retry’s fetch step, not cleaned up automatically) – per the “check stale artifacts before build” convention, since repo-add is last-write-wins by pkgname and a stale file could have silently clobbered this publish. Confirmed both remote boards (eurobuild4/eurobuild5) free before launching this time, no collision. Rebuilt and published cleanly on all 4 wished archs (i686/x86_64/armv6h/armv7h); namcap’s missing-jansson warning is gone from this build’s log. armv6h took notably longer this time (38m55s vs the previous run) – board load variance, not a regression to chase.

2026-09-10 (later same day): added pentium4, no pkgrel bump needed

User asked why pentium4 was missing – answer: it was simply never in arch=() at all (inherited unevaluated from the original AUR PKGBUILD), not a build failure. Added it. Initially bumped pkgrel 2.5 -> 2.6 out of habit (the adapted/ X.Y rule) – user caught it: “Are you sure we have to bump pkgrel here… Because we are just adding new subarchs.” Correct: a purely-additive arch=() edit (new arch only, no already-published arch touched) needs no bump at all – there’s no existing publish for that arch to version-skew against. Reverted to 2.5, built pentium4 alone (REPO_BUILD_ONLY_ARCH=pentium4). Built and published cleanly in 3m24s, no arch-specific fixes needed – confirms the earlier hunch that the narrow i686 size_t fix would carry over fine. Full writeup of the general rule in memory/PKGREL_VS_PKGVER.md’s “A purely-additive arch=() edit needs no pkgrel bump at all” section.