fluxengine-git
pkgrel scheme correction, 2026-07-18
This package is under arch/adapted/, so local-only fixes must use
pkgrel=X.Y sub-numbering (see memory/PKGREL_VS_PKGVER.md), not a
plain integer bump. The fmt-12 fix below was first published as plain
pkgrel=2 (upstream AUR’s own pkgrel was 1) — wrong, and already
built/published before being caught. Corrected to pkgrel=1.1 and
republished same day. If upstream’s own AUR PKGBUILD ever bumps past
pkgrel=1 again, resume local fixes from 1.1, not from 2.
fmt 12 build failure (fixed pkgrel=1.1, 2026-07-18)
Build failed compiling a vendored ImHex GUI plugin
(hex_editor.cpp -> hex/api/localization_manager.hpp) with:
error: no matching function for call to 'format(fmt::v12::runtime_format_string<>, ...)'
• there is 1 candidate
• candidate 1: 'template<class ... Args> auto fmt::format(const hex::Lang&, Args&& ...)'
Root cause: fluxengine’s own build system (build/ab.mk, custom
git_repository() rule in dep/build.py) fetches an unpinned
fork, davidgiven/ImHex branch master, into dep/r/imhex at build
time – not a normal git submodule, not part of fluxengine’s own
pinned commit. That fork’s localization_manager.hpp reopens
namespace fmt with its own fmt::format(const hex::Lang&, Args&&...)
overload and, inside it, calls fmt::format(fmt::runtime(...), ...).
The file only #include <fmt/core.h>, and fmt’s own
runtime_format_string overload of fmt::format isn’t declared by
that header (only in <fmt/format.h>). Because the call is a
qualified name (fmt::format(...)), two-phase lookup only
considers overloads already declared at the point of this template’s
definition – so with only core.h included, the compiler sees
only the custom hex::Lang overload and fails. This only started
breaking with fmt 12.2.0 (Arch’s current fmt package as of
2026-07-18); confirmed with a minimal repro (fmt::format core.h
vs format.h) before touching the PKGBUILD.
Fix (PKGBUILD prepare()): pre-clone dep/r/imhex ourselves before
make binaries ever runs, and sed the one #include <fmt/core.h>
to #include <fmt/format.h> in
dep/r/imhex/lib/libimhex/include/hex/api/localization_manager.hpp.
The build system’s own git_repository ninja rule for that path only
clones if dep/r/imhex/.git/config is missing, so pre-seeding it
makes ninja treat the fetch as already satisfied and leaves the patch
in place. Confirmed working: two full test builds (before/after the
patch) plus a real archbuild release build all matched this
behavior.
Since dep/r/imhex tracks davidgiven/ImHex’s master with no
pin, this exact failure could recur (or a different one could
appear) any time that fork’s master moves or Arch’s fmt gets a
further ABI/API change. If a future build fails again in
localization_manager.hpp or another vendored ImHex file with a
similar “custom overload shadowing the real one” pattern, check
whether the same #include <fmt/core.h> -> <fmt/format.h> fix
still applies, or whether the file/line has moved upstream.
Other namcap fix
boost-libs was missing from depends (binary links
libboost_regex.so, namcap flagged it as an E: error) – added
in the same pkgrel=2 bump.
Build notes
arch=(x86_64), no unpinned toolchain surprises otherwise.- Full clean build takes a while (~1000+ ninja targets); most of it
is compiling the vendored ImHex GUI (
gui2) plugin tree. make tests(check()) is fast/no-op aftermake binariesalready built everything – ninja just reports “no work to do”.- Lots of namcap
W: Unused shared librarywarnings forlibabsl_*(abseil, pulled in transitively via protobuf/wxwidgets) – these are noise, not worth chasing; only theboost-libsE:was real.