notion3

Build times (auto-updated)

• armv7h: 5m36s (2026-09-11 05:48 UTC, remote)
• aarch64: 1m50s (2026-09-11 05:48 UTC, remote)
• x86_64: 9m41s (2026-09-11 05:22 UTC, serial)
• pentium4: 3m1s (2026-09-11 05:25 UTC, serial)
• i686: 3m43s (2026-09-11 05:29 UTC, serial)
• i486: 2m13s (2026-09-11 05:31 UTC, serial)
• armv6h: 17m6s (2026-09-11 05:48 UTC, remote)

---

• 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.

2026-09-10/11: filled in the rest of arch=(), then fixed the doc-build blocker properly

arch=() already listed all 7 archs, but only x86_64 had ever published. Built the other 6: armv7h succeeded outright; aarch64 failed once on transient archlinuxarm.org mirror flakiness (truncated downloads, DNS timeouts) and succeeded on a plain retry; pentium4/i686/i486 all failed identically on /usr/bin/ebb/extractbb exists in both 'texlive-bin' and 'texlive-basic'; armv6h failed differently, error: target not found: texlive-meta (not even present there). No pkgrel bump for any of this – purely additive new-arch builds, nothing already- published touched (see memory/PKGREL_VS_PKGVER.md’s “purely- additive arch=() edit” section, confirmed with the user the same session on a different package).

Root cause of the texlive failures, investigated on request: both texlive-bin (2026.0-2) and texlive-basic (2026.1-1) come from extra – upstream Arch32’s own repo, not archlinuxaba – and texlive-bin is a full point-version behind texlive-basic. Classic packaging-split lag: texlive-bin hasn’t been rebuilt to match texlive-basic’s newer file split yet, so both still ship the same two binaries. Not something this project can fix (upstream Arch32 package, not ours) or work around locally. armv6h’s texlive-meta absence is a related but separate symptom – that arch’s extra doesn’t carry the full texlive suite at all.

Fix: rubber/latex2html/texlive-meta are only needed for a separate notion-doc git source that builds the HTML manual – the actual window-manager build/install never touches them. Made doc building arch-conditional instead of an all-or-nothing removal (the user specifically asked for this, correctly – docs build fine on x86_64/armv7h/aarch64, no reason to drop them there):

• New _doc_archs=('x86_64' 'armv7h' 'aarch64') array.
• makedepends_x86_64/makedepends_armv7h/makedepends_aarch64 (Arch-suffixed arrays are additive to the base makedepends, per makepkg convention – not a replacement) carry the three doc-only deps instead of the base makedepends array.
• build()/package() wrap the notion-doc make invocations in if printf '%s ' "${_doc_archs[@]}" | grep -qx "$CARCH"; then ... fi. The notion-doc git source itself, and prepare()’s one-line Makefile sed fix, stay unconditional – both are cheap/harmless on every arch regardless of whether the doc actually gets built.
• pkgrel 6 -> 6.1 (private/ X.Y scheme, real content change, affects every arch’s actual package – rebuilt all 7 archs under the new pkgrel for consistency, not just the 4 previously- blocked ones).
• If Arch32 ever rebuilds a matching texlive-bin, revisit whether pentium4/i686/i486 can rejoin _doc_archs; armv6h needs Arch32 to actually carry texlive-meta for that arch first.