feat(distribution): Flathub (Flatpak) GUI path #232

Activity

1. cevheri

   added

   enhancementNew feature or requestNew feature or request

   deploymentPaaS / one-click deployment platform integrations and listingsPaaS / one-click deployment platform integrations and listings

   on Jul 28, 2026
2. cevheri

   self-assigned this

   on Jul 28, 2026
3. cevheri

   added the

   Feature

   issue type on Jul 28, 2026
4. cevheri

   changed the issue type from

   Feature

   to

   Task

   on Jul 28, 2026
5. cevheri commented on Jul 28, 2026

   

   cevheri

   on Jul 28, 2026

   MemberAuthor

   More actions

   Local Flatpak E2E - done

   The packaging work is in #235: the Tauri v2 desktop shell (desktop/), the AppImage release job,
   and the Flathub manifest (packaging/flatpak/). Everything below was run on this machine against
   the manifest and the AppImage that PR produces.

   Environment: Ubuntu 24.04 x86_64, X11 session; flatpak-builder 1.4.9 and flatpak-builder-lint
   3.0.0 from org.flatpak.Builder; org.gnome.Platform//50 + org.gnome.Sdk//50; PostgreSQL 18 on
   127.0.0.1:5433.

   Done bar

   • build/install locally with org.flatpak.Builder - scripts/build-flatpak-local.sh <appimage> --install renders both manifests, validates the metainfo (appstreamcli validate: pass),
     lints the release manifest (pass), builds, installs, and lints the exported repo (pass). The
     AppImage it repacks is 144 MB and its own --smoke boots the bundled server out of the
     extracted AppDir and gets 200 from /api/db/health.
   • flatpak run org.libredb.Studio starts the GUI - splash, then the workspace, with no
     login prompt: the shell reads the password the zero-config first run persisted in
     ~/.var/app/org.libredb.Studio/data/org.libredb.Studio/auth-bootstrap.json and hands it to
     /api/auth/login. Zero error lines in the app log.
   • walk the main screens - workspace, connections sidebar, schema explorer, Monaco editor,
     results panel, admin dashboard. Screenshots below.
   • add a sample PostgreSQL connection over TCP - 127.0.0.1:5433, user postgres, database
     companyos. "Test Connection" answered Connected successfully (55ms) from inside the
     sandbox, and the schema loaded with 58 tables and row counts.
   • run a query and see rows in the results grid - SELECT 1 AS ok, current_database() AS db
     returned 1 rows - 1ms, ok = 1, db = companyos.
   • note on this issue - this comment.

   Note on how the walkthrough was driven: the WebKitGTK window has no scriptable input on this box (no
   xdotool/ydotool), so the clicking part of the connection-and-query walkthrough was done against
   the same sidecar the Flatpak app was running (http://127.0.0.1:<port>) from a browser, and the
   result then verified inside the app's own window after a restart. The screenshot above is the Flatpak
   window itself: Local PostgreSQL (TCP) selected, POSTGRES - LOCAL - Online, 58 tables in the
   explorer.

   What the run turned up (all fixed in #235)

   • Tauri's resource copy drops symlinks, and Turbopack resolves the externalized DB drivers through
     hashed symlinks under payload/.next/node_modules - the server logged "Ready" and then failed
     every request with Failed to load external module ssh2-<hash>.
   • flatpak-builder strips binaries by default, which turned the bundled better_sqlite3.node into
     "object file has no loadable segments" and took SQLite storage down while the app looked healthy.
     The module now sets strip: false / no-debuginfo: true.
   • The session cookie was marked Secure whenever NODE_ENV=production; libsoup (the cookie store
     behind WebKitGTK) discards such a cookie over http instead of ignoring the flag the way Chromium
     does on localhost, so the handoff signed in and then bounced between /login and / forever.
     Secure is now omitted only for loopback-over-http requests.
   • linuxdeploy needs APPIMAGE_EXTRACT_AND_RUN=1, patchelf and librsvg2-dev, and hard-fails on
     sharp's Alpine libvips build (libc.musl-x86_64.so.1).
   • Two repo-lint checks (appstream-external-screenshot-url, appstream-remote-icon-not-mirrored)
     can only pass inside Flathub's own pipeline, which rewrites media URLs to dl.flathub.org. They
     are listed in packaging/flatpak/lint-exceptions.json with the reason; everything else the linter
     reports stays a hard failure.

   Still open on this issue

   • The submission PR against flathub/flathub (base branch
     new-pr, title Add org.libredb.Studio) - a maintainer step. Checklist in
     packaging/flatpak/README.md. Worth saying in that PR up front that the manifest repacks the
     released AppImage rather than building from source, and why.
   • The domain-verification token at https://libredb.org/.well-known/org.flathub.VerifiedApps.txt -
     Flathub only issues it after the submission exists, so it is a libredb-website follow-up.
   • A <release> entry in org.libredb.Studio.metainfo.xml for whichever version first ships to
     Flathub (the External Data Checker maintains the manifest sources, not the release list).
6. cevheri

   added 3 commits that reference this issue on Jul 28, 2026

   test(auth): expose headers() in every next/headers module mock (#232)

   ...

   82fe283

   docs(distribution): add the desktop AppImage to the channel inventory (…

   ...

   7e99940

   feat(distribution): desktop shell, AppImage release artifact and Flat…

   ...

   dc3a02d
7. cevheri commented on Jul 28, 2026

   

   cevheri

   on Jul 28, 2026

   MemberAuthor

   More actions

   Flathub submission opened as a draft: flathub/flathub#9538

   It stays draft until 0.9.60 ships, because the manifest references that release's AppImage and the two sha256 values are placeholders until then. Before marking it ready:

   1. cut 0.9.60 (the desktop-appimage job attaches the two AppImages plus their .sha256 sidecars)
   2. put the real checksums into org.libredb.Studio.yml on the submission branch
   3. attach a short screencast of the Flatpak running (the template asks for a video)
   4. add a entry for 0.9.60 to org.libredb.Studio.metainfo.xml

   The domain token for https://libredb.org/.well-known/org.flathub.VerifiedApps.txt is issued from the developer portal after the app repository exists, so that stays a follow-up on libredb-website.
8. cevheri

   added 3 commits that reference this issue on Jul 28, 2026

   feat(auth): add AUTH_COOKIE_SECURE to allow login over plain HTTP

   ...

   c0473df

   feat(auth): add AUTH_COOKIE_SECURE to allow login over plain HTTP

   ...

   ed062cf

   feat(auth): add AUTH_COOKIE_SECURE to allow login over plain HTTP (#236)

   ...

   2f90c4b
9. cevheri

   added

   loop:needs-moderator-actionFlagged by the maintainer loop: suspicious content or a decision only a human can makeFlagged by the maintainer loop: suspicious content or a decision only a human can make

   on Jul 29, 2026
10. cevheri commented on Jul 30, 2026

    

    cevheri

    on Jul 30, 2026

    MemberAuthor

    More actions

    Outcome: the Flatpak GUI path shipped, the Flathub listing did not

    Closing this. Everything in scope was built and verified; the one part that depended on a third party did not go our way, and there is no version of it left to work on.

    Shipped

    • Tauri v2 desktop shell with the standalone server as a sidecar (desktop/), released as an AppImage (x64 + arm64) since 0.9.60 and as a GUI .deb since 0.9.62. Both are hard gates on publish-release, and both carry SLSA build provenance.
    • Flatpak manifest template and renderer in packaging/flatpak/, plus flatpak-smoke.yml, which builds the AppImage and repacks it on both architectures.
    • Local E2E from the acceptance list: org.flatpak.Builder build and install, flatpak run org.libredb.Studio starting the GUI, a walk through login/workspace/connections/editor/results, a PostgreSQL connection over TCP and a SELECT 1 returning rows. The walkthrough video is on the submission PR.
    • Domain verification file live at https://libredb.org/.well-known/org.flathub.VerifiedApps.txt (no token: Flathub only issues one after publication).
    • docs/DISTRIBUTION.md section and the distribution/channels.yaml entry.

    Not shipped: the Flathub listing

    The submission, flathub/flathub#9538, was declined on 2026-07-30 under Flathub's generative AI policy. The reviewer's position was that developing with an AI code assistant disqualifies the app, independently of who designed, reviewed and released it. We closed the PR ourselves rather than argue it:

    flathub/flathub#9538 (comment)

    That comment leaves the verifiable record on the thread - repository public since 2025-12-23, MIT, 62 releases, 100% line coverage as a hard merge gate, and 21 live distribution channels.

    Where Flatpak users go instead

    FlatPark, live since 0.9.62 (#241) with the developer-approved flag. Same app id, same sandbox policy. It pins the GUI .deb as extra-data rather than repacking the AppImage:

    flatpak --user remote-add --if-not-exists flatpark https://dl.flatpark.org/flatpark.flatpakrepo
    flatpak --user install flatpark org.libredb.Studio

    What stays in the tree

    packaging/flatpak/ is kept, not deleted. flatpak-smoke.yml is now its only consumer and is real coverage of the desktop AppImage. It is marked dormant in packaging/flatpak/README.md and the channel is deprecated in channels.yaml, both pointing at the closing comment above (#252).

    Reopening this would need a from-source Flatpak build, which is a separate and independent blocker: Flathub requires submissions to be built entirely from source, and flatpak-node-generator has no Bun support. That is a new issue if we ever want it, not this one.
11. cevheri

    closed this as completedon Jul 30, 2026
12. cevheri

    removed

    loop:needs-moderator-actionFlagged by the maintainer loop: suspicious content or a decision only a human can makeFlagged by the maintainer loop: suspicious content or a decision only a human can make

    on Jul 30, 2026