openssl-1.1

• Path: arch/adapted/openssl-1.1
• Build failure during the 2026-07-07 “build all packages for x86_64” private-repo release pass (see repo_release_logs/adapted_openssl-1.1.log).
• Source retrieval and a very large stack of custom CVE/security patches all applied cleanly (dozens of hunks across crypto/cms, crypto/pkcs12, crypto/x509, test/ etc. – this PKGBUILD carries many backported fixes on top of the base openssl-1.1 release). The actual failure is at ./Configure: optflags='enable-ktls enable-ec_nistp_64_gcc_128' (PKGBUILD line 215) is passed into Configure --prefix=/usr ... (line 243), and Configure rejects it outright: ***** Unsupported options: enable-ktls.
• Root-caused and fixed 2026-08-17. enable-ktls is not, and never was, a real Configure option for vanilla OpenSSL 1.1.1w: grep -n ktls Configure Configurations/10-main.conf against the pristine extracted source tarball (and this project’s own CVE/security patch stack, none of which touch Configure/Configurations/) returns zero hits. So optflags='enable-ktls enable-ec_nistp_64_gcc_128' on the x86_64 arm of the case ${CARCH} in build() was simply wrong from the start – enable-ec_nistp_64_gcc_128 is real (appears in Configure’s disablables table), enable-ktls never was. Fix: drop enable-ktls, keep enable-ec_nistp_64_gcc_128. Bumped pkgrel 11 -> 11.1 (arch=() extended to add i686/pentium4, which don’t hit this x86_64-only code path and built fine first try) -> 11.2 (the ktls fix itself, a second successive local deviation).
• This bug had been dormant since the 2026-07-07 report: the previously published x86_64 package was never rebuilt in the interim (nothing changed its pkgrel), so OVERVIEW.md’s “SAME” status was just comparing local pkgrel to the remote package, not evidence of a recent successful build. The 2026-08-17 arch-extension task (adding i686/pentium4) was the first thing to actually trigger an x86_64 rebuild since, which is what surfaced the bug again. Lesson: a “SAME” published-status package can still be silently broken if nothing has forced a rebuild in a while — don’t assume “SAME” means “still builds.”
• Now builds cleanly for aarch64 (skipped here, no local build cmd), x86_64, armv7h (skipped here, no local build cmd), i686, and pentium4. i686/pentium4 are at pkgrel=11.1, x86_64 at 11.2 (a cross-arch pkgrel mismatch within the same pkgbase is harmless – pacman resolves each arch’s package version independently).

2026-09-28: armv7h + aarch64 published for the first time

First real remote-ARM build attempt for this package (11.2, once the ARM cluster came back up) – both repo_build.sh legs reported FAILED, but that verdict was wrong: this PKGBUILD’s pkgver=${_ver/[a-z]/.${_ver//[0-9.]/}} line broke remote_build.sh’s naive sed-based pkgver extraction (used only to name the live build-log file), which fed a literal unexpanded ${_ver/[a-z]/...} string (slashes and all) into the log’s tee target path. tee couldn’t open that path and failed; set -o pipefail (intentionally there to catch real makepkg failures) propagated that as the whole remote script’s exit status, even though makepkg itself – including check(), since there’s no options=(!check) here – had already completed and produced valid .pkg.tar.xz files on both eurobuild5 (armv7h) and eurobuild14 (aarch64). Root cause fixed in arch/scripts/remote_build.sh (see that script’s own header comment) by switching pkgver/pkgrel extraction to makepkg --printsrcinfo, matching how _pkgname was already done.

Verified the two already-built artifacts directly (tar tJf listing + .PKGINFO pkgver/arch check) before trusting them, rather than re-running the ~70-minute armv7h build (its own make test is what made this take so long on that board) – both were genuine complete builds, just mis-reported. Signed + published both by hand (repo_sign.sh + repo_publish.sh directly, skipping repo_build_staged.sh since the artifacts already existed) – confirmed live on the remote repo afterward. No PKGBUILD change needed; this was purely a build-tooling bug.