Reusing the linux job's binary (previous commit) doesn't work: it's
dynamically linked against ~100 libraries at absolute /nix/store
paths, including its own ELF interpreter, none of which exist inside
the Flatpak sandbox - confirmed locally via a real install+run
(execvp: No such file or directory). Reverted to building from source
inside flatpak-builder's sandbox via the rust-stable SDK extension,
same as the existing local `devbox run package` already does.
Also fixes two things needed for that in-sandbox build to work under
the forgejo-runner service (not an interactive session):
- appstreamcli (used by flatpak-builder to compose AppStream metadata)
wasn't on PATH - added as a devbox package (linux-only, like
gtk4/libadwaita) rather than a NixOS system package, keeping it
scoped to the project.
- rofiles-fuse's mount/unmount cycle fails under the service context
even though /dev/fuse itself is world-writable; --disable-rofiles-fuse
is flatpak-builder's own documented workaround for this.
Verified locally: full build, appstreamcli compose, bundle install,
and the installed binary actually executing inside the sandbox.
rofiles-fuse's mount/unmount cycle fails under the forgejo-runner
systemd service ("Permission denied" / "Operation not permitted" on
fusermount3) even though /dev/fuse itself is world-writable - services
don't get the same mount-namespace treatment an interactive session
does. --disable-rofiles-fuse is flatpak-builder's own documented
workaround for exactly this class of environment (containers/CI).
Missing --user (present on the existing package script, omitted here
by mistake) made flatpak-builder try to install missing deps
system-wide, which this unprivileged CI user can't authorize via
polkit: "Flatpak system operation GetRevokefsFd not allowed for user".
Builds carrier-x86_64.flatpak from the linux job's already-built binary
rather than recompiling inside flatpak-builder's sandbox (which can't
see the shared cargo cache anyway, making an in-sandbox build pure
duplicate work). com.randogoth.carrier.release.json is a separate
manifest from the main one, which stays as-is for local
`devbox run package` dev-from-source builds.
Linux now gets gtk4/libadwaita declared as nix devbox packages (scoped
to linux platforms, with the dev output requested explicitly - nixpkgs
splits runtime libs from headers/pkgconfig, and devbox only installs
the default output unless told otherwise). macOS keeps using Homebrew's
build exactly as before (nixpkgs' GTK build is much rockier there).
PKG_CONFIG_PATH moved out of the static env block (which can't be
platform-conditional) into init_hook, which can branch on uname.
Verified building clean with 0 warnings on both this machine (Linux)
and apfel (macOS).
On Apple Silicon Macs, many GTK-related nixpkgs packages are marked as
unsupported on aarch64-darwin. Instead of using nixpkgs for the GUI stack,
use Homebrew which provides pre-built bottles for gtk4, libadwaita, and
all their dependencies (glib, pango, cairo, gdk-pixbuf, graphene, etc.).
The devbox config now provides only the Rust toolchain (rustc, cargo,
pkg-config, rustfmt) and sets environment variables to locate the
Homebrew-installed libraries:
- PKG_CONFIG_PATH: /opt/homebrew/lib/pkgconfig
- PKG_CONFIG_PATH_arm64_apple_darwin: /opt/homebrew/lib/pkgconfig
- PATH: Includes /opt/homebrew/bin and /opt/homebrew/sbin
This allows building the project with: devbox run build
All 16 tests pass with: devbox run check
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
