Skip to content

Package as a Flatpak and build it in CI - #2

Open
Josh-Reimer wants to merge 3 commits into
mainfrom
flatpak-packaging
Open

Package as a Flatpak and build it in CI#2
Josh-Reimer wants to merge 3 commits into
mainfrom
flatpak-packaging

Conversation

@Josh-Reimer

Copy link
Copy Markdown
Owner

Packages BibleApp as a Flatpak and adds CI so it can be built and tested without a Linux machine.

What's here

  • flatpak/io.github.josh_reimer.BibleApp.yml — manifest building Tcl 8.6.15, Tk 8.6.15, CPython 3.12.11, then the app
  • flatpak/bibleapp — launcher installed to /app/bin/bibleapp
  • flatpak/*.desktop, flatpak/*.metainfo.xml — desktop entry and AppStream metadata
  • .github/workflows/flatpak.yml — builds x86_64 + aarch64 bundles, plus a fast metadata-validation job
  • CLAUDE.md — repo guide

Why Tcl, Tk, and Python are built from source

The freedesktop runtime ships Python but not Tkinter. Python 3.12 removed --with-tcltk-includes/--with-tcltk-libs and now locates Tk solely via pkg-config (tcl >= 8.5.12 tk >= 8.5.12), which is why PKG_CONFIG_PATH=/app/lib/pkgconfig is set on the python3 module and Tcl/Tk must install their .pc files first. A post-install step runs import tkinter so a broken chain fails the build instead of producing an app that can't open a window.

Settings had to move

/app is read-only in the sandbox. The old _bpath("settings.json") would have hit the except OSError: pass in save_settings() and silently discarded every preference. Settings now live at $XDG_CONFIG_HOME/bibleapp/settings.json; load_settings() still reads the old path once so existing settings carry over.

Not yet verified

The build itself — flatpak-builder doesn't run on macOS, so this PR's CI run is the first real test. Two things to watch:

  • appstreamcli validate may fail on the LicenseRef-proprietary placeholder in the metainfo (the repo has no LICENSE file, so that value is currently accurate).
  • The aarch64 job assumes the freedesktop-24.08 container image is published multi-arch. If it fails on image pull, drop that matrix entry.

Before submitting to Flathub

  • Add a LICENSE file and set project_license to its SPDX id
  • Tag a release and switch the manifest's type: dir source to a pinned tag + commit
  • Confirm the app ID is final — it's permanent after first publish
  • Rehost the screenshot if the build bot can't fetch the user-attachments URL

🤖 Generated with Claude Code

Josh-Reimer and others added 3 commits July 31, 2026 06:54
Adds a Flatpak manifest, launcher, desktop entry, and AppStream metainfo
under flatpak/, plus a GitHub Actions workflow that builds the bundle on
x86_64 and aarch64 and validates the metadata.

The freedesktop runtime ships Python but not Tkinter, so the manifest
builds Tcl, Tk, and CPython. Python 3.12 removed --with-tcltk-includes
and locates Tk only through pkg-config, hence PKG_CONFIG_PATH on the
python3 module; a post-install "import tkinter" fails the build rather
than shipping an app that cannot open a window.

Settings move to $XDG_CONFIG_HOME/bibleapp/settings.json. The install
directory is read-only under Flatpak, so the previous location next to
the script would have made save_settings() silently discard every
preference. The old path is still read once so existing settings carry
over.

Also adds CLAUDE.md documenting the data format, the index-aligned book
name lists, the theming split, and the packaging setup.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The flatpak-github-actions image is published for x86_64 only, so the
arm64 runner failed at docker pull with "no matching manifest for
linux/arm64/v8" before any build work started. Install flatpak from apt
on the native arm runner and drive flatpak-builder directly instead.

Ubuntu 24.04 confines unprivileged user namespaces with AppArmor, which
blocks bubblewrap, so the job relaxes that sysctl before building.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Tcl and Tk install their shared libraries mode 555. flatpak-builder's
eu-strip pass then fails with "Permission denied" on libtcl8.6.so
wherever rofiles-fuse is not mediating writes, which is how the aarch64
job runs. The x86_64 job happened to survive this because the container
build uses rofiles-fuse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant