notion3

• Path: arch/private/notion3
• 2026-07-25: pkgrel 5 -> 6, notion3-ioncore-winprops-lua55-hole-border.patch added (ioncore/ioncore_winprops.lua). ifnil()’s helper used #arg to count its varargs, but #’s result on a table with holes (e.g. a nil first argument – the common case for id.role/id.instance) is unspecified by the language and silently changed between Lua 5.4 and 5.5, collapsing the loop bound to 0. Fixed with select('#', ...), which is well-defined regardless of holes. Test build (x86_64) succeeded, all three patches (libtu C99, mkman Lua 5.4, this one) applied cleanly; same pre-existing namcap warnings as before (stale cfg_bindings.lua backup entry, LGPL2 SPDX naming, unrelated missing-dependency notes).
• 2026-07-25: rebuilt/republished on request, no PKGBUILD changes needed – still pkgrel 5, x86_64 builds clean. i486 still fails the same pre-existing way (texlive-bin vs texlive-basic/dvisvgm/ texlive-context file collisions) – confirmed still unrelated to this package, just the i486 chroot’s texlive-family situation.
• 2026-07-15: build failure fixed and published (x86_64), pkgrel 4 -> 5. Previously flagged alongside optdb5.3 as “incompatible function-pointer types – modern GCC strictness vs old C code”. Two independent bugs surfaced in sequence, both real, pre-existing defects (not just GCC-version friction):
  1. Genuine upstream typo: libtu/Makefile sets CFLAGS += $(C98_SOURCE) ..., but every other module’s Makefile in the tree correctly uses $(C99_SOURCE) – C98_SOURCE is never defined anywhere, so it silently expanded to nothing and libtu (which includes obj.c) has always built without -std=c99. Old GCC’s default standard happened to still tolerate calling through libtu’s unprototyped function-pointer tables (e.g. destroy_fn in obj.c) with arguments; GCC’s new default standard (gnu23) correctly rejects it as a real too-many-arguments error.
  2. Once past that, build/mkman.lua (run at build time via the system lua, now 5.5.0) failed: attempt to assign to const variable 'l' – the script reassigns a generic-for loop control variable, which newer Lua now rejects.
• Fix: two new patches applied via prepare() – notion-libtu-c99.patch (fixes the C98_SOURCE->C99_SOURCE typo) and notion-mkman-lua54.patch (uses a separate local ln instead of reassigning the loop variable l). Both patches’ checksums are real sha256sums; the two git+ sources stayed SKIP (already pinned by commit) – updpkgsums tries to hash git sources too, revert those two back to SKIP if re-running it.
• The full multi-arch repo_release.sh run hit an unrelated, pre-existing i486 chroot conflict (texlive-bin vs texlive-basic/dvisvgm/texlive-context file collisions, nothing to do with this fix) which – under the old repo_build.sh logic – aborted the whole release before signing/publishing the x86_64 build that had already succeeded. Worked around manually that once; properly fixed in scripts/repo_build.sh itself afterward (see UPDATES.md’s 2026-07-15 “optdb5.3 and notion3: published” entry – a failing arch no longer blocks signing/publishing the archs that did succeed).
• One unrelated, pre-existing makepkg warning noted but left alone: backup=() lists etc/notion/cfg_bindings.lua, a file that doesn’t exist anywhere in the upstream source tree – a stale entry, not a build failure.