webkit2gtk

Current: pkgver=2.50.6, pkgrel=8. Published, matches upstream (nvchecker OK).

2026-07-23: build-failure comment (horsemanoffaith)

AUR comment reported a CMake configure failure:

-- Found Unifdef: /usr/bin/unifdef
CMake Error at Source/cmake/WebKitMacros.cmake:311 (if):
  if given arguments:
    "(" "NOT" "_linked_into" ")" "OR" "(" "WTF" "STREQUAL" ")" "OR" "(" "NOT" "IN_LIST" "LLIntSettingsExtractor_FRAMEWORKS" ")"
  Unknown arguments specified
Call Stack (most recent call first):
  Source/cmake/WebKitMacros.cmake:393 (_WEBKIT_TARGET_LINK_FRAMEWORK)
  Source/JavaScriptCore/CMakeLists.txt:409 (WEBKIT_EXECUTABLE)

Our own build of this exact pkgver/pkgrel succeeds in the local extra-x86-build chroot (published, OVERVIEW.md shows SAME). The malformed if() argument list (empty/unquoted variable expansions, e.g. WTF STREQUAL with nothing after STREQUAL) looks like classic cmake-version-dependent if() policy behavior – likely the reporter has a much newer cmake than what’s in our chroot, and a newer policy default changes how an empty/unquoted variable inside if(... OR ...) is parsed. Not reproduced locally, so not treated as a packaging bug yet.

Next time this comes up: ask what cmake version the reporter has, and check whether cmake_minimum_required/cmake_policy pins in WebKit’s own build system need a corresponding bump in our makedepends=(cmake ...) version constraint (or a cmake_policy(SET CMP... OLD) workaround) if newer cmake becomes the norm here too.

2026-07-24: fixed the WebKitMacros.cmake / cmake>=4 configure failure

Root cause found and fixed. extra/cmake in our chroot (and in official Arch extra) moved to 4.4.0 on 2026-07-21, which is what made this reproduce locally for the first time – it wasn’t reporter-specific after all.

The bug is in upstream WebKit’s Source/cmake/WebKitMacros.cmake, macro _WEBKIT_TARGET_LINK_FRAMEWORK:

if ((NOT _linked_into) OR (${framework} STREQUAL ${_linked_into}) OR (NOT ${_linked_into} IN_LIST ${_target}_FRAMEWORKS))

${_linked_into} (the <framework>_LINKED_INTO GLOBAL PROPERTY) is genuinely empty the first time this runs: LLIntSettingsExtractor (a bootstrap executable JavaScriptCore builds to generate offlineasm headers) links WTF before JavaScriptCore’s own WEBKIT_FRAMEWORK(JavaScriptCore) call ever sets WTF’s _LINKED_INTO property – a real ordering/bootstrap situation, not a one-off. An unquoted empty variable inside if() vanishes as a token instead of becoming an empty-string argument, so this produces a malformed argument list ("WTF" "STREQUAL" with nothing after, "NOT" "IN_LIST" "..." with nothing before). Something changed in cmake 4.x’s if() argument validation and it started rejecting that malformed list outright (“Unknown arguments specified”) instead of tolerating it. Checked WebKit upstream main on GitHub: still unquoted as of 2026-07-24, so no upstream fix to pull in yet. Checked official Arch webkit2gtk-4.1 PKGBUILD too: no patch there either – it just hasn’t been rebuilt since cmake 4.4.0 landed (last build 2026-07-14), so this is likely a brewing problem for them too, not something already solved elsewhere.

Fix: quote both variables so the comparisons stay well-formed when empty – ("${framework}" STREQUAL "${_linked_into}") and (NOT "${_linked_into}" IN_LIST ${_target}_FRAMEWORKS). Shipped as a standalone patch file cmake4-linked-into-quoting.patch (source= entry, applied via patch -Np1 in prepare(), not inline sed – see the project’s cross-session memory on why: patch files are portable to other distros packaging the same upstream source). Bumped pkgrel only (packaging fix, not a pkgver change). Verified: cmake -S ... -B build now completes past JavaScriptCore/LLIntSettingsExtractor and produces build.ninja, full build finished cleanly (webkit2gtk, webkit2gtk-debug, webkit2gtk-docs all built, namcap only flagged pre-existing license/dependency lint issues, unrelated).

If this resurfaces in a future pkgver bump: reapply/regenerate the patch against the new source tree first (diff -Naur between vanilla and patched, verify with patch -Np1 --dry-run) – don’t assume it still applies cleanly.

Stale “cmake4-linked-into-quoting.patch not applied” reports – recurring

Four separate commenters (skaileen/terwarf 2026-07-24 15:22, RyLoS 2026-07-27, henna.eject comment 1085192 2026-09-13 07:35 UTC / 09:35 CEST) have each reported the same WebKitMacros.cmake:311 cmake>=4 configure error the patch already fixes (landed f20b046, 2026-07-24). Each time: prepare() still has the patch -Np1 -i "$srcdir/cmake4-linked-into-quoting.patch" call, HEAD still at/past the fix, working tree clean – stale AUR-helper cache or an old local checkout on their end, not a regression. No PKGBUILD change, no reply, any time. If a fifth one shows up, it’s worth actually asking the reporter for their exact PKGBUILD/.SRCINFO rather than assuming stale cache again.

PGP “unknown public key 91C559DBE4C9123B” – recurring, never ours to fix

Reported twice (kde_fcitx5, 2026-08-23/25; re-checked 2026-09-13, same comment, no new one). Key 5AA3BC334FD7E3369E7C77B291C559DBE4C9123B (Adrián Pérez de Castro) is, both times, already correctly in validpgpkeys, already vendored in keys/pgp/, and already in this host’s keyring – not expired/revoked (expires 2027-03-16). Always the reporter’s own keyring/keyserver gap (same shape as python2’s and thunderbird-esr-bin’s cases), never ours. No PKGBUILD change, no reply, either time.