build: add Flatpak packaging and CI workflow

[lklimek]

Summary

Replace Snap packaging with Flatpak for Linux distribution:

• Remove snap/snapcraft.yaml (226 lines of complex, hard-to-maintain Snap config)
• Add Flatpak build manifest, desktop entry, and AppStream metadata
• Add GitHub Actions workflow for automated Flatpak builds (x86_64 + aarch64)
• Set app_id on ViewportBuilder to match Flatpak/Wayland StartupWMClass
• Update README with Flatpak install/uninstall instructions, rename "Installation" to "Build from Source"
• No application logic changes — app continues to work in SPV mode by default

User Story

Imagine you are a Linux user who wants to try Dash Evo Tool without compiling Rust from source or installing system-wide dependencies. You download a single .flatpak bundle from the GitHub release page, install it with one command, and launch the app from your desktop's application menu. The app runs sandboxed with minimal permissions, stores its configuration inside the Flatpak sandbox automatically, and receives updates the same way. If you ever want to remove it, a single flatpak uninstall cleans everything up.

Changes

File	Purpose
flatpak/org.dash.DashEvoTool.yml	Flatpak build manifest (freedesktop 25.08 runtime, rust-stable + llvm21 SDK extensions)
flatpak/org.dash.DashEvoTool.desktop	Desktop entry for app launchers
flatpak/org.dash.DashEvoTool.metainfo.xml	AppStream metadata for software centers
.github/workflows/flatpak.yml	CI workflow: matrix build (x86_64/aarch64), Cargo + Flatpak caching, release attachment
snap/snapcraft.yaml	Deleted — replaced by Flatpak
src/main.rs	Set with_app_id("org.dash.DashEvoTool") on viewport builder
README.md	Add Flatpak install section, clarify build-from-source prerequisites
.gitignore	Add Flatpak build artifact exclusions

CI workflow details

• Triggers: push to **flatpak** branches, release (published), workflow_dispatch
• Matrix: parallel x86_64 (ubuntu-latest) and aarch64 (ubuntu-24.04-arm) builds
• Cargo caching: Cargo registry and target directories are bind-mounted into the Flatpak build sandbox and cached per architecture, with cleanup of incremental and registry/src artifacts (similar to Swatinem/rust-cache)
• Flatpak caching: .flatpak-builder state cached per arch, keyed on manifest + lockfile
• Concurrency: new push cancels in-progress builds for the same ref
• Security: all GitHub Actions pinned to commit SHAs
• On release: automatically attaches .flatpak bundles to the existing GitHub release
• Artifacts: 14-day retention for build artifacts on non-release triggers

Flatpak sandbox permissions

Follows least-privilege principle:

• --share=ipc — X11 shared memory
• --share=network — blockchain communication
• --socket=wayland + --socket=fallback-x11 — Wayland-first display
• --device=dri — GPU acceleration for egui rendering
• No filesystem access (Flatpak redirects XDG_CONFIG_HOME to sandbox automatically)

Build & install locally

# Build
flatpak-builder --user --force-clean --repo=flatpak-repo build-dir flatpak/org.dash.DashEvoTool.yml

# Bundle
flatpak build-bundle flatpak-repo dash-evo-tool-linux-x86_64.flatpak org.dash.DashEvoTool

# Install
flatpak --user install dash-evo-tool-linux-x86_64.flatpak

Known limitations

• Build requires network access for cargo deps (--share=network in build-args) — cargo vendoring needed for Flathub submission
• protoc module is x86_64-only in manifest; CI patches URL/sha256 for aarch64 via sed
• No screenshots in metainfo yet (required for Flathub listing)

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds Flatpak packaging and CI: new Flatpak manifest, desktop/metainfo, Flatpak build GitHub Actions workflow for x86_64/aarch64, .gitignore updates for Flatpak artifacts, removal of Snap packaging, README install/build changes, and a small runtime change setting egui app_id in src/main.rs.

Changes

Cohort / File(s)	Summary
Flatpak manifests & desktop assets flatpak/org.dash.DashEvoTool.yml, flatpak/org.dash.DashEvoTool.metainfo.xml, flatpak/org.dash.DashEvoTool.desktop	Adds Flatpak YAML manifest (modules: protoc, libsodium, dash-evo-tool), metainfo XML, and desktop entry. Declares runtime/sdk, finish-args, build modules, installs binary and desktop assets to /app/bin and /app/share.
CI: GitHub Actions workflow .github/workflows/flatpak.yml	New "Build Flatpak" workflow with an architecture matrix (x86_64, aarch64): checks out code, installs Flatpak tooling, configures Flathub, installs SDKs/runtimes, patches manifest per-arch (protoc artifact), caches builder state, builds repo, creates .flatpak bundle, uploads artifact, and conditionally attaches to a release.
Removed Snap packaging snap/snapcraft.yaml	Removes Snapcraft manifest and all parts/override-build logic previously used for snap packaging.
Docs / README README.md	Adds "Install via Flatpak (Linux)" and a "Build from Source" section; updates TOC and prerequisites to reflect Flatpak and source-build workflows.
Ignore patterns .gitignore	Adds Flatpak build ignores: *.flatpak, .flatpak-builder/, flatpak-repo/, build-dir/.
Runtime minor change src/main.rs	Sets explicit egui viewport app_id to org.dash.DashEvoTool when starting the UI.

Sequence Diagram(s)

sequenceDiagram
    participant GH as "GitHub Actions"
    participant Runner as "Runner\n(arch-specific)"
    participant Flatpak as "flatpak-builder"
    participant Flathub as "Flathub Remote"
    participant Artifacts as "GitHub Artifacts / Release"

    GH->>Runner: trigger job (push/release, arch matrix)
    Runner->>Runner: checkout repo
    Runner->>Runner: install Flatpak tooling & SDKs
    Runner->>Flathub: add/configure Flathub remote
    Runner->>Runner: patch manifest for target arch (protoc)
    Runner->>Flatpak: build flatpak-repo
    Flatpak->>Runner: produce bundle (.flatpak)
    Runner->>Artifacts: upload artifact
    alt release event
        Runner->>Artifacts: attach bundle to release
    end

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I hopped from snaps into flatpak light,
Manifests, icons, and CI taking flight,
Builders hum and bundles gleam,
Artifacts tucked in a release-stream,
A carrot-powered CI delight 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'build: add Flatpak packaging and CI workflow' clearly and concisely summarizes the main changes: adding Flatpak packaging files and a GitHub Actions CI workflow.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat/flatpak

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🧹 Nitpick comments (3)

.github/workflows/flatpak.yml (1)

55-63: Consider failing fast if there's insufficient disk space after SDK install.

The disk space is printed after cleanup and after SDK install, but only for informational purposes. A Rust + Flatpak build can easily consume 10+ GB. Consider adding a threshold check that fails the job early rather than letting it fail mid-build with a cryptic "no space left on device" error.

Example threshold check

          echo "=== Disk space after SDK install ==="
          df -h
+          AVAIL_GB=$(df --output=avail -BG / | tail -1 | tr -d ' G')
+          if [ "$AVAIL_GB" -lt 10 ]; then
+            echo "::error::Insufficient disk space: ${AVAIL_GB}GB available, need at least 10GB"
+            exit 1
+          fi

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/flatpak.yml around lines 55 - 63, The "Install Flatpak SDK
and runtime" step currently only prints disk usage; add a bash check after the
SDK install that reads the available space (e.g., using df --output=avail -k /
or similar), compares it to a configurable threshold in KB (for example
15_000_000 KB ≈ 15GB), and exits non-zero with a clear error log if available
space is below the threshold so the job fails fast; update the step to emit a
helpful message including the checked mount, available KB, threshold KB, and
exit 1 when insufficient.

flatpak/org.dash.DashEvoTool.yml (1)

40-49: protoc module is x86_64-only — document or guard this.

The prebuilt protoc binary is hardcoded to linux-x86_64. This is noted as a known limitation in the PR, but adding a comment in the manifest would help future maintainers understand the constraint and what to change for aarch64 support.

Add a note

   # Module 1: Install protobuf compiler (required for building dash-sdk)
+  # NOTE: Uses x86_64 binary. For aarch64, replace with protoc-25.2-linux-aarch_64.zip and update sha256.
   - name: protoc

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@flatpak/org.dash.DashEvoTool.yml` around lines 40 - 49, The manifest
currently installs a prebuilt protoc binary that is linux-x86_64-only (see the
module named "protoc" and its build-commands that unzip
protoc-25.2-linux-x86_64.zip); add a clear inline comment in the manifest above
the "name: protoc" entry stating this architecture limitation and what to change
for aarch64 (e.g., use an aarch64 release or build from source), and optionally
add a guard/conditional around the "sources" or "build-commands" (based on
Flatpak variables or an ARCH check) to skip or replace the x86_64 package when
building on aarch64 so maintainers know how to handle non-x86_64 builds.

flatpak/org.dash.DashEvoTool.metainfo.xml (1)

32-34: Keep release metadata in sync with actual releases.

The hardcoded development release entry is fine for now, but this will need to be updated (or automated) when tagging actual releases. AppStream validators expect the latest <release> version to match the distributed version and the date to be accurate.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@flatpak/org.dash.DashEvoTool.metainfo.xml` around lines 32 - 34, The
<releases> block currently contains a hardcoded <release version="1.0.0-dev"
date="2026-02-17" type="development" /> entry which will diverge from actual
distributed versions and fails AppStream validators; update the <release>
element to match the real release version and current date before publishing or
automate population during your release pipeline (e.g., replace the version/date
in org.dash.DashEvoTool.metainfo.xml from the git tag or CI build metadata),
ensuring the latest <release> entry always equals the shipped package version
and accurate release date.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/flatpak.yml:
- Around line 65-67: The workflow step "Build Flatpak" currently uses the flag
--repo=repo which creates a top-level repo/ directory that doesn't match
.gitignore (which ignores flatpak-repo/); update the repo path to a more
specific name (e.g., --repo=flatpak-repo) in the Build Flatpak step of
.github/workflows/flatpak.yml and also update any references/comments in
flatpak/org.dash.DashEvoTool.yml to use the same flatpak-repo name so the
generated directory matches .gitignore, or alternatively add repo/ to .gitignore
if you prefer keeping --repo=repo.

In `@flatpak/org.dash.DashEvoTool.desktop`:
- Line 10: The ViewportBuilder configuration doesn't set an explicit app_id so
the WM_CLASS reported by the window doesn't match the desktop file; update the
ViewportBuilder used to construct the viewport (the viewport field in
src/main.rs where egui::ViewportBuilder::default() is called) to call
with_app_id("org.dash.DashEvoTool") (i.e.
egui::ViewportBuilder::default().with_icon(icon_data).with_app_id("org.dash.DashEvoTool")),
ensuring the app_id matches StartupWMClass in org.dash.DashEvoTool.desktop;
alternatively, if you prefer the opposite approach, change StartupWMClass to
match the actual reported class, but prefer adding with_app_id to
ViewportBuilder.

In `@flatpak/org.dash.DashEvoTool.yml`:
- Line 1: The file header "# Flatpak manifest for Dash Evo Tool" uses CRLF line
endings; convert this YAML to Unix-style LF endings (replace CRLF -> LF) — e.g.,
run dos2unix on the manifest or change your editor's EOL setting and save — then
recommit; optionally add a .gitattributes entry (e.g., for *.yml set text
eol=lf) to prevent future CRLF commits so org.dash.DashEvoTool.yml stays
LF-only.
- Around line 70-71: Update the build command under build-commands to run cargo
with the locked flag so dependency versions are fixed: replace the current
"cargo build --release" invocation with "cargo build --release --locked" in the
YAML entry to ensure reproducible, audited builds.
- Around line 63-69: The skip list in the dir entry (the mapping with "path: .."
and "skip:") is missing the actual output directory name used by CI (repo/);
update the skip array to include "repo" (or "repo/") so the repo output
directory is not copied into the build context, or alternatively rename the
CI/workflow output to match the existing "flatpak-repo" entry — adjust the
"skip" values in that dir block accordingly.

---

Nitpick comments:
In @.github/workflows/flatpak.yml:
- Around line 55-63: The "Install Flatpak SDK and runtime" step currently only
prints disk usage; add a bash check after the SDK install that reads the
available space (e.g., using df --output=avail -k / or similar), compares it to
a configurable threshold in KB (for example 15_000_000 KB ≈ 15GB), and exits
non-zero with a clear error log if available space is below the threshold so the
job fails fast; update the step to emit a helpful message including the checked
mount, available KB, threshold KB, and exit 1 when insufficient.

In `@flatpak/org.dash.DashEvoTool.metainfo.xml`:
- Around line 32-34: The <releases> block currently contains a hardcoded
<release version="1.0.0-dev" date="2026-02-17" type="development" /> entry which
will diverge from actual distributed versions and fails AppStream validators;
update the <release> element to match the real release version and current date
before publishing or automate population during your release pipeline (e.g.,
replace the version/date in org.dash.DashEvoTool.metainfo.xml from the git tag
or CI build metadata), ensuring the latest <release> entry always equals the
shipped package version and accurate release date.

In `@flatpak/org.dash.DashEvoTool.yml`:
- Around line 40-49: The manifest currently installs a prebuilt protoc binary
that is linux-x86_64-only (see the module named "protoc" and its build-commands
that unzip protoc-25.2-linux-x86_64.zip); add a clear inline comment in the
manifest above the "name: protoc" entry stating this architecture limitation and
what to change for aarch64 (e.g., use an aarch64 release or build from source),
and optionally add a guard/conditional around the "sources" or "build-commands"
(based on Flatpak variables or an ARCH check) to skip or replace the x86_64
package when building on aarch64 so maintainers know how to handle non-x86_64
builds.

[coderabbitai]

🧹 Nitpick comments (1)

README.md (1)

39-41: Consider noting the aarch64 bundle and clarifying the install command.

The PR adds both x86_64 and aarch64 Flatpak builds, but only the x86_64 bundle filename is shown here. Also, for users unfamiliar with Flatpak, it may help to note that flatpak install on a local .flatpak file may prompt for the --user flag or require the freedesktop runtime to already be installed.

Suggested improvement

-``` shell
-flatpak install dash-evo-tool-linux-x86_64.flatpak
-```
+``` shell
+# For x86_64:
+flatpak install dash-evo-tool-linux-x86_64.flatpak
+# For aarch64:
+flatpak install dash-evo-tool-linux-aarch64.flatpak
+```
+
+> **Note**: If prompted, allow installation of the required runtime dependencies. You may also use `--user` to install for the current user only.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` around lines 39 - 41, Update the Flatpak install example to
include both bundle filenames and a short note about potential
runtime/permission prompts: add the aarch64 bundle name
dash-evo-tool-linux-aarch64.flatpak alongside dash-evo-tool-linux-x86_64.flatpak
in the code block and append a brief note that users may be prompted to install
runtime dependencies or may need to add the --user flag to install for the
current user only.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@README.md`:
- Around line 39-41: Update the Flatpak install example to include both bundle
filenames and a short note about potential runtime/permission prompts: add the
aarch64 bundle name dash-evo-tool-linux-aarch64.flatpak alongside
dash-evo-tool-linux-x86_64.flatpak in the code block and append a brief note
that users may be prompted to install runtime dependencies or may need to add
the --user flag to install for the current user only.

[coderabbitai]

🧹 Nitpick comments (2)

flatpak/org.dash.DashEvoTool.metainfo.xml (2)

32-34: Development release entry is fine for now; remember to update before stable release.

The 1.0.0-dev development release is appropriate for the current stage. When cutting a stable release, update the version, date, and change type to "stable", and add a <description> with release notes — Flathub validators expect release descriptions for stable releases.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@flatpak/org.dash.DashEvoTool.metainfo.xml` around lines 32 - 34, The current
<release> element uses version="1.0.0-dev" and type="development" which is
correct for now; before cutting a stable release, update the <release> element's
attributes: set version to the stable version string (e.g., "1.0.0"), update the
date to the release date, change type="stable", and add a <description> child
containing the release notes so Flathub validators accept the stable release.

---

1-35: Flathub will require <screenshots> before publishing.

The PR description notes this as a known limitation. Just flagging that appstreamcli validate will emit a warning/error for the missing <screenshots> element, and Flathub submission requires at least one screenshot. Consider adding a placeholder TODO comment or tracking this in an issue.

Would you like me to open an issue to track adding screenshots to the metainfo?

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@flatpak/org.dash.DashEvoTool.metainfo.xml` around lines 1 - 35, The AppStream
metadata is missing the required <screenshots> element which causes appstreamcli
validation warnings and will block Flathub submission; add a <screenshots> block
to the metainfo XML for the component id org.dash.DashEvoTool (e.g., include at
least one <screenshot type="default"> entry pointing to a packaged image or a
placeholder), or if screenshots cannot be provided now, add a clear TODO comment
in the file and create/link an issue tracking adding screenshots for release
version 1.0.0-dev so the missing element is addressed before Flathub submission.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@flatpak/org.dash.DashEvoTool.metainfo.xml`:
- Around line 32-34: The current <release> element uses version="1.0.0-dev" and
type="development" which is correct for now; before cutting a stable release,
update the <release> element's attributes: set version to the stable version
string (e.g., "1.0.0"), update the date to the release date, change
type="stable", and add a <description> child containing the release notes so
Flathub validators accept the stable release.
- Around line 1-35: The AppStream metadata is missing the required <screenshots>
element which causes appstreamcli validation warnings and will block Flathub
submission; add a <screenshots> block to the metainfo XML for the component id
org.dash.DashEvoTool (e.g., include at least one <screenshot type="default">
entry pointing to a packaged image or a placeholder), or if screenshots cannot
be provided now, add a clear TODO comment in the file and create/link an issue
tracking adding screenshots for release version 1.0.0-dev so the missing element
is addressed before Flathub submission.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (3)

.github/workflows/flatpak.yml (2)

34-35: Consider increasing timeout-minutes for cold-cache builds.

A full Rust build (including all dependencies) inside the Flatpak sandbox can easily exceed 20 minutes, especially on aarch64 runners. If the .flatpak-builder cache misses, this timeout may be hit before the build completes. A value of 60–90 minutes would be safer for initial or cache-miss builds.

Suggested change

     runs-on: ${{ matrix.runs-on }}
-    timeout-minutes: 20
+    timeout-minutes: 90

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/flatpak.yml around lines 34 - 35, The workflow's
timeout-minutes setting is too low for cold-cache Rust builds; update the
timeout-minutes value under the job definition (the "timeout-minutes" key) from
20 to a larger value (e.g., 60 or 90) so full Flatpak/Rust builds on
slow/aarch64 runners don't abort on cache misses; modify the timeout-minutes
entry in the .github/workflows/flatpak.yml workflow to the chosen higher value.

---

60-63: Sed-based manifest patching is fragile — consider a templating approach.

If the protoc version, filename, or SHA in the manifest is ever updated, the sed replacements will silently fail to match and the build will use the wrong (x86_64) binary on aarch64. Consider adding a verification step after patching, or using yq / envsubst for more robust substitution.

Add a post-patch verification step

      - name: Verify manifest was patched
        if: matrix.arch != 'x86_64'
        run: |
          grep -q "${{ matrix.protoc-zip }}" flatpak/org.dash.DashEvoTool.yml || \
            { echo "ERROR: manifest was not patched for ${{ matrix.arch }}"; exit 1; }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/flatpak.yml around lines 60 - 63, The current "Patch
manifest for architecture" step uses brittle sed replacements against
flatpak/org.dash.DashEvoTool.yml; replace this with a robust templating or
substitution approach (e.g., use yq or envsubst to set the protoc filename and
sha) and add a post-patch verification to fail the job if the manifest still
contains the old x86_64 filename or SHA; specifically update the step that
references matrix.protoc-zip and matrix.protoc-sha256 to perform structured YAML
substitution and then verify (grep or yq query) that
flatpak/org.dash.DashEvoTool.yml contains ${{ matrix.protoc-zip }} and ${{
matrix.protoc-sha256 }} (exit non‑zero if not) so the build cannot silently
continue with the wrong binary.

README.md (1)

35-61: Clear and well-structured Flatpak installation section.

Instructions cover install, run, and uninstall with architecture-specific commands. The data path note and SPV mode clarification are helpful for users transitioning from native builds.

One small thing: for bundle installs, users may want to pass --user to avoid requiring root permissions:

flatpak install --user dash-evo-tool-linux-x86_64.flatpak

This is optional since flatpak install typically prompts for the installation type.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@README.md` around lines 35 - 61, Update the Flatpak install instructions
under the "## Install via Flatpak (Linux)" section to note the optional --user
flag for bundle installs to avoid requiring root (e.g., mention users can run
flatpak install --user dash-evo-tool-linux-ARCH.flatpak); modify the install
command examples (the x86_64 and aarch64 lines) or add a short sentence after
them clarifying the --user option and that installation type may be prompted by
flatpak.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/flatpak.yml:
- Around line 87-95: The step "Attach bundle to release" uses a step-level
permissions key (permissions: contents: write) which is invalid and causes
uploads to fail; remove the step-level permissions and instead grant write
access at the job level that contains the step (or create a new job, e.g.
"attach-release", with permissions: contents: write that depends on the build
job and downloads artifacts before running the softprops/action-gh-release
step). Locate the step named "Attach bundle to release" and either move the
permissions block up to its job's permissions or implement the separate job that
runs softprops/action-gh-release with job-level permissions set to contents:
write.

---

Nitpick comments:
In @.github/workflows/flatpak.yml:
- Around line 34-35: The workflow's timeout-minutes setting is too low for
cold-cache Rust builds; update the timeout-minutes value under the job
definition (the "timeout-minutes" key) from 20 to a larger value (e.g., 60 or
90) so full Flatpak/Rust builds on slow/aarch64 runners don't abort on cache
misses; modify the timeout-minutes entry in the .github/workflows/flatpak.yml
workflow to the chosen higher value.
- Around line 60-63: The current "Patch manifest for architecture" step uses
brittle sed replacements against flatpak/org.dash.DashEvoTool.yml; replace this
with a robust templating or substitution approach (e.g., use yq or envsubst to
set the protoc filename and sha) and add a post-patch verification to fail the
job if the manifest still contains the old x86_64 filename or SHA; specifically
update the step that references matrix.protoc-zip and matrix.protoc-sha256 to
perform structured YAML substitution and then verify (grep or yq query) that
flatpak/org.dash.DashEvoTool.yml contains ${{ matrix.protoc-zip }} and ${{
matrix.protoc-sha256 }} (exit non‑zero if not) so the build cannot silently
continue with the wrong binary.

In `@README.md`:
- Around line 35-61: Update the Flatpak install instructions under the "##
Install via Flatpak (Linux)" section to note the optional --user flag for bundle
installs to avoid requiring root (e.g., mention users can run flatpak install
--user dash-evo-tool-linux-ARCH.flatpak); modify the install command examples
(the x86_64 and aarch64 lines) or add a short sentence after them clarifying the
--user option and that installation type may be prompted by flatpak.

[PastaPastaPasta]

PR #589 Review: build: add Flatpak packaging and CI workflow

Author: lklimek | Status: All CI checks pass | +307 / -230 lines

Overview

Replaces the existing Snap packaging with Flatpak for Linux distribution. Adds a Flatpak build
manifest, desktop entry, AppStream metadata, a GitHub Actions CI workflow (x86_64 + aarch64), and
minor app changes (with_app_id). Clean removal of the old Snap config.

Strengths

• Well-structured PR — excellent description with rationale, user story, change table, and known
  limitations
• Security best practices — all GitHub Actions pinned to commit SHAs, top-level permissions:
  contents: read with scoped contents: write only on the job that needs it
• Minimal app code change — only with_app_id() added to main.rs, no application logic touched
• Least-privilege Flatpak sandbox — no --filesystem access, Wayland-first with X11 fallback, only
  the permissions actually needed
• Good caching strategy — separate Cargo and Flatpak builder caches keyed by arch + lockfile,
  with incremental/src cleanup before saving
• Concurrency control — cancels in-progress builds for the same ref

Issues & Suggestions

Medium

1. protoc build-commands reference hardcoded x86_64 filename
   (flatpak/org.dash.DashEvoTool.yml:46-48)
   The unzip commands inside build-commands hardcode protoc-25.2-linux-x86_64.zip as the archive
   name. The CI sed step patches the url and sha256 for aarch64, but the build-commands unzip lines
   also reference that filename. This works because flatpak-builder downloads the file and renames
   it, but it's fragile and confusing — worth adding a comment or using a wildcard (protoc-*.zip).
2. timeout-minutes: 20 may be tight for cold cache — The aarch64 build took ~14 minutes (with
   cache). A cold build (new Cargo.lock, no cache) could exceed 20 minutes. Consider bumping to
   30-40 minutes for safety, especially since Rust compile times are unpredictable.
3. contents: write on push branches — The job has contents: write always, but it only needs write
   for the release event (to attach assets). On push/dispatch triggers this is an unnecessary
   permission escalation. Consider:
   permissions:
   contents: ${{ github.event_name == 'release' && 'write' || 'read' }}

Low / Nits

4. Metainfo block is not part of the AppStream spec (metainfo.xml:19-23) —
   in AppStream metainfo.xml is valid, but BlockchainTools is not a standard
   freedesktop category. This won't break anything but could generate warnings from appstreamcli
   validate. Standard alternatives: Finance, Network, Utility.
5. Hardcoded placeholder release in metainfo (metainfo.xml:48) — version="1.0.0-dev"
   date="2026-02-17" is a snapshot. When actual releases happen, this will need to be updated (or
   generated). Consider adding a comment noting this needs to be kept in sync, or automating it in
   CI.
6. --locked in build-commands (org.dash.DashEvoTool.yml:70) — cargo build --release --locked
   requires Cargo.lock to be committed and up-to-date. This is good practice for reproducible
   builds, but make sure Cargo.lock is always committed (it is, based on .gitignore not excluding
   it).
7. Snap deletion removes dash-qt bundling — The old Snap bundled dash-qt (Dash Core wallet
   binary). The new Flatpak does not. This is intentional (SPV mode), but worth confirming that no
   users relied on the snap-bundled dash-qt.
8. No retention-days on artifact upload — The PR description mentions 14-day retention, but the
   workflow doesn't set retention-days on upload-artifact. It will use the org/repo default (which
   may differ). Consider being explicit:
   retention-days: 14

Correctness

• The with_app_id("org.dash.DashEvoTool") in main.rs matches the Flatpak app-id, desktop
  StartupWMClass, and metainfo — all consistent.
• Icon path assets/DET_LOGO.png exists and is referenced correctly.
• The sed for bind-mount injection in CI looks correct but is somewhat brittle. If the YAML
  structure of build-args changes, it could silently fail.

Verdict

This is a well-executed packaging change. The CI workflow is solid and follows security best
practices. The main concern is the permission scope on non-release triggers (#3) and the tight
timeout (#2). The rest are minor polish items. Looks good to merge after considering the medium
items.