Build the Flatpak with crafter-build's Flatpak output instead of the CrafterBuild base app #7

New issue

Open

opened 2026-11-02 19:07:58 +00:00 by jorijnvdgraaf · 0 comments

jorijnvdgraaf commented

2026-11-02 19:07:58 +00:00

Owner

crafter-build 6.1.0 (on its way to stable) can package an executable as a Flatpak itself. Crafter.Review's manifest could then drop the CrafterBuild base app and prune-base.sh: the program, the three LLVM libraries it links and its data come out of crafter-build ready to install, and flatpak-builder only adds node and ripgrep.

Blocked on crafter-build 6.1.0 being on stable. That release brings the Flatpak output, the bundle and install verbs, and the --talk-name=org.freedesktop.Flatpak permission those verbs need.

Today

The manifest uses net.catcrafts.CrafterBuild//stable as its base, so flatpak-builder's build sandbox has crafter-build. Then prune-base.sh deletes everything of the base except the libc++, libc++abi and libunwind the binary links through its /app/lib run path. The finish-args, app-id and metainfo live in the YAML.

With crafter-build's Flatpak output

project.cpp describes the app, on the crafter.review-exe configuration:

cfg.packaging = Packaging::Flatpak;
cfg.flatpak.appId = "net.catcrafts.CrafterReview";
cfg.flatpak.runtime = FlatpakRuntime::Sdk;   // the lenses' Bash tool needs git, python3, curl, jq
cfg.flatpak.permissions = { "--share=network", "--filesystem=host", "--filesystem=/tmp",
                            "--filesystem=xdg-run/gnupg/S.keyboxd", "--env=PATH=/app/bin:/usr/bin" };
cfg.flatpak.metainfo = "packaging/flatpak/net.catcrafts.CrafterReview.metainfo.xml";
cfg.flatpak.share = {
    { "process", "crafter-review/process" },
    { "LICENSE", "licenses/net.catcrafts.CrafterReview/LICENSE" },
};
cfg.flatpak.modules = { "packaging/flatpak/ripgrep.yaml", "packaging/flatpak/node.yaml" };

What the build writes. bin/crafter.review-exe-<variant>/ becomes a finished Flatpak build directory: metadata, export/, and files/ holding bin/crafter-review, lib/ with the three LLVM libraries, and share/.
process/ under -r. <exe>/../share/crafter-review (Crafter.Review-Core.cppm:33) finds files/share/crafter-review under -r as well, since -r runs the program from files/bin.
The two modules are the ripgrep and node modules of today's manifest, moved into module files of their own. crafter-build lists them in a manifest it generates, build/flatpak-apps/net.catcrafts.CrafterReview/net.catcrafts.CrafterReview.json, ending with a module that copies files/ into /app. So the program is not compiled again in flatpak-builder.
Stripping and .Debug. With modules set, flatpak-builder still strips the binary and splits out the .Debug extension.
-march. As today, set CRAFTER_BUILD_MARCH=x86-64-v2 and CRAFTER_BUILD_MTUNE=generic when building for release, along with CRAFTER_REVIEW_VERSION.

CI

Run crafter-build's Flatpak in the job and let it drive the job container's own flatpak-builder:

flatpak install --noninteractive catcrafts net.catcrafts.CrafterBuild//stable   # needed today too, as the base
dbus-run-session -- sh -c '
  flatpak run --die-with-parent net.catcrafts.CrafterBuild test &&
  flatpak run --die-with-parent net.catcrafts.CrafterBuild bundle'
# The app is now in build/flatpak-apps/net.catcrafts.CrafterReview/repo, on branch master.
flatpak build-commit-from --src-repo=build/flatpak-apps/net.catcrafts.CrafterReview/repo \
  --src-ref=app/net.catcrafts.CrafterReview/x86_64/master <live repo> app/net.catcrafts.CrafterReview/x86_64/stable

Signing, the summary and the .flatpak attached to the release stay as they are today. bundle also writes bin/<variant>.flatpak, which uses Flathub as its runtime repository; use it or keep the current build-bundle step.

Why dbus-run-session. crafter-build reaches the job container's flatpak through flatpak-spawn --host, which needs a session bus. With a private one, D-Bus starts flatpak-session-helper from the service file that Arch's flatpak package installs.
Where the checkout lives. It must not be under /tmp: that directory is the sandbox's own, and crafter-build refuses a project there.

Verified, and not

Verified on a workstation, 2026-11-02:

dbus-run-session -- flatpak run --talk-name=org.freedesktop.Flatpak net.catcrafts.CrafterBuild reached the host's flatpak 1.18.4 through flatpak-spawn --host.
crafter-build's own tests bundle a Flatpak with a module through flatpak-builder, install one into a private FLATPAK_USER_DIR, and check that a program finds its share data from files/bin.

Not verified:

any of this inside Crafter.Review's CI container;
Crafter.Review itself built this way.

crafter-build 6.1.0 (on its way to `stable`) can package an executable as a Flatpak itself. Crafter.Review's manifest could then drop the CrafterBuild base app and `prune-base.sh`: the program, the three LLVM libraries it links and its data come out of crafter-build ready to install, and flatpak-builder only adds node and ripgrep. **Blocked on** crafter-build 6.1.0 being on `stable`. That release brings the Flatpak output, the `bundle` and `install` verbs, and the `--talk-name=org.freedesktop.Flatpak` permission those verbs need. ## Today The manifest uses `net.catcrafts.CrafterBuild//stable` as its base, so flatpak-builder's build sandbox has crafter-build. Then `prune-base.sh` deletes everything of the base except the libc++, libc++abi and libunwind the binary links through its `/app/lib` run path. The finish-args, app-id and metainfo live in the YAML. ## With crafter-build's Flatpak output `project.cpp` describes the app, on the `crafter.review-exe` configuration: ```cpp cfg.packaging = Packaging::Flatpak; cfg.flatpak.appId = "net.catcrafts.CrafterReview"; cfg.flatpak.runtime = FlatpakRuntime::Sdk; // the lenses' Bash tool needs git, python3, curl, jq cfg.flatpak.permissions = { "--share=network", "--filesystem=host", "--filesystem=/tmp", "--filesystem=xdg-run/gnupg/S.keyboxd", "--env=PATH=/app/bin:/usr/bin" }; cfg.flatpak.metainfo = "packaging/flatpak/net.catcrafts.CrafterReview.metainfo.xml"; cfg.flatpak.share = { { "process", "crafter-review/process" }, { "LICENSE", "licenses/net.catcrafts.CrafterReview/LICENSE" }, }; cfg.flatpak.modules = { "packaging/flatpak/ripgrep.yaml", "packaging/flatpak/node.yaml" }; ``` - **What the build writes.** `bin/crafter.review-exe-<variant>/` becomes a finished Flatpak build directory: `metadata`, `export/`, and `files/` holding `bin/crafter-review`, `lib/` with the three LLVM libraries, and `share/`. - **`process/` under `-r`.** `<exe>/../share/crafter-review` (Crafter.Review-Core.cppm:33) finds `files/share/crafter-review` under `-r` as well, since `-r` runs the program from `files/bin`. - **The two modules** are the ripgrep and node modules of today's manifest, moved into module files of their own. crafter-build lists them in a manifest it generates, `build/flatpak-apps/net.catcrafts.CrafterReview/net.catcrafts.CrafterReview.json`, ending with a module that copies `files/` into `/app`. So the program is not compiled again in flatpak-builder. - **Stripping and `.Debug`.** With modules set, flatpak-builder still strips the binary and splits out the `.Debug` extension. - **`-march`.** As today, set `CRAFTER_BUILD_MARCH=x86-64-v2` and `CRAFTER_BUILD_MTUNE=generic` when building for release, along with `CRAFTER_REVIEW_VERSION`. ## CI Run crafter-build's Flatpak in the job and let it drive the job container's own flatpak-builder: ```bash flatpak install --noninteractive catcrafts net.catcrafts.CrafterBuild//stable # needed today too, as the base dbus-run-session -- sh -c ' flatpak run --die-with-parent net.catcrafts.CrafterBuild test && flatpak run --die-with-parent net.catcrafts.CrafterBuild bundle' # The app is now in build/flatpak-apps/net.catcrafts.CrafterReview/repo, on branch master. flatpak build-commit-from --src-repo=build/flatpak-apps/net.catcrafts.CrafterReview/repo \ --src-ref=app/net.catcrafts.CrafterReview/x86_64/master <live repo> app/net.catcrafts.CrafterReview/x86_64/stable ``` Signing, the summary and the `.flatpak` attached to the release stay as they are today. `bundle` also writes `bin/<variant>.flatpak`, which uses Flathub as its runtime repository; use it or keep the current `build-bundle` step. - **Why `dbus-run-session`.** crafter-build reaches the job container's flatpak through `flatpak-spawn --host`, which needs a session bus. With a private one, D-Bus starts `flatpak-session-helper` from the service file that Arch's `flatpak` package installs. - **Where the checkout lives.** It must not be under `/tmp`: that directory is the sandbox's own, and crafter-build refuses a project there. ## Verified, and not **Verified on a workstation, 2026-11-02:** - `dbus-run-session -- flatpak run --talk-name=org.freedesktop.Flatpak net.catcrafts.CrafterBuild` reached the host's flatpak 1.18.4 through `flatpak-spawn --host`. - crafter-build's own tests bundle a Flatpak with a module through flatpak-builder, install one into a private `FLATPAK_USER_DIR`, and check that a program finds its `share` data from `files/bin`. **Not verified:** - any of this inside Crafter.Review's CI container; - Crafter.Review itself built this way.