aurupdater

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.

mbedtls 4.x API break (pkgrel=1.2, 2026-08-28)

Triggered by a repo_diff_local_remote.sh check after the user reported pacman -Syu reporting installing protobuf (36.0-1) breaks dependency 'libprotobuf.so=35.1.0-64' required by fluxengine-git – this package’s published build was linked against an older protobuf and needed a plain rebuild against current protobuf. Bumped pkgrel 1.1 -> 1.2 for that (rebuild-only, no PKGBUILD logic change beyond the version bump).

That rebuild then hit a second, unrelated failure: dep/r/imhex/lib/libimhex/source/helpers/crypto.cpp:11:10: fatal error: mbedtls/bignum.h: No such file or directory. Root cause: Arch’s mbedtls package jumped to 4.2.0, which restructured its API (PSA-first) and moved/removed the old public headers (bignum.h now lives only at mbedtls/private/bignum.h, not meant for external use). The vendored ImHex fork’s crypto.cpp (see the fmt-12 fix above for how it gets vendored) uses the old pre-4.0 API throughout (mbedtls_mpi, mbedtls_md5/sha1/sha256/sha512_*_ret, mbedtls_cipher_*) – a straight header-path patch wouldn’t be enough, the whole ABI is different in 4.x.

Confirmed fluxengine’s own build system (src/gui2/build.py) resolves mbedtls purely via pkg-config --cflags/--libs mbedtls (build/pkg.py’s package() rule) – no hardcoded include/lib paths. Arch ships exactly the right compat package for this: mbedtls3 (3.6.7-1, in extra), a full standalone build of the old API with its own headers (/usr/include/mbedtls3/mbedtls/...), libs (/usr/lib/mbedtls3/libmbed{tls,crypto,x509}.so*), and a matching mbedtls.pc (package name mbedtls) at /usr/lib/mbedtls3/pkgconfig/. Fix: swapped depends/makedepends mbedtls -> mbedtls3, and exported PKG_CONFIG_PATH="/usr/lib/mbedtls3/pkgconfig:${PKG_CONFIG_PATH:-}" in both build() and check() so pkg-config resolves the compat package ahead of the system one. Confirmed via grep that mbedtls is used only by the gui2 (ImHex-based fluxengine-gui) build target, nowhere else in fluxengine’s own code – safe to swap outright rather than needing both packages installed side by side.

Kept pkgrel at 1.2 (folded into the same rebuild that hadn’t succeeded yet, same reasoning as [[pacman-static]]’s pkgrel-17 multi-fix entry – not a second bump).

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.

Upstream switched build systems entirely (found 2026-09-08, NOT fixed)

Attempted a routine rebuild-only pkgrel bump (1.2 -> 1.3) to pick up a new protobuf soname (libprotobuf.so=36.0.0-64 -> 36.1-1 broke the installed package). Build failed immediately in build():

make: *** No rule to make target 'binaries'.  Stop.

Root cause: upstream (davidgiven/fluxengine) has completely replaced its old build system (Python/build/ab.mk/ninja, make binaries / make tests) with Bazel (.bazelversion pins 9.2.0) plus a Java frontend – BUILD.bazel now aliases the fluxengine binary target to //java/com/cowlark/fluxengine, and deps are pulled via MODULE.bazel/bzlmod. The repo’s own top-level Makefile is now just a thin wrapper: bazel test //... //:fluxengine.

This is 342 commits ahead of the last commit we successfully packaged (909fac72, current tip at the time of this check was acaae8f5, pkgver r3631). The migration is a genuine rewrite, not a renamed target – old prepare()/build()/check() (ImHex vendoring patch, mbedtls3 PKG_CONFIG_PATH swap, make binaries/make tests) no longer apply at all. Packaging this properly would mean: adding bazel+JDK to makedepends, reworking build()/check()/package() around Bazel’s output tree, and dealing with Bazel’s own network fetching during the build (bzlmod pulls deps at build time, which doesn’t fit the sandboxed/no-network expectation of a normal makepkg/archbuild build()). Whether the old ImHex-fmt12 and mbedtls3 vendoring issues even still apply under the new Java/Bazel build is unknown – not investigated, since this needs a scoping decision first.

Left unresolved deliberately – this is well beyond the “rebuild for a soname bump” ask that triggered it (see [[feedback_ask_before_nonroutine_pkgbuild_changes]] in the cross-session memory). pkgrel was bumped to 1.3 in the PKGBUILD during the attempt, then reverted back to 1.2 (matches what’s actually published, build never succeeded) after asking the user how to proceed – decision was “leave it broken for now”, no further action taken this session. fluxengine-git remains uninstallable against current protobuf on the repo (libprotobuf.so=36.0.0-64 vs installed 36.1-1) until one of the options above is picked in a future session: pin the AUR package to the last pre-Bazel commit (125c554a), attempt the Bazel/Java rewrite, or drop the package.

Re-confirmed still broken, 2026-10-05

Hit again during a full -git batch build/publish pass (same “No rule to make target ‘binaries’” failure, Bazel migration still unresolved upstream). No new action taken – same deliberate “leave it broken” decision from 2026-09-08 still stands.

Build notes