Gale manages Thunderstore mods as per-game profiles you can import, export
and share. It is not on Flathub: upstream's submission was closed, and the
permissions the app needs (a host hand-off to launch Steam) would not have
passed Flathub's rules either, which is the gap FlatPark exists to fill.
Upstream already publishes a Flatpak of their own from kesomannen.com, and
this package uses the same application id on purpose, so the two are the same
ref from two remotes rather than two competing entries - and so the listing
can simply be dropped later without stranding anyone. The metainfo says so in
its first paragraph.
Packaged as extra-data from the official amd64 .deb on org.gnome.Platform//50,
the same Tauri/WebKitGTK shape as NoteGen. The shared-mime-info package for
.r2z is shipped at build time rather than taken from the payload, because
Flatpak exports MIME packages when the app is built and the .deb only arrives
later.
Sandbox: narrower than upstream's own manifest, which grants --filesystem=home.
Here it is the three Steam locations Gale has to write mods and Proton wine
overrides into (~/.steam, ~/.local/share/Steam, the Flatpak Steam data dir),
with a library on another drive documented as a `flatpak override`. The one
broad permission is --talk-name=org.freedesktop.Flatpak, declared under
policy.dangerous_permissions: Gale detects the sandbox from the `container`
variable by itself and starts Steam through flatpak-spawn --host, since a game
has to run on the host. X11 is granted alongside Wayland rather than as
fallback-x11 for the same clipboard reason as OpenPencil.
Co-authored-by: Claude Opus 5 <[email protected]>
OpenPencil is a design editor that reads and writes native Figma .fig files
as well as its own .pen documents. The catalog has no vector/UI design tool
at all - Impasto is raster painting and tldraw offline is a whiteboard - and
upstream is not on Flathub.
Packaged as extra-data from the official amd64 .deb on org.gnome.Platform//50,
the same Tauri/WebKitGTK shape as NoteGen: the whole usr tree is staged under
/app/extra, the launcher name is read out of the package's own .desktop Exec=
so an upstream rename cannot ship an app that will not start, and the wrapper
only sets WEBKIT_DISABLE_DMABUF_RENDERER.
The app id follows openpencil.dev, the project's own domain, rather than the
maintainer's personal domain that the Tauri bundle identifier uses.
Sandbox: network for the AI providers and the WebRTC collaboration sessions,
the Secret Service for provider API keys, dri for canvas rendering, and no
filesystem grant - documents go through the file-chooser portal. X11 is
granted alongside Wayland rather than as fallback-x11, because the clipboard
that copies nodes between apps falls back to X11 whenever the compositor does
not offer Wayland data-control to a sandboxed client, and fallback-x11
withholds the socket in exactly that case.
Co-authored-by: Claude Opus 5 <[email protected]>
An upstream release ping opened a PR and stopped there, waiting for a
maintainer, while the daily sweep merged the identical pins unattended at
06:17 UTC. That gap is what upstreams see: zbcoding dropped the Notify
FlatPark step from ImpastoPaint's release job because "each ping opens an
update PR that only their side can merge, and nothing about their setup
suggests those merges are automatic".
Merge it here on the daily sweep's terms, with two things the sweep cannot
be as strict about:
- the diff must be exactly the pinged app's <id>.yml / <id>.metainfo.xml,
since push mode knows which app it asked for (the sweep can only require
"some app's manifest or metainfo");
- the payload was already unpacked with the app's own apply_extra.sh two
steps up, before the PR was opened at all.
Also install appstreamcli: update-pins validates upstream's release notes
before writing a <release> into the metainfo, but silently skips that when
the validator is missing, and this job now merges those notes unattended.
Same AUTO_MERGE_PINS kill switch as the sweep rather than a second variable,
the same post-merge publish dispatch (a GITHUB_TOKEN push triggers no
workflow), and the same cleanup of the orphaned pr-checks run left behind by
--delete-branch.
No per-app opt-in: the sweep already merges every app's pins unattended, so
gating push mode per app would only delay the same bytes by a day.
Co-authored-by: Claude Opus 5 <[email protected]>
NoteGen is a Tauri/WebKitGTK notebook that separates capturing from
organizing: records (text, voice, screenshots, images, links, files) go in
as they happen, and a model of your choice turns a selection of them into a
structured Markdown note you keep editing. Not on Flathub under any id, and
upstream ships an official amd64 .deb, so it repackages cleanly as
extra-data.
The app id is upstream's own Tauri identifier from tauri.conf.json rather
than one invented here.
Two things needed care in the sandbox. The clipboard plugin the app builds
on opens an X11 display while it initialises and exits with
DisplayParsingError(DisplayNotSet) when there is none, so the package grants
--socket=x11 rather than fallback-x11, which withholds X11 whenever Wayland
is present; the window stays Wayland-native. And the .deb's payload is a
binary plus a Tauri resource tree at usr/lib/NoteGen that the app resolves
relative to its own executable, so apply_extra stages the whole usr tree and
links a stable launcher name into /app/extra/bin - the launcher name itself
is read out of the package's .desktop Exec= so a rename upstream cannot ship
an uninstallable pin, and the link's name keeps matching StartupWMClass.
Beyond network, audio and the tray, nothing is granted: the workspace,
database, images and attachments live under ~/.var/app/com.codexu.NoteGen,
and a workspace elsewhere is an opt-in flatpak override documented in the
metainfo.
Co-authored-by: Claude Opus 5 <[email protected]>
The publish run's expensive half is the OSTree repo: the flatpak toolchain
install, the repo cache and the rclone pull of the whole object store from R2
(323s on the last run), then the push back. A push that cannot change a
published byte — a site edit, config/featured.yml, a catalog-only descriptor
edit like a developer-approved flip, metainfo/icons — pays all of it to upload
nothing.
scripts/publish-scope.sh decides that up front and prints "site" or "full".
It answers "full" for anything not provably repo-neutral: publish tooling
(scripts/, config/flatpark.conf, publish.yml), a build-relevant app change
(changed-apps.sh), an app added or de-listed, or a rename (the .flatpakref
Title). The workflow gates the toolchain, the signing key, the repo cache,
both R2 syncs, the summary re-sign and the .published-sha write on it; the
site build and the Pages deploy always run.
The diff base is .published-sha read straight from R2 (rclone cat, no sync),
so a failed publish keeps its registry changes in the diff and the next push
still runs full. A site publish leaves the marker alone for the same reason.
Co-authored-by: Claude Opus 5 <[email protected]>
Vynody is a Flutter + Rust music player built around a local library:
folder scanning, synced lyrics from LRCLIB or an AI provider, tag
completion via audio fingerprinting, and Navidrome/WebDAV streaming. It
is not on Flathub under any app id.
The payload is upstream's official x86_64 Linux tarball as extra-data,
kept byte-for-byte under /app/extra. The bundle is a self-contained
Flutter tree - engine, the Rust audio core and its bundled FFmpeg - so
the freedesktop 25.08 runtime covers every remaining NEEDED library.
apply_extra reads the launcher name out of the archive rather than
hardcoding it, and unpacks with --no-same-owner because the tarball
records the build machine's uid/gid.
The sandbox grants only what the app was observed to use: xdg-music for
the library scanner, MPRIS and StatusNotifier names it actually owns,
the Secret Service for saved server credentials, and Avahi for its
local-network sharing. Tracks opened from a file manager arrive through
the document portal, so no directory grant is needed for them.
Claude-Session: https://claude.ai/code/session_01PFw3uc57Wm8V9shhvKwVGG
Co-authored-by: Claude Opus 5 <[email protected]>
Tencent's AI agent desktop workspace, packaged from the official Linux
.deb as extra-data. Electron 37 on the Electron base app via zypak; the
payload ships its own Node 22 and CPython 3.13 runtimes, so nothing is
forwarded to the host and no org.freedesktop.Flatpak talk name is needed.
Update resolver reads upstream's own per-platform update endpoint. The
version is taken from the published filename rather than the feed's
"version" field so the trailing commit hash is kept: upstream re-cuts a
build under the same numeric version with a new hash, and a trimmed
version would never re-pin. Both arches are resolved together and must
agree, and the download host is pinned so a feed that ever points
elsewhere fails loudly instead of re-pinning the app somewhere new.
Filesystem grants cover the three directories WorkBuddy hardcodes off
os.homedir(): ~/.workbuddy (account state, plugins, skills, downloaded
runtimes), ~/WorkBuddy (per-task workspaces) and ~/.workbuddy-key-fallback
(connector key material used when the keyring is unavailable). Verified
against the running sandbox that nothing else it persists lands on the
tmpfs $HOME; broad home access stays opt-in.
The tray needs only --talk-name=org.kde.StatusNotifierWatcher — this
Electron registers the item under its unique connection name, so no
--own-name and no getpid shim. Verified both ways against the watcher's
RegisteredStatusNotifierItems.
The metainfo documents that the agent's command tool needs WorkBuddy's
built-in sandbox switched off in Settings > Security Center: that sandbox
is built on user namespaces and mount operations, which Flatpak does not
permit to an app inside it. Commands then run confined by this package's
Flatpak permissions instead.
Co-authored-by: Claude Opus 5 <[email protected]>
The payload upstream now serves no longer unpacks under this app's
apply_extra, so the pin has been frozen at v0.47.18 since the CI alert
(#323) while upstream has moved on to v0.50.3. Rather than keep chasing
the repackaging, the listing is withdrawn.
Upstream is not looking for a Flatpak on our side either: browseros-ai/BrowserOS#164,
the request for Flatpak support, was closed as not-planned in June, and the
comment introducing the FlatPark listing there has had no reply since July.
With no upstream interest and a payload we would have to keep re-fitting on
our own, the package is not worth carrying.
Deleting registry/<id>/ is the whole de-list: delist-prune drops the
app/<id>/* refs, prunes and re-signs the summary, and sync-r2 removes the
stale ref files; the site and discovery feed build from the registry.
No featured.yml entry and no upstream_approved shield to clean up.
Closes#323
Claude-Session: https://claude.ai/code/session_01RepwmKX2p84HPmgYaEYtRt
Co-authored-by: Claude Opus 5 <[email protected]>
Keep held drags between their original pair of slides and use the clamped displacement when settling, so reversing past the origin cannot select a third image.
Dismiss the copied hint when opening the install menu, synchronize its expanded state, and add pointer cursors to install, show-more, and category controls. Cover swipe reversals with 20 regression cases.
Every --talk-name finish-arg was blanket-classified as the lowest
'info' risk level, same tier as PulseAudio or GPG-agent access. But
talk-name to org.freedesktop.Flatpak lets a sandboxed app run
flatpak-spawn --host, i.e. execute commands on the host — a real
sandbox-escape vector present in 27+ registry manifests, not a
ChatGPT-specific issue.
Closes#304
Co-authored-by: Claude Sonnet 5 <[email protected]>
Folo now ships a -linux-x64.deb (from desktop/v1.13.0), so repackage that
directly instead of extracting the AppImage with the appimage-tools prebuilt
stack. The .deb is a single extra-data source; the second (appimage-tools)
source is gone.
- apply_extra.sh: bsdtar reads the .deb ar container and unpacks data.tar.zst.
The app tree is at usr/lib/folo/ with launcher "Folo"; both the dir and the
launcher name are resolved from the usr/bin/folo -> ../lib/folo/Folo symlink
(the .deb's own .desktop only has a bare Exec=folo), and the name is recorded
in /app/extra/launcher.
- folo-wrapper: drop LD_LIBRARY_PATH=/app/extra/folo/usr/lib. The .deb bundles
no tray libraries; libappindicator3 + libdbusmenu come from the Electron base
app's /app/lib. Read the launcher name from /app/extra/launcher.
- manifest: managed block -> folo.deb 1.13.0; comments updated.
- resolve-update.sh: match -linux-x64.deb, emit filename folo.deb.
- metainfo: note the .deb repackage; add the 1.13.0 release.
Verified: scripts/check-apply-extra.sh is.folo.Folo passes (real .deb, root with
all caps dropped, offline). Local build + install + run: app starts through
zypak-wrapper /app/extra/folo/Folo, loads the renderer, API 200.
Co-authored-by: Claude Sonnet 5 <[email protected]>
Header control order is now theme toggle -> language switcher -> GitHub
link. The lang dropdown keeps right-0; the GitHub button to its right keeps
it clear of the viewport edge.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WFMXxs6pBNGzr6kajevEoc
AppImage packaging is solved (appimage-tools prebuilt cracks the appended
SquashFS offline, no libfuse, never executed), so drop every "AppImage is
not accepted" line and document the recipe instead:
- packaging-playbook §2 gate + §3 tech recipe (Folo / OpenShot references)
- discovery-pipeline §3 gate + §4 recipe bullet
- pr-review Phase 5 + rubric: an AppImage that runs the stub or needs FUSE
is the reject, not the format
- site policies / about / contributing / trust (+ zh-Hans): AppImage listed
as an accepted artifact, unpacked offline
New constraint, same docs: only a shared flatpark/prebuilt stack (Ayatana
tray, appimage-tools, mpv/sql/opencv, ...) may land bytes in /app and ship
from R2. App payloads and single-app dependencies must be extra-data, not
built into the ref. Added as playbook golden rule 2 (rules renumbered),
discovery-pipeline §4, pr-review Phase 3 + rubric + template row 3.1b, and
the contributing prebuilt section.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01WFMXxs6pBNGzr6kajevEoc
CodeBuddy's site (both codebuddy.cn and codebuddy.ai) answers HTTP 404 to every
HEAD request while serving the same URLs fine over GET, so check-links flagged
all six of the app's links. The probe already falls back to GET for 403/405/501;
widen that to any missing-or-non-2xx HEAD, then let a genuine dead link fail the
GET. test_check_links still passes (its HEAD-then-GET connection-count assertion
is unaffected).
Also point project_license at the product page (no standalone terms page
exists — the /docs/legal/terms-of-service path renders a JS "not found") and the
release note at the real /docs/ide/release-notes/release-notes.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Requested in #298. CodeBuddy is Tencent's AI-native editor built on Code - OSS
(Electron 37, Code-OSS 1.106); the "CN" build is the only one Tencent ships for
Linux. Not on Flathub.
Packaged as extra-data from the official x86_64 .deb
(download.codebuddy.cn/aiide/linux-x64/...), unmodified: Electron2 BaseApp +
zypak so Chromium keeps its internal sandbox, apply_extra unpacks the .deb with
bsdtar and stages /usr/share/buddycn whole, the launcher name is read from the
.deb's own desktop entry. resolve-update.sh tracks upstream's version feed
(aiide/version.json); the full build string is kept as the release version
because upstream re-cuts a release under the same 4.x.y with a new hash.
Sandbox mirrors ai.z.zcode (same class of app): network, wayland/x11, dri,
pulseaudio, notifications, secrets, and the app's own ~/.codebuddycn; NOT
--filesystem=home (documented as an opt-in override in the metainfo, along with
~/.ssh:ro). The editor and its agent shell out to host developer tools, so the
wrapper puts a flatpak-spawn --host PATH bridge in front of git / toolchains —
this needs --talk-name=org.freedesktop.Flatpak, declared in
policy.dangerous_permissions.
Verified: read/audit-descriptor clean, build + appstreamcli compose Success,
check-apply-extra OK as root with caps dropped, full test suite green, installed
into a throwaway --user remote and launched on Wayland — editor window,
extension host and the CodeBuddy agent chat panel all render, integrated
terminal's node-pty / @vscode/sqlite3 / @parcel/watcher load as native x86_64.
Not verified: sign-in (needs a Tencent Cloud account), the agent end to end.
Note: the upstream Linux .deb ships no .node binary for @vscode/spdlog or
native-keymap, so logging falls back to console and keyboard-layout detection is
disabled (VS Code's own fallbacks apply) — upstream behaviour, unchanged here.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
The `deno` module staged the Deno runtime via `type: archive`, so its
~95 MB (stripped) binary was baked into the OSTree commit and synced to
R2 — R2 grew from <50 MB to ~90 MB after OpenTubeX landed (#275).
Fetch the official deno zip as extra-data (x86_64 + aarch64) instead.
apply_extra.sh unpacks it (a single `deno` executable) next to the app
payload with the same bsdtar path already used for the portable zip, and
opentubex-wrapper prepends /app/extra to PATH so yt-dlp still finds it.
Pinned by hand and kept outside the MANAGED EXTRA-DATA block, matching
the appimage-tools pattern in OpenShot/Folo.
Claude-Session: https://claude.ai/code/session_01Bkxv9eZ46GSKuPqDBTBnmK
Co-authored-by: Claude Sonnet 5 <[email protected]>
The 512x512 PNG had a black fringe around the rounded-square edge.
Replace it with upstream's own icon.svg (renderer/public/icon.svg),
installed to hicolor/scalable/apps. The site catalog generator
already prefers .svg over .png.
Co-authored-by: Claude Sonnet 5 <[email protected]>
OpenShot ships its Linux build only as an AppImage — no .deb, .rpm or plain
tarball — which FlatPark's playbook has so far treated as a hard stop. It is
not one: a type-2 AppImage is an ELF stub with a SquashFS image appended, and
that image unpacks directly without the AppImage ever being executed or
FUSE-mounted. This is the first app to use that route.
Packaging:
- extra-data, org.freedesktop.Platform//25.08. The AppImage is fully
self-contained (its own Python 3.8, PyQt5, libopenshot, FFmpeg, Blender), so
no KDE/GNOME runtime is needed — verified nothing in the bundle resolves
against the runtime's Qt/Python, and the bundle ships no libGL/EGL/fontconfig
to shadow it.
- Second extra-data source: flatpark/prebuilt's appimage-tools-v1
(appimage-offset + unsquashfs, 54 KB). apply_extra computes the SquashFS
offset from the ELF header and unpacks with unsquashfs -o; the AppImage and
the extractor are deleted afterwards. Passes check-apply-extra.sh (root, all
caps dropped, offline, /usr + /app/extra only).
- Wrapper execs the AppDir's own usr/bin/openshot-qt-launch and pins
QT_QPA_PLATFORM=xcb: the bundle ships the Qt5 wayland plugins but not the
libQt5WaylandClient.so.5 they link, so wayland cannot initialise and Qt does
not fall back on its own. Runs through XWayland.
Sandbox: ipc, x11, dri, pulseaudio, network (update check / title templates /
AI model download), xdg-videos/pictures/music/download for project footage, and
--persist=.openshot_qt so OpenShot's state dir lands in the per-app directory
rather than tmpfs or the real home. No --filesystem=home. dangerous_permissions
is empty.
OpenShot is on Flathub (currently 3.5.1, behind upstream's 4.0.0); this entry
is primarily the AppImage-extraction mechanism proven end to end.
Claude-Session: https://claude.ai/code/session_016F22CmZ197QR9hW3qiVxQC
Co-authored-by: Claude Sonnet 5 <[email protected]>
Folo ships its Linux build only as an AppImage (electron-builder) — no .deb,
.rpm or tarball. It is not on Flathub, and there is an open request for a
Flatpak (RSSNext/Folo#1067). This uses the AppImage-extraction route: a type-2
AppImage is an ELF stub with a SquashFS image appended, unpacked directly at
install time without ever executing it or FUSE-mounting it.
Packaging:
- extra-data, base org.electronjs.Electron2.BaseApp//25.08 (for zypak),
runtime org.freedesktop.Platform//25.08. The AppImage bundles Chromium, its
own ffmpeg/ANGLE/SwiftShader and app.asar; GTK3/NSS/CUPS/X11/libsecret come
from the runtime (verified against the binary's NEEDED set, 0 missing).
- Second extra-data source: flatpark/prebuilt appimage-tools-v1
(appimage-offset + unsquashfs). apply_extra unpacks the AppDir and deletes
the AppImage + extractor. Passes check-apply-extra.sh (root, all caps
dropped, offline, /usr + /app/extra only).
- Wrapper runs the launcher through zypak-wrapper with
--ozone-platform-hint=auto, puts the AppImage's usr/lib (bundled tray libs)
on LD_LIBRARY_PATH, and clears ELECTRON_RUN_AS_NODE. electron-builder names
the binary after productName, which upstream can change, so apply_extra reads
it from the bundled Folo.desktop Exec= and drops a stable-named symlink.
- app-id is.folo.Folo (folo.is). Icon resized from the AppImage's 1108px PNG to
512x512 (flatpak-validate-icon caps at 512).
Sandbox: ipc, network, wayland, fallback-x11, dri, Notifications,
StatusNotifierWatcher (tray), --unset-env=ELECTRON_RUN_AS_NODE. No filesystem
access — OPML import/export goes through the portal; Downloads and full home
are documented flatpak override opt-ins. Folo's own data stays under the
per-app home (Electron honours XDG_CONFIG_HOME; no --persist needed).
Verification: build + appstreamcli Success; check-apply-extra OK; installed and
launched — full Electron/zypak process tree, renderer loads app.asar, config
persists in ~/.var/app/is.folo.Folo with no leak to the real ~/.config/Folo.
Not verified: signed-in sync, tray on every desktop, GPU video decode.
Claude-Session: https://claude.ai/code/session_016F22CmZ197QR9hW3qiVxQC
Co-authored-by: Claude Sonnet 5 <[email protected]>
PR #286 tried to skip pr-checks on auto/update-pins-* via a per-job `if:` on
github.head_ref. That can't work: the run fails at setup ("This run likely
failed because of a workflow file issue", zero jobs) because --delete-branch
removes the merge ref before GitHub fetches the workflow file — so the job
`if:` is never evaluated. Manual run today still produced a red
"Update extra-data pins (2026-08-31)". Also the guard wrongly covered
auto/release-* PRs, which are human-merged and *should* run pr-checks.
Revert pr-checks.yml to its pre-#286 state. Instead, after the auto-merge in
update-check.yml, find that doomed pr-checks run by head SHA (captured before
the branch is deleted), wait for it to finish failing, and delete it via the
API — the job already has actions:write. Every payload in the merged diff was
unpacked by "Verify the new payloads unpack" and publish.yml rebuilds each
app, so the run adds nothing. Best-effort: a run that never appears just means
nothing to clean.
release-dispatch.yml: its auto/release-* PRs are not auto-merged, so pr-checks
runs on them normally; reword the stale "GITHUB_TOKEN PR does not trigger
pr-checks" comment to describe the pre-PR unpack gate as what it is.
Claude-Session: https://claude.ai/code/session_0188yAm5HVmxYRG4aLfBWsdg
Co-authored-by: Claude Sonnet 5 <[email protected]>
