{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiahhb6xgko6ybxksl7mlsn3z6qian64vj3b5g3ktcwdaexwxlxpju",
    "uri": "at://did:plc:yrn4rbgwenb6lfhhzjegbtnc/app.bsky.feed.post/3mnxo64wykqd2"
  },
  "path": "/t/introducing-flutpak-automating-flathub-submission-for-flutter-apps/12294#post_5",
  "publishedAt": "2026-06-10T15:47:06.000Z",
  "site": "https://discourse.flathub.org",
  "tags": [
    "successful Flathub CI run",
    "PR #8889",
    "requirements",
    "@bbhtt",
    "cargokit",
    "crates.io",
    "Crates.io",
    "@hfiguiere"
  ],
  "textContent": "# flutpak — major update (0.8.0): Rust/Cargo support, flatpak-flutter-compatible registry, no local SDK required\n\nSince the original post (and the first successful Flathub CI run) a lot has landed. I want to give a proper update, especially on two points raised in the thread.\n\n## A note on the proof-of-concept submission\n\nThe previous update in this thread reported that PR #8889 passed the Flathub test build on the first try — that part is still true: the build succeeded for both `x86_64` and `aarch64`. However, the PR was subsequently closed for reasons unrelated to the packaging itself:\n\n  1. **Proprietary dependency** — `objectbox-c` is distributed as a prebuilt binary under the Apache License with no source code available. @hfiguiere flagged this as incompatible with the app’s GPL-3.0 license.\n  2. **Generative AI policy** — Flathub’s requirements restrict AI-generated code in submissions. Claude was used during development of the app, which made the PR ineligible.\n\n\n\nNeither of these is a flutpak issue — the tool produced a correct, buildable manifest. The rejection is about the specific app’s dependencies and its codebase, not the packaging toolchain. I mention it for transparency since this thread had the earlier “CI passed” update and it would be misleading to leave it without follow-up.\n\n* * *\n\n## Registry now compatible with flatpak-flutter\n\n@bbhtt raised the point about `flatpak-flutter`. Since then the foreign deps registry format has been aligned to be **fully schema-compatible with`flatpak-flutter`’s `foreign_deps.json`**. Every entry from the `flatpak-flutter` registry can be used in flutpak with no changes. flutpak extends the schema by one optional field (`crlf:` on patch sources); `flatpak-flutter` silently ignores it.\n\nThe registry currently covers 19 packages:\n\n  * `objectbox_flutter_libs` / `objectbox_sync_flutter_libs`\n  * `sqlite3` / `sqlite3_flutter_libs` / `sqlcipher_flutter_libs`\n  * `simple_secure_storage_linux`\n  * `audiotags`, `flutter_webrtc`, `media_kit_libs_linux`, `pdfium_flutter`,\n`printing`, `flutter_new_pipe_extractor`, `fvp`, `powersync`\n  * `rhttp`, `metadata_god`, `super_native_extensions`, `flutter_discord_rpc`,\n`flutter_vodozemac` (cargokit/Rust — see below)\n\n\n\nAll native archive sources, patches, and version-stamped `dest:` paths are\nresolved and injected automatically by `flutpak generate`. No manual source\nhunting per release.\n\n**Version matching is`≤`**: a registry entry for `1.0.0` covers `1.2.3`,\n`1.5.0`, etc., reducing churn when upstream bumps patch/minor versions.\n\n* * *\n\n## Rust / Cargo offline builds (0.8.0)\n\nFlutter plugins using cargokit\n(`rhttp`, `metadata_god`, `super_native_extensions`, etc.) now work out of the\nbox. Add a `rust:` section to `flutpak.yaml`:\n\n\n    rust:\n      version: 1.85.0\n      rustup-path: /var/lib/rustup\n\n\n`generate` will:\n\n  1. Extract `Cargo.lock` from pub.dev archives, fetch SHA-256 checksums from the\ncrates.io sparse registry index, emit `cargo-sources.json`\n  2. Generate `rustup-<version>.json`: downloads the channel manifest,\n`rustup-init` binaries, and a minimal toolchain (rustc, cargo, rust-std) for\nboth `x86_64` and `aarch64`; sets `RUSTUP_DIST_SERVER` to the pre-downloaded\nstatic directory so nothing touches the network at build time\n  3. Insert the `rustup` module before the app module in the generated manifest\n  4. Wire `CARGO_HOME`, `RUSTUP_HOME`, and `PATH` into the app module’s\n`build-options`\n\n\n\nKnown limitation: git-sourced crates (`git+https://...`) are skipped with a\nwarning — they require cloning at generate time, which is out of scope.\nCrates.io dependencies are fully supported.\n\n* * *\n\n## No local Flutter SDK required for `generate` (0.7.0)\n\n`flutpak generate` no longer reads from a local Flutter installation. Engine\nversions (engine binary, Dart SDK, fonts, Gradle wrapper checksums) are fetched\nfrom the GitHub raw API using `flutter.ref`:\n\n\n    flutter:\n      ref: \"3.44.1\" # tag, branch, or commit SHA\n\n\nThe Flutter SDK sources are emitted as a **standalone module**\n(`flutter-sdk-<version>.json`) — separate from `pubspec-sources.json`. Pre-built\nmodule JSONs for recent Flutter releases are cached in the flutpak repo and\nfetched on first use, avoiding regeneration across multiple projects on the same\nSDK version.\n\n* * *\n\n## LLVM SDK extension auto-injected (0.5.0)\n\nThe correct `org.freedesktop.Sdk.Extension.llvmXX` is now selected automatically\nbased on `runtime-version` (25.08 → llvm20, 24.08 → llvm19, 23.08 → llvm17) with\n`append-path` / `prepend-ld-library-path` wired up. No manual extension entry\nneeded.\n\n* * *\n\n## Breaking changes since the original post\n\n\n    # before\n    flutter:\n      sdk: $FLUTTER_ROOT\n      manifest:\n        app-id: io.github.YourOrg.YourApp\n\n    # after (0.8.0)\n    flutter:\n    ref: \"3.29.3\"\n    app-id: io.github.YourOrg.YourApp\n\n\n  * `generated-sources.json` → renamed to `pubspec-sources.json` (update `!include` references)\n  * Flutter SDK sources moved out of `pubspec-sources.json` into a separate module\n  * Re-run `flutpak init --force` after upgrading to 0.8.x to get a clean template\n\n\n\n* * *\n\n## Other notable changes\n\nVersion | Change\n---|---\n0.8.0 | `flutpak cache clear` — wipes `~/.cache/flutpak/`\n0.7.0 | `subdir:` — Flutter project in a monorepo subdirectory\n0.7.0 | `flutpak sdk-mod` — standalone Flutter SDK module JSON for `!include`\n0.6.0 | `patches[].use-git` — `git apply` instead of `patch -p1`\n0.5.0 | `--binary` on every `type: patch` entry — deterministic CRLF handling\n0.5.0 | `.gitattributes` with `*.patch -text` generated by `init`\n0.4.0 | `yaml_edit` injection — `tag:`/`commit:` written directly into the git source block\n0.4.0 | `actions/generate` + `actions/build-flatpak` composite CI actions\n0.4.0 | Retry on 429/5xx for all network fetches\n\n* * *\n\n## Current status\n\nThe core workflow is stable. The demo app (`examples/demo_app/`) builds\nsqlite3 + rhttp end-to-end inside the Flatpak sandbox on both architectures —\nthe CI workflow is a working reference.\nThe most impactful contribution right now: if you maintain or package a Flutter\napp with a native dep not yet in the registry, a PR adding it to\n`foreign_deps/foreign_deps.json` makes it work for everyone. The format is\nidentical to `flatpak-flutter`, so existing entries can be copied directly.",
  "title": "Introducing flutpak - automating Flathub submission for Flutter apps"
}