cyrus-imapd2

• Path: arch/adapted/cyrus-imapd2

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

• This directory is descended from a plain “cyrus-imapd” AUR PKGBUILD (maintainer Carsten Feuls), but the directory itself is named/intended to be the separate, actual AUR cyrus-imapd2 package – the internal pkgname= had never been updated to match, the same class of directory/pkgname mismatch hit earlier this session with trojita-git. Fixed the same way: kept a _pkgname=cyrus-imapd var for the real upstream source references (tarball URL, $srcdir subdirectory, cd targets), set pkgname=cyrus-imapd2 for everything package-identity-related (install=, licenses/doc install dirs). Renamed cyrus-imapd.install -> cyrus-imapd2.install to match. Added provides/conflicts/replaces=('cyrus-imapd') (on top of the pre-existing imap-server/pop3-server) so it properly supersedes a plain cyrus-imapd install, matching the real AUR cyrus-imapd2’s own semantics. pkgrel 2.1 -> 2.2 for the rename.
• User had a reference copy at /data/INSTALL/cyrus-imapd-2-from-eurobuild3 with two useful patches this directory already had integrated (cyrus-imapd-2.5.17-perl-5.36-assert.patch, cyrus-imapd-2.5.17-mib-missing-semicocon-util-funcs.patch) – confirmed identical content, no changes needed there. Both patches are small local fixes (not fetched from an obscure/one-off source), so no src/ mirror upload needed for them.
• CC=gcc CFLAGS='-fPIC -std=gnu17' (was CC=clang, undeclared makedepend) – root cause: imap/mboxlist.h declares callback params as old K&R-style unprototyped function pointers, which clang tolerated but GCC’s current default standard (gnu23) now rejects as a hard incompatible-pointer-types error. -std=gnu17 restores the looser semantics this code was written for.
• New 32-bit-only bug found this build (i686 failed even with the gnu17 fix applied, x86_64 succeeded): imap/mboxevent.c:831 declared unsigned long len = 0; but lib/map.h’s map_refresh()/ map_free() prototypes take size_t *len. On x86_64, size_t and unsigned long are the identical 8-byte type, so this was silently fine. On i686, size_t is unsigned int – a genuinely distinct type from unsigned long despite matching 4-byte width – so GCC’s -Wincompatible-pointer-types (a hard error by default in current GCC) rejected it. This is a real, narrow, pre-existing upstream bug (latent on 64-bit, only surfaces as a build error on 32-bit); fixed with a new patch, cyrus-imapd-2.5.17-mboxevent-size_t-pointer-mismatch.patch (unsigned long len -> size_t len, one-line change). pkgrel 2.2 -> 2.3.
• Result: builds and publishes cleanly on x86_64 and i686. armv6h/armv7h are declared in arch=() but skipped both times (SKIPPED armv6h/armv7h (no local extra-*-build)) – no local archbuild chroot for those arches on this workstation, not a package problem. pentium4 was never in arch=() to begin with (inherited from the original AUR package, not evaluated this round – would be worth trying given how narrow the i686 fix was, if picked up again).
• sed -i'' 's/gettid/_gettid/g' lib/cyrusdb_berkeley.c inline fix in build() still not converted to a proper patch file (per the project’s “patch files, not inline edits” convention) – left as-is, not addressed this round.
• Lesson: a K&R-implicit-declaration fix (-std=gnu17) and a strict-pointer-type-mismatch fix (size_t vs unsigned long) look similar (both show up as -Wincompatible-pointer-types errors, both only bite on GCC’s stricter modern defaults) but are different root causes needing different fixes – worth checking whether an i686-only build failure surviving an existing K&R fix is actually a second, arch-width-dependent type mismatch rather than the same bug recurring.