commit dc7918ad88a06a122af75ce927d2014d00726d91 Author: kawaiipunk Date: Thu Aug 13 01:04:39 2026 +0200 Add Flatpak packaging for Patchwork 5.4.0 Bundle Poncho Wonky (Patchwork 5.4.0) for x86_64 and aarch64 on the 24.08 freedesktop runtime with the Electron BaseApp. Launcher forces Wayland when a socket is present so the app starts from terminals outside the desktop session. Pinned versions and checksums live in versions.sh and are validated by check-versions.sh. diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..b141328 --- /dev/null +++ b/.gitignore @@ -0,0 +1,4 @@ +.flatpak-builder/ +build-dir/ +repo/ +*.swp diff --git a/Adding Flatpak Support to Patchwork.md b/Adding Flatpak Support to Patchwork.md new file mode 100644 index 0000000..cc586cd --- /dev/null +++ b/Adding Flatpak Support to Patchwork.md @@ -0,0 +1,858 @@ +# Adding Flatpak Support to Patchwork + +*Created: 12/08/2026, 22:15:24* + +--- + +**You** + +how hard is it to add flatpak support to + +https://github.com/soapdog/patchwork + +--- + +**Assistant** + +It’s **moderately easy** to add Flatpak support, but there are a few gotchas because this is an Electron app with native SSB modules and a non-standard packaging setup. + +## What I found about the project + +- It’s an Electron 41 app built with `electron-builder` 26. +- Linux builds already exist: `deb`, `tar.gz`, and `AppImage` for `x64` and `arm64`. +- ASAR is **disabled** because the app relies on Node.js code execution and the maintainer couldn’t get a packaged ASAR to work. +- It already has `.desktop` and AppData files under `assets/`, plus a 512×512 icon. +- It uses many native-ish SSB modules (`ssb-db`, `ssb-blobs`, `secret-stack`, etc.) and GitHub dependency overrides. + +## How hard is Flatpak? + +| Factor | Impact | +|--------|--------| +| Electron base app exists (`org.electronjs.Electron2.BaseApp`) | Easy | +| Native modules / LevelDB / sodium / libsodium | Medium — may need to compile inside the Flatpak or bundle prebuilt binaries | +| ASAR disabled | Medium — Flatpak expects a normal app tree, so this is actually fine, but the app bundle is larger | +| Existing `.desktop` + AppData + icon | Easy | +| Already builds AppImage/tar.gz | Easy — you can reuse the unpackaged build | +| SSB networking (LAN, DHT, pub invites) | Medium — needs `--share=network`, `--device=all` maybe, and careful portal permissions | + +## Two practical approaches + +### 1. Wrap the existing Linux build (easiest) +Build the `tar.gz` or AppImage, then create a Flatpak manifest that extracts it and runs the Electron binary. This avoids rebuilding native modules in the Flatpak SDK. + +```yaml +# nz.scuttlebutt.Patchwork.yaml +app-id: nz.scuttlebutt.Patchwork +runtime: org.freedesktop.Platform +runtime-version: '24.08' +sdk: org.freedesktop.Sdk +base: org.electronjs.Electron2.BaseApp +base-version: '24.08' +command: patchwork +finish-args: + - --share=ipc + - --socket=x11 + - --socket=wayland + - --socket=pulseaudio + - --share=network + - --device=all + - --filesystem=xdg-download + - --talk-name=org.freedesktop.Notifications +modules: + - name: patchwork + buildsystem: simple + sources: + - type: archive + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/Patchwork-5.4.0-linux-x64.tar.gz + sha256: ... + build-commands: + - cp -r . /app/Patchwork + - install -Dm644 assets/nz.scuttlebutt.Patchwork.desktop /app/share/applications/$FLATPAK_ID.desktop + - install -Dm644 assets/nz.scuttlebutt.Patchwork.appdata.xml /app/share/metainfo/$FLATPAK_ID.metainfo.xml + - install -Dm644 build/512x512.png /app/share/icons/hicolor/512x512/apps/$FLATPAK_ID.png + - install -Dm755 patchwork.sh /app/bin/patchwork +``` + +### 2. Build from source inside Flatpak (cleaner, harder) +Use the Node SDK extension and run `npm install` + `npm run dist:linux` inside the Flatpak builder. This is harder because: + +- Native modules may need `node-gyp` and Python headers. +- GitHub tarballs as dependencies sometimes break offline builds. +- The build is slow and may need architecture-specific tweaks. + +## Main challenges + +1. **Native modules** — `ssb-db` and friends likely use LevelDB, `sodium-native`, or `libsodium`. Prebuilt binaries may not match the Flatpak runtime. You may need to ship them or build them. +2. **Sandboxed networking** — SSB uses multicast LAN discovery, DHT, and direct TCP/UDP. `--share=network` covers most, but LAN discovery can be tricky inside Flatpak. +3. **Data directory** — SSB stores its identity and logs in `~/.ssb`. In Flatpak, `HOME` is sandboxed to `~/.var/app/nz.scuttlebutt.Patchwork`. This is usually fine, but users migrating from a non-Flatpak install may need to copy data. +4. **ASAR disabled** — not a blocker, but the Flatpak bundle will be large. + +## Verdict + +If you wrap the existing `tar.gz` release, **a basic Flatpak can be done in a few hours**. Making it Flathub-ready and fully sandboxed with proper portals may take a day or two, mostly around testing native modules and network permissions. Building from source inside Flatpak is more involved and could take several days if native dependencies misbehave. + +If you want, I can write a complete `flatpak-builder` manifest and a build script for the release-wrapper approach. + +--- + +**You** + +do it + +--- + +**Assistant** + +
Thinking + +The user wants a complete Flatpak manifest and build script. I have enough info now: + +- Product name is "ponchowonky" in package.json, but the app-id is nz.scuttlebutt.Patchwork +- Version 5.4.0 +- Linux assets are AppImage only (no tar.gz) +- Desktop and AppData files exist +- Icon is assets/icon.png or assets/512x512.png + +Since only AppImage is available, I need to extract the AppImage. AppImages are ISO 9660 images with a squashfs or iso9660 payload. The standard way to extract an AppImage is: +- `./Patchwork.AppImage --appimage-extract` (but this requires FUSE which may not work in Flatpak builder) +- Or use `appimagetool` / `unsquashfs` + +Actually, the easiest way in a Flatpak manifest is to use the `type: file` or `type: archive` and extract with `unsquashfs` or use the AppImage's own extraction. + +Wait, AppImages can be extracted by running them with `--appimage-extract` but they need to be executable and may need libfuse. In Flatpak builder, we can use `unsquashfs` if the AppImage uses squashfs. + +Modern AppImages (type 2) use squashfs. We can extract with: +``` +chmod +x *.AppImage +./ponchowonky-5.4.0-linux-x86_64.AppImage --appimage-extract +``` + +But this might fail without FUSE. However, `--appimage-extract` doesn't use FUSE, it extracts directly. + +Alternatively, we can mount it or use `unsquashfs`. + +Let me create a robust manifest that: +1. Downloads the AppImage +2. Extracts it +3. Installs the desktop, appdata, and icon +4. Creates a wrapper script + +I should also provide a build script and instructions. + +Let me also check the desktop file content. The librarian had a parsing error on the desktop file. Let me try to get it via text_editor or just assume it has the standard fields. Actually, I can use the raw URL directly. + +Wait, I have the appdata content. It uses `nz.scuttlebutt.Patchwork.desktop` and `assets/icon.png`. The desktop file likely has `Exec=ponchowonky` or similar. + +Since I can't read the desktop file easily, I'll create a Flatpak manifest that renames the installed desktop file to match the app-id, and I'll create a wrapper script. + +Actually, the AppImage itself contains the desktop file and icon. When we extract the AppImage, we get a `squashfs-root` directory with the app. The electron-builder AppImage typically contains: +- `usr/bin/ponchowonky` (the actual binary) +- `usr/share/applications/ponchowonky.desktop` +- `usr/share/icons/...` +- `AppRun` + +But it's easier to just run the extracted AppImage's AppRun or the electron binary directly. + +For Flatpak, the best approach is: +1. Extract AppImage +2. Copy contents to /app +3. Create launcher script + +Let me write this. I'll create: +- `nz.scuttlebutt.Patchwork.yaml` - the manifest +- `build.sh` - helper script +- `README.md` - instructions + +I need to handle both x86_64 and arm64. Flatpak manifests can use `only-arches` for sources. + +For the AppImage extraction, I'll use the `--appimage-extract` method. This is reliable in the build environment. + +Let me draft the manifest: + +```yaml +app-id: nz.scuttlebutt.Patchwork +runtime: org.freedesktop.Platform +runtime-version: '24.08' +sdk: org.freedesktop.Sdk +base: org.electronjs.Electron2.BaseApp +base-version: '24.08' +command: patchwork +finish-args: + - --share=ipc + - --socket=x11 + - --socket=wayland + - --socket=pulseaudio + - --share=network + - --device=all + - --filesystem=xdg-download + - --talk-name=org.freedesktop.Notifications + - --own-name=org.kde.* # for tray? Maybe not needed +modules: + - name: patchwork + buildsystem: simple + build-commands: + - chmod +x ponchowonky-*.AppImage + - ./ponchowonky-5.4.0-linux-x86_64.AppImage --appimage-extract || ./ponchowonky-5.4.0-linux-arm64.AppImage --appimage-extract + - mv squashfs-root /app/Patchwork + - install -Dm755 patchwork.sh /app/bin/patchwork + - install -Dm644 /app/Patchwork/usr/share/applications/ponchowonky.desktop /app/share/applications/nz.scuttlebutt.Patchwork.desktop + - desktop-file-edit --set-key=Exec --set-value=patchwork /app/share/applications/nz.scuttlebutt.Patchwork.desktop + - install -Dm644 assets/nz.scuttlebutt.Patchwork.appdata.xml /app/share/metainfo/nz.scuttlebutt.Patchwork.metainfo.xml + - install -Dm644 /app/Patchwork/usr/share/icons/hicolor/512x512/apps/ponchowonky.png /app/share/icons/hicolor/512x512/apps/nz.scuttlebutt.Patchwork.png + sources: + - type: file + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-x86_64.AppImage + sha256: TBD + only-arches: [x86_64] + - type: file + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-arm64.AppImage + sha256: TBD + only-arches: [aarch64] + - type: file + path: patchwork.sh + - type: file + path: assets/nz.scuttlebutt.Patchwork.appdata.xml +``` + +Wait, the appdata file from the repo references old URLs and may need updating for Flathub. But for local builds it's fine. + +The wrapper script: +```bash +#!/bin/sh +exec /app/Patchwork/AppRun "$@" +``` + +Or better, run the electron binary directly: +```bash +#!/bin/sh +exec /app/Patchwork/ponchowonky "$@" +``` + +Actually, AppRun sets up environment variables. It's better to use AppRun. + +But AppRun might try to do AppImage-specific things. Let me check what electron-builder AppImage AppRun does. It typically sets up the environment and execs the electron binary. It should work fine. + +Actually, a safer approach is to run the electron binary directly: +```bash +#!/bin/sh +exec /app/Patchwork/ponchowonky --no-sandbox "$@" +``` + +But `--no-sandbox` is needed because Flatpak's sandbox doesn't allow Chromium's setuid sandbox. However, Electron in Flatpak usually uses the zypak helper from the BaseApp to handle the sandbox. The BaseApp provides `zypak` which rewrites the sandbox. + +With `org.electronjs.Electron2.BaseApp`, we should use `zypak` to launch the app. The standard wrapper is: + +```bash +#!/bin/sh +exec zypak-wrapper /app/Patchwork/ponchowonky "$@" +``` + +But wait, the extracted AppImage might have its own Chromium sandbox binary. The BaseApp's `zypak-wrapper` handles this. + +Actually, the modern approach for Electron Flatpak is to use `zypak-wrapper` from the BaseApp. Let me use that. + +Hmm, but the AppImage already contains a bundled Electron. The `zypak-wrapper` will intercept the sandbox launch. + +Let me also consider that the extracted AppImage binary might be called `ponchowonky` (matching productName). The path would be `/app/Patchwork/ponchowonky` or `/app/Patchwork/usr/bin/ponchowonky`. + +In electron-builder AppImages, the main binary is at the root of squashfs-root, named after the productName. There's also a `usr/bin/` structure. + +Let me write the manifest to be robust. + +Actually, I should note that I don't have the exact sha256 hashes or the desktop file contents. I'll put `TBD` or `REPLACE_ME` placeholders and instruct the user to compute them. + +Also, I should update the AppData file to be Flathub-compliant. The existing one has some issues: +- It uses old screenshot URLs from ssbc/patchwork +- It might lack release info +- It might have content rating issues + +For Flathub, the appdata should: +- Have proper `` section +- Use `` instead of `` (newer spec) +- Have OARS content rating +- Have valid screenshots + +But the user just asked for Flatpak support, not necessarily Flathub. I'll provide a manifest that works locally and can be adapted for Flathub. + +Let me also check if the project has a 512x512 icon. The appdata mentions `assets/icon.png`. The repo tree mentioned `assets/512x512.png`. I'll use the icon from the extracted AppImage. + +Let me create the files now. I'll provide them in a code block as a complete deliverable. + +Actually, I should also create a `flathub.json` if needed. For Flathub, Electron apps often need: +```json +{ + "only-arches": ["x86_64", "aarch64"] +} +``` + +But that's optional. + +Let me also think about permissions. SSB needs: +- Network (obviously) +- Maybe raw sockets? No, just TCP/UDP +- LAN discovery uses multicast UDP. This works with `--share=network`. +- File system access for downloads and maybe importing media. `xdg-download` is enough for downloads. For importing, users might need more, but we can use portals. + +I think `--share=network`, `--device=all` (for webcam? not sure if Patchwork uses it), `--socket=x11`, `--socket=wayland`, `--socket=pulseaudio`, `--filesystem=xdg-download` are sufficient. + +Actually, `--device=all` might be needed for camera if Patchwork supports image capture. But it's probably not needed. I'll include it as optional comment. + +Also, SSB stores data in `~/.ssb`. In Flatpak, this becomes `~/.var/app/nz.scuttlebutt.Patchwork/.ssb` automatically because HOME is set to that directory. No extra permission needed. + +Let me write the complete deliverable now. + +One more thing: the AppImage extraction. The `--appimage-extract` flag is built into the AppImage runtime. It extracts to `squashfs-root/`. This works without FUSE. + +But there's a catch: AppImages have a magic bytes offset. The first few bytes are the ELF runtime. The `--appimage-extract` option is parsed by the runtime. So running `./AppImage --appimage-extract` should work. + +However, in some build environments, the AppImage might not be executable or might need specific libraries. But since it's a self-contained runtime, it usually works. + +Alternative: use `unsquashfs` directly. But finding the offset is tricky. `--appimage-extract` is easier. + +I'll write the build commands to extract the AppImage for the current architecture. + +Wait, with `only-arches`, only one AppImage file will be downloaded. So I can do: +```bash +./ponchowonky-5.4.0-linux-$(uname -m).AppImage --appimage-extract +``` + +But `uname -m` returns `x86_64` or `aarch64`. The AppImage names use `x86_64` and `arm64`. So I need to map: +- x86_64 -> x86_64 +- aarch64 -> arm64 + +I can do: +```bash +case "$(uname -m)" in + x86_64) ARCH=x86_64 ;; + aarch64) ARCH=arm64 ;; +esac +./ponchowonky-5.4.0-linux-${ARCH}.AppImage --appimage-extract +``` + +This is robust. + +Now, the extracted directory is `squashfs-root`. Inside, there should be: +- `AppRun` - the launcher script +- `ponchowonky` - the main binary (symlink or actual) +- `.DirIcon` - icon +- `usr/share/` - desktop and icons + +I'll copy the whole thing to `/app/Patchwork`. + +Then create the launcher: +```bash +#!/bin/sh +exec zypak-wrapper /app/Patchwork/AppRun "$@" +``` + +Wait, AppRun might do things that conflict with Flatpak. Let me think. AppRun from electron-builder typically: +1. Sets `APPIMAGE`, `APPDIR`, `OWD` environment variables +2. Sets `LD_LIBRARY_PATH` to include bundled libs +3. Execs the main binary + +In Flatpak, we don't want `LD_LIBRARY_PATH` to override system libs. But the bundled libs are needed for the app. The AppRun script is specific to the AppImage. It might work, but could cause issues. + +Better approach: bypass AppRun and run the electron binary directly with zypak-wrapper. + +The electron binary in the extracted AppImage is typically at: +- `squashfs-root/ponchowonky` (which is a shell script wrapper that sets up and runs the actual electron) +- or `squashfs-root/usr/bin/ponchowonky` + +Actually, electron-builder creates a wrapper script at the root named after the product. This script sets up the environment and runs the electron binary from `usr/lib/ponchowonky/`. + +Let me just use the root `ponchowonky` script with `zypak-wrapper`. But the script might set `ELECTRON_DISABLE_SANDBOX` or other things. + +Actually, the safest for Flatpak is: +```bash +#!/bin/sh +exec zypak-wrapper /app/Patchwork/ponchowonky "$@" +``` + +But we need to make sure the script is executable and works in the Flatpak environment. + +Alternatively, some Electron Flatpak manifests just run: +```bash +#!/bin/sh +exec /app/Patchwork/ponchowonky --no-sandbox "$@" +``` + +But `--no-sandbox` disables Chromium sandbox entirely, which is less secure. Using `zypak-wrapper` is better. + +I'll provide the `zypak-wrapper` approach and mention `--no-sandbox` as a fallback. + +Now, the desktop file. The extracted AppImage has `usr/share/applications/ponchowonky.desktop`. I need to rename it to `nz.scuttlebutt.Patchwork.desktop` and update the Exec line. The `desktop-file-edit` tool is available in the SDK. + +The icon in the desktop file should also be updated to `nz.scuttlebutt.Patchwork`. + +For the icon, I'll copy from the extracted AppImage's icon directory. + +Let me also think about the AppData. The existing one references `nz.scuttlebutt.Patchwork.desktop` and old URLs. I should create an updated version for the Flatpak. But I can also just use the existing one and patch it. + +Actually, I'll provide a patched `nz.scuttlebutt.Patchwork.metainfo.xml` file that is Flathub-ready. This is more useful. + +Let me write the complete set of files. + +Files to provide: +1. `nz.scuttlebutt.Patchwork.yaml` - manifest +2. `patchwork.sh` - launcher wrapper +3. `nz.scuttlebutt.Patchwork.metainfo.xml` - updated appdata +4. `build.sh` - build helper +5. `README.md` - instructions + +I'll put them all in one code block with file paths, or separate blocks. The user said "Provide code in one block whenever possible" but with multiple files, I think separate blocks with file paths are clearer. Or I can use a single markdown block with file separators. + +Actually, I'll provide them as separate code blocks with file names, which is standard. + +Let me also include the sha256 computation command in the README. + +One issue: the AppImage download URLs. I have them from the API: +- x86_64: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-x86_64.AppImage +- arm64: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-arm64.AppImage + +I'll use these. + +For the icon, I'll use the one from the AppImage. But I don't know the exact path. electron-builder typically installs icons at: +- `usr/share/icons/hicolor/512x512/apps/ponchowonky.png` +- or `usr/share/icons/hicolor/0x0/apps/ponchowonky.png` + +I'll use a wildcard or check both. Actually, I can use: +```bash +find /app/Patchwork/usr/share/icons -name "*.png" -exec install -Dm644 {} /app/share/icons/hicolor/512x512/apps/nz.scuttlebutt.Patchwork.png \; +``` + +But this might not preserve the hicolor structure. Better: +```bash +cp -r /app/Patchwork/usr/share/icons/hicolor/* /app/share/icons/hicolor/ +``` + +Then rename the icon file. But the icon names are `ponchowonky.png`. I need to rename to `nz.scuttlebutt.Patchwork.png`. + +Actually, the desktop file's Icon key should match the installed icon name. So I'll: +1. Copy all hicolor icons to `/app/share/icons/hicolor/` +2. Rename the 512x512 one to `nz.scuttlebutt.Patchwork.png` +3. Set the desktop file Icon to `nz.scuttlebutt.Patchwork` + +But what if the AppImage only has a 0x0 icon? electron-builder sometimes puts the icon in `0x0` directory. Let me handle that: +```bash +for size in 0x0 16x16 32x32 48x48 128x128 256x256 512x512; do + if [ -f "/app/Patchwork/usr/share/icons/hicolor/${size}/apps/ponchowonky.png" ]; then + install -Dm644 "/app/Patchwork/usr/share/icons/hicolor/${size}/apps/ponchowonky.png" \ + "/app/share/icons/hicolor/${size}/apps/nz.scuttlebutt.Patchwork.png" + fi +done +``` + +This is robust. + +For the desktop file, I need to find it: +```bash +install -Dm644 /app/Patchwork/usr/share/applications/ponchowonky.desktop /app/share/applications/nz.scuttlebutt.Patchwork.desktop +desktop-file-edit --set-key=Exec --set-value=patchwork /app/share/applications/nz.scuttlebutt.Patchwork.desktop +desktop-file-edit --set-key=Icon --set-value=nz.scuttlebutt.Patchwork /app/share/applications/nz.scuttlebutt.Patchwork.desktop +desktop-file-edit --set-key=StartupWMClass --set-value=Ponchowonky /app/share/applications/nz.scuttlebutt.Patchwork.desktop +``` + +Wait, the WMClass might be `Ponchowonky` (productName capitalized). I should set it correctly. Actually, the desktop file from the AppImage already has the correct WMClass. I should only change Exec and Icon, and maybe Name. But the app-id is different from the product name. + +Actually, for Flatpak, the desktop file name must match the app-id. The Name can stay "Patchwork" or "Ponchowonky". The user might want it to be "Patchwork". I'll leave the original Name but update Exec and Icon. + +Now, the metainfo file. I'll create a Flathub-compliant one. + +Let me think about the content rating. Patchwork is a social network. It might have: +- Social: intense (user-generated content) +- No violence, etc. + +I'll use the OARS 1.1 content rating. + +For releases, I'll add the current version. + +Screenshots: I'll use the existing screenshot URL from the repo, but note it might be broken. Actually, for Flathub, screenshots must be hosted on a reliable CDN. The existing one uses raw.githubusercontent.com which is not ideal. But for local builds, it's fine. + +I'll provide a metainfo file and note that screenshots should be updated for Flathub. + +Now, let me write the actual files. + +Wait, I should also consider that the app-id `nz.scuttlebutt.Patchwork` needs to be controlled by the project. If soapdog doesn't own `scuttlebutt.nz`, this might be a problem for Flathub. But the existing appdata already uses this ID, so I'll keep it. + +Let me also think about the build environment. The user will run: +```bash +flatpak-builder --repo=repo build-dir nz.scuttlebutt.Patchwork.yaml +``` + +They need to install the runtime and base app first: +```bash +flatpak install flathub org.freedesktop.Platform//24.08 org.freedesktop.Sdk//24.08 org.electronjs.Electron2.BaseApp//24.08 +``` + +I'll include this in the README. + +Now, let me also consider if we should build from source instead. The user asked "do it" after I said wrapping the release is easiest. So I'll provide the release-wrapper approach. + +But I should also mention that building from source is an alternative if they want a fully open-source Flatpak. + +OK, let me write the deliverable. + +One more thing: the AppImage extraction might fail in the Flatpak builder if the AppImage runtime needs specific libraries. To make it more robust, I can use `unsquashfs` from the SDK. The SDK includes `squashfs-tools`. + +Let me use `unsquashfs` approach. But I need to find the squashfs offset. The AppImage type 2 has the offset at a specific location. There's a tool `appimage-extract` or I can parse the ELF header. + +Actually, the simplest is still `--appimage-extract`. If that fails, we can fall back. + +Let me check: AppImage type 2 uses a static runtime that doesn't need external libs. It should work in any Linux environment. So `--appimage-extract` is fine. + +I'll use: +```bash +chmod +x ponchowonky-*.AppImage +./ponchowonky-5.4.0-linux-${ARCH}.AppImage --appimage-extract +``` + +This extracts to `squashfs-root/`. + +OK, let me write the files now. + +Actually, I realize I should verify the exact binary name inside the AppImage. Since I don't have access to the AppImage contents, I'll make the wrapper script flexible. It can try multiple paths: + +```bash +#!/bin/sh +set -e + +if [ -x /app/Patchwork/ponchowonky ]; then + BIN=/app/Patchwork/ponchowonky +elif [ -x /app/Patchwork/usr/bin/ponchowonky ]; then + BIN=/app/Patchwork/usr/bin/ponchowonky +else + echo "Patchwork binary not found" >&2 + exit 1 +fi + +exec zypak-wrapper "$BIN" "$@" +``` + +This is robust. + +Now, the manifest. I'll write it carefully. + +For the metainfo, I need to make sure it's valid. Let me draft: + +```xml + + + nz.scuttlebutt.Patchwork + nz.scuttlebutt.Patchwork.desktop + CC0-1.0 + AGPL-3.0 + Patchwork + A decentralized messaging and sharing app + +

Patchwork is a decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB).

+ + + + Network chat feed + https://raw.githubusercontent.com/soapdog/patchwork/master/screenshot.jpg + + + https://www.scuttlebutt.nz/ + https://github.com/soapdog/patchwork/issues + + Secure Scuttlebutt Consortium + + + intense + intense + intense + + + + + +``` + +Wait, the current date is 2026-08-12. The release date might not be today. I should use a placeholder or the actual release date. Since I don't know the exact release date of v5.4.0, I'll use a placeholder `YYYY-MM-DD` and tell the user to update it. + +Actually, I can look it up but I've reached max research iterations. I'll use a placeholder. + +For the README, I'll include: +1. Prerequisites +2. How to compute sha256 +3. Build command +4. Install command +5. Testing +6. Notes on permissions and data migration +7. Flathub submission notes + +Let me also create a `build.sh` that computes sha256 and runs flatpak-builder. But computing sha256 requires downloading the files first. The user can do: + +```bash +wget https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-x86_64.AppImage +sha256sum ponchowonky-5.4.0-linux-x86_64.AppImage +``` + +I'll provide this in the README. + +Actually, flatpak-builder can download and verify. The user just needs to put the correct sha256 in the manifest. + +OK, I think I have everything. Let me write the final response. + +I should also note that this is a release-wrapper Flatpak, not built from source. And it uses the AppImage because that's what the releases provide. + +Let me write the response with minimal explanation as requested. + +One more consideration: the product name in package.json is "ponchowonky" but the app is known as Patchwork. The AppImage is named `ponchowonky-...`. The desktop file and icons will use `ponchowonky`. I need to handle this naming mismatch in the manifest. + +OK, writing now. + +
+ +Here is a complete release-wrapper Flatpak setup. It extracts the upstream AppImage because that is what the project currently ships. + +## Files + +```yaml +# nz.scuttlebutt.Patchwork.yaml +app-id: nz.scuttlebutt.Patchwork +runtime: org.freedesktop.Platform +runtime-version: '24.08' +sdk: org.freedesktop.Sdk +base: org.electronjs.Electron2.BaseApp +base-version: '24.08' +command: patchwork + +finish-args: + - --share=ipc + - --socket=x11 + - --socket=wayland + - --socket=pulseaudio + - --share=network + - --device=all + - --filesystem=xdg-download + - --talk-name=org.freedesktop.Notifications + +modules: + - name: patchwork + buildsystem: simple + build-commands: + - | + case "$(uname -m)" in + x86_64) ARCH=x86_64 ;; + aarch64) ARCH=arm64 ;; + *) echo "Unsupported architecture: $(uname -m)" >&2; exit 1 ;; + esac + chmod +x "ponchowonky-5.4.0-linux-${ARCH}.AppImage" + "./ponchowonky-5.4.0-linux-${ARCH}.AppImage" --appimage-extract + - mv squashfs-root /app/Patchwork + - install -Dm755 patchwork.sh /app/bin/patchwork + - | + install -Dm644 /app/Patchwork/usr/share/applications/ponchowonky.desktop \ + /app/share/applications/nz.scuttlebutt.Patchwork.desktop + desktop-file-edit --set-key=Exec --set-value=patchwork \ + /app/share/applications/nz.scuttlebutt.Patchwork.desktop + desktop-file-edit --set-key=Icon --set-value=nz.scuttlebutt.Patchwork \ + /app/share/applications/nz.scuttlebutt.Patchwork.desktop + - | + for size in 0x0 16x16 24x24 32x32 48x48 64x64 128x128 256x256 512x512; do + src="/app/Patchwork/usr/share/icons/hicolor/${size}/apps/ponchowonky.png" + if [ -f "$src" ]; then + install -Dm644 "$src" \ + "/app/share/icons/hicolor/${size}/apps/nz.scuttlebutt.Patchwork.png" + fi + done + - install -Dm644 nz.scuttlebutt.Patchwork.metainfo.xml \ + /app/share/metainfo/nz.scuttlebutt.Patchwork.metainfo.xml + sources: + - type: file + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-x86_64.AppImage + sha256: REPLACE_WITH_SHA256_X86_64 + only-arches: [x86_64] + - type: file + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-arm64.AppImage + sha256: REPLACE_WITH_SHA256_ARM64 + only-arches: [aarch64] + - type: file + path: patchwork.sh + - type: file + path: nz.scuttlebutt.Patchwork.metainfo.xml +``` + +```bash +#!/bin/sh +# patchwork.sh +set -e + +if [ -x /app/Patchwork/ponchowonky ]; then + BIN=/app/Patchwork/ponchowonky +elif [ -x /app/Patchwork/usr/bin/ponchowonky ]; then + BIN=/app/Patchwork/usr/bin/ponchowonky +else + echo "Patchwork binary not found" >&2 + exit 1 +fi + +exec zypak-wrapper "$BIN" "$@" +``` + +```xml + + + + nz.scuttlebutt.Patchwork + nz.scuttlebutt.Patchwork.desktop + CC0-1.0 + AGPL-3.0 + Patchwork + A decentralized messaging and sharing app + +

Patchwork is a decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB).

+ + + + Network chat feed + https://raw.githubusercontent.com/soapdog/patchwork/master/screenshot.jpg + + + https://www.scuttlebutt.nz/ + https://github.com/soapdog/patchwork/issues + + Secure Scuttlebutt Consortium + + + intense + intense + intense + + + + + +``` + +```bash +#!/bin/bash +# build.sh +set -e + +# 1. Install dependencies +flatpak install -y flathub \ + org.freedesktop.Platform//24.08 \ + org.freedesktop.Sdk//24.08 \ + org.electronjs.Electron2.BaseApp//24.08 + +# 2. Compute SHA256 for the AppImages and update the manifest +for arch in x86_64 arm64; do + url="https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-linux-${arch}.AppImage" + file="ponchowonky-5.4.0-linux-${arch}.AppImage" + if [ ! -f "$file" ]; then + wget -q --show-progress "$url" -O "$file" + fi + sha=$(sha256sum "$file" | cut -d' ' -f1) + echo "${arch}: ${sha}" +done + +echo "Paste the SHA256 values into nz.scuttlebutt.Patchwork.yaml, then run:" +echo " flatpak-builder --repo=repo --force-clean build-dir nz.scuttlebutt.Patchwork.yaml" +``` + +## Build and install + +```bash +# 1. Fill in the SHA256 placeholders in the manifest, or run: +./build.sh + +# 2. Build +flatpak-builder --repo=repo --force-clean build-dir nz.scuttlebutt.Patchwork.yaml + +# 3. Install locally +flatpak --user remote-add --no-gpg-verify patchwork-repo repo +flatpak --user install -y patchwork-repo nz.scuttlebutt.Patchwork + +# 4. Run +flatpak run nz.scuttlebutt.Patchwork +``` + +## Important notes + +- Update the `` in the metainfo file with the actual v5.4.0 release date. +- The AppImage is named `ponchowonky` but the public name and app-id stay `Patchwork`. The manifest renames the desktop entry and icons accordingly. +- SSB data lives in `~/.var/app/nz.scuttlebutt.Patchwork/.ssb` inside the Flatpak sandbox. Users migrating from a non-Flatpak install must copy that directory manually. +- For Flathub, replace the screenshot URL with images hosted on a stable CDN and ensure the `nz.scuttlebutt.Patchwork` app-id is controlled by the project. + +--- + +**You** + +Is it best to have a separate repo for the flatpak or in the main repo + +--- + +**Assistant** + +
Thinking + +The user is asking for advice on whether to keep the Flatpak manifest in a separate repository or in the main Patchwork repo. This is a general software packaging/Flathub convention question. I should provide reasoning based on common practices, especially for Flathub submissions. + +Key points to consider: +1. Flathub's preference - they typically prefer a separate repo under flathub/org.example.App +2. Maintenance burden - keeping it in main repo means releases can update manifest together +3. CI/CD integration +4. Build from source vs wrapping release +5. Flathub external data checker +6. AppData/desktop files location + +This is an established concept/opinion discussion, no need for web search. But I should be thorough and give practical recommendation. + +Let me think about the best answer: +- For Flathub submission: separate repo is standard (flathub/flathub repo PR creates a new repo under flathub org) +- For project-owned distribution: in main repo can work +- For release-wrapper approach: separate repo is cleaner because the manifest references external binaries +- For build-from-source: in main repo makes more sense + +Given this is a wrapper approach, separate repo is probably better. But I should explain both options. + +Let me structure the answer with a clear recommendation and tradeoffs table. + +
+ +For your **release-wrapper approach**, a **separate repo is usually better**. Here is the tradeoff. + +## Recommendation + +| Approach | Best repo location | Why | +|----------|-------------------|-----| +| Release wrapper (what I gave you) | **Separate repo** | The manifest downloads upstream binaries. Keeping it separate avoids polluting the main repo with packaging-only files and matches Flathub expectations. | +| Build from source inside Flatpak | **Main repo** | The manifest needs the source tree, tags, and CI. It is easier to maintain alongside the app. | + +## Why a separate repo is better for wrappers + +- **Flathub expects it.** When you submit to Flathub, they create a repo like `flathub/nz.scuttlebutt.Patchwork` from your PR. Having your own `patchwork-flatpak` repo already structured makes that PR trivial. +- **Different release cadence.** The Flatpak only needs updating when a new upstream AppImage is released, not on every commit. +- **No main-repo noise.** Files like `nz.scuttlebutt.Patchwork.yaml`, `patchwork.sh`, and metainfo do not help developers working on Patchwork itself. +- **External data checker.** Flathub bots can watch the upstream release URL and auto-open PRs to bump the version/SHA256. That works cleanly in a dedicated repo. + +## When the main repo makes sense + +- You want the Flatpak built automatically on every CI run. +- You are building from source, not wrapping a release. +- You want `flatpak-builder` to use the current checkout directly. + +## Suggested layout + +``` +patchwork-flatpak/ # or flathub manifest repo +├── nz.scuttlebutt.Patchwork.yaml +├── nz.scuttlebutt.Patchwork.metainfo.xml +├── patchwork.sh +├── flathub.json # optional: skip-arches, etc. +└── README.md +``` + +## Practical workflow + +1. Create `soapdog/patchwork-flatpak` or similar. +2. On each upstream release, update the URL, SHA256, and `` in metainfo. +3. Submit to Flathub from that repo. +4. Optionally add a GitHub Action in the main repo that opens a PR in the Flatpak repo when a release is published. + +**Bottom line:** use a separate repo. It is the standard pattern for Flathub and keeps the main repo clean. + +--- + diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..0e259d4 --- /dev/null +++ b/LICENSE @@ -0,0 +1,121 @@ +Creative Commons Legal Code + +CC0 1.0 Universal + + CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE + LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN + ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS + INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES + REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS + PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM + THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED + HEREUNDER. + +Statement of Purpose + +The laws of most jurisdictions throughout the world automatically confer +exclusive Copyright and Related Rights (defined below) upon the creator +and subsequent owner(s) (each and all, an "owner") of an original work of +authorship and/or a database (each, a "Work"). + +Certain owners wish to permanently relinquish those rights to a Work for +the purpose of contributing to a commons of creative, cultural and +scientific works ("Commons") that the public can reliably and without fear +of later claims of infringement build upon, modify, incorporate in other +works, reuse and redistribute as freely as possible in any form whatsoever +and for any purposes, including without limitation commercial purposes. +These owners may contribute to the Commons to promote the ideal of a free +culture and the further production of creative, cultural and scientific +works, or to gain reputation or greater distribution for their Work in +part through the use and efforts of others. + +For these and/or other purposes and motivations, and without any +expectation of additional consideration or compensation, the person +associating CC0 with a Work (the "Affirmer"), to the extent that he or she +is an owner of Copyright and Related Rights in the Work, voluntarily +elects to apply CC0 to the Work and publicly distribute the Work under its +terms, with knowledge of his or her Copyright and Related Rights in the +Work and the meaning and intended legal effect of CC0 on those rights. + +1. Copyright and Related Rights. A Work made available under CC0 may be +protected by copyright and related or neighboring rights ("Copyright and +Related Rights"). Copyright and Related Rights include, but are not +limited to, the following: + + i. the right to reproduce, adapt, distribute, perform, display, + communicate, and translate a Work; + ii. moral rights retained by the original author(s) and/or performer(s); +iii. publicity and privacy rights pertaining to a person's image or + likeness depicted in a Work; + iv. rights protecting against unfair competition in regards to a Work, + subject to the limitations in paragraph 4(a), below; + v. rights protecting the extraction, dissemination, use and reuse of data + in a Work; + vi. database rights (such as those arising under Directive 96/9/EC of the + European Parliament and of the Council of 11 March 1996 on the legal + protection of databases, and under any national implementation + thereof, including any amended or successor version of such + directive); and +vii. other similar, equivalent or corresponding rights throughout the + world based on applicable law or treaty, and any national + implementations thereof. + +2. Waiver. To the greatest extent permitted by, but not in contravention +of, applicable law, Affirmer hereby overtly, fully, permanently, +irrevocably and unconditionally waives, abandons, and surrenders all of +Affirmer's Copyright and Related Rights and associated claims and causes +of action, whether now known or unknown (including existing as well as +future claims and causes of action), in the Work (i) in all territories +worldwide, (ii) for the maximum duration provided by applicable law or +treaty (including future time extensions), (iii) in any current or future +medium and for any number of copies, and (iv) for any purpose whatsoever, +including without limitation commercial, advertising or promotional +purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each +member of the public at large and to the detriment of Affirmer's heirs and +successors, fully intending that such Waiver shall not be subject to +revocation, rescission, cancellation, termination, or any other legal or +equitable action to disrupt the quiet enjoyment of the Work by the public +as contemplated by Affirmer's express Statement of Purpose. + +3. Public License Fallback. Should any part of the Waiver for any reason +be judged legally invalid or ineffective under applicable law, then the +Waiver shall be preserved to the maximum extent permitted taking into +account Affirmer's express Statement of Purpose. In addition, to the +extent the Waiver is so judged Affirmer hereby grants to each affected +person a royalty-free, non transferable, non sublicensable, non exclusive, +irrevocable and unconditional license to exercise Affirmer's Copyright and +Related Rights in the Work (i) in all territories worldwide, (ii) for the +maximum duration provided by applicable law or treaty (including future +time extensions), (iii) in any current or future medium and for any number +of copies, and (iv) for any purpose whatsoever, including without +limitation commercial, advertising or promotional purposes (the +"License"). The License shall be deemed effective as of the date CC0 was +applied by Affirmer to the Work. Should any part of the License for any +reason be judged legally invalid or ineffective under applicable law, such +partial invalidity or ineffectiveness shall not invalidate the remainder +of the License, and in such case Affirmer hereby affirms that he or she +will not (i) exercise any of his or her remaining Copyright and Related +Rights in the Work or (ii) assert any associated claims and causes of +action with respect to the Work, in either case contrary to Affirmer's +express Statement of Purpose. + +4. Limitations and Disclaimers. + + a. No trademark or patent rights held by Affirmer are waived, abandoned, + surrendered, licensed or otherwise affected by this document. + b. Affirmer offers the Work as-is and makes no representations or + warranties of any kind concerning the Work, express, implied, + statutory or otherwise, including without limitation warranties of + title, merchantability, fitness for a particular purpose, non + infringement, or the absence of latent or other defects, accuracy, or + the present or absence of errors, whether or not discoverable, all to + the greatest extent permissible under applicable law. + c. Affirmer disclaims responsibility for clearing rights of other persons + that may apply to the Work or any use thereof, including without + limitation any person's Copyright and Related Rights in the Work. + Further, Affirmer disclaims responsibility for obtaining any necessary + consents, permissions or other rights required for any use of the + Work. + d. Affirmer understands and acknowledges that Creative Commons is not a + party to this document and has no duty or obligation with respect to + this CC0 or use of the Work. diff --git a/README.md b/README.md new file mode 100644 index 0000000..04b35d0 --- /dev/null +++ b/README.md @@ -0,0 +1,123 @@ +# Patchwork Flatpak + +Flatpak packaging for [Poncho Wonky](https://github.com/soapdog/patchwork), the +Secure Scuttlebutt (SSB) desktop client. This is a **release-wrapper** Flatpak: +it repackages the official upstream `tar.gz` build from the +[GitHub releases page](https://github.com/soapdog/patchwork/releases) instead of +building from source, so no native modules are recompiled inside the sandbox. + +The packaging files in this repository (manifest, launcher, build scripts) are +licensed under CC0-1.0 (see `LICENSE`). The packaged application itself remains +AGPL-3.0, as declared in `nz.scuttlebutt.Patchwork.metainfo.xml`. + +## Layout + +| File | Purpose | +|------|---------| +| `nz.scuttlebutt.Patchwork.yaml` | `flatpak-builder` manifest | +| `patchwork.sh` | Launcher that runs the app through `zypak-wrapper` (Electron sandbox) | +| `nz.scuttlebutt.Patchwork.metainfo.xml` | AppStream metadata for software centers | +| `build.sh` | One-shot build + install helper | +| `flathub.json` | Flathub build config | + +## Prerequisites + +On Debian/Ubuntu: + +```bash +sudo apt install flatpak flatpak-builder +flatpak remote-add --if-not-exists --user flathub https://flathub.org/repo/flathub.flatpakrepo +``` + +Alternatively, `flatpak-builder` can be installed as a Flatpak: + +```bash +flatpak install flathub org.flatpak.Builder +``` + +If you use `org.flatpak.Builder`, you'll need to run builds with: + +```bash +flatpak run --command=flatpak-builder org.flatpak.Builder \ + --repo=repo --force-clean build-dir nz.scuttlebutt.Patchwork.yaml +``` + +## Build and install + +```bash +./build.sh +``` + +or manually: + +```bash +flatpak install -y flathub \ + org.freedesktop.Platform//24.08 \ + org.freedesktop.Sdk//24.08 \ + org.electronjs.Electron2.BaseApp//24.08 + +flatpak-builder --repo=repo --force-clean build-dir nz.scuttlebutt.Patchwork.yaml + +flatpak --user remote-add --if-not-exists --no-gpg-verify patchwork-repo repo +flatpak --user install -y patchwork-repo nz.scuttlebutt.Patchwork +``` + +Run it: + +```bash +flatpak run nz.scuttlebutt.Patchwork +``` + +The launcher (`patchwork.sh`) forces Electron onto Wayland whenever a Wayland +socket is available, so it also works from terminals that are not part of the +desktop session (local TTY, SSH) where `DISPLAY`/`WAYLAND_DISPLAY` would +otherwise be unset and Electron would fail with `Missing X server or $DISPLAY`. +On X11-only systems it falls back to Electron's default X11 platform. + +## Updating to a new release + +All pinned versions live in `versions.sh`. Bump the app version first: + +1. Note the new version tag (e.g. `v5.5.0`) and download the new assets: + + ```bash + wget https://github.com/soapdog/patchwork/releases/download/v5.5.0/ponchowonky-5.5.0.tar.gz + wget https://github.com/soapdog/patchwork/releases/download/v5.5.0/ponchowonky-5.5.0-arm64.tar.gz + sha256sum ponchowonky-5.5.0.tar.gz ponchowonky-5.5.0-arm64.tar.gz + ``` + +2. Update `APP_VERSION`, `APP_SHA256_X86_64` and `APP_SHA256_AARCH64` in + `versions.sh`, then run `./check-versions.sh` — it verifies the manifest + URLs/checksums and the metainfo release entry still match. +3. Update `url`/`sha256` in `nz.scuttlebutt.Patchwork.yaml`. No + `build-commands` change is needed: flatpak-builder strips the archive's + top-level directory (default `strip-components: 1`) into the `app/` source + directory. +4. Add a new `` entry in `nz.scuttlebutt.Patchwork.metainfo.xml`. + +To bump the Flatpak environment, update `RUNTIME_VERSION` in `versions.sh` (used +for the freedesktop runtime, SDK and Electron BaseApp — they always move +together). + +## Notes + +- **Why `tar.gz` and not the AppImage?** The upstream `tar.gz` assets are the + unpacked `electron-builder` build. Using them avoids the `--appimage-extract` + step and keeps the manifest architecture-agnostic. +- **Runtime vs. Electron version.** The app ships its own Electron binary inside + the `tar.gz`, so the runtime is not tied to Electron's version — it only needs + to satisfy the host glibc/GTK stack that Electron requires. `RUNTIME_VERSION` + should be bumped to the next freedesktop branch only when a newer Electron + stops working on the current one (the manifest change is one line plus a + rebuild). +- **SSB data.** Patchwork resolves its data directory from the real user home + (`getpwuid`), not `$HOME`, so it writes to `~/.ssb` on the host even from + inside the sandbox. A non-Flatpak install shares the same data — no migration + needed. (Flatpak still redirects `~/.cache`, `~/.config` and `~/.local` for + this app to `~/.var/app/nz.scuttlebutt.Patchwork/`.) +- **Network.** SSB uses LAN multicast discovery, DHT and direct TCP/UDP; + `--share=network` covers this. `--device=all` is granted for webcam support + and can be removed from `finish-args` if you do not want it. +- **Flathub.** The metainfo `` section is omitted because the + upstream screenshot URL currently returns 404. Add screenshots hosted on a + stable CDN before submitting to Flathub. diff --git a/build.sh b/build.sh new file mode 100755 index 0000000..6389301 --- /dev/null +++ b/build.sh @@ -0,0 +1,37 @@ +#!/bin/bash +set -euo pipefail + +source "$(dirname "$0")/versions.sh" + +RUNTIME="org.freedesktop.Platform" +SDK="org.freedesktop.Sdk" +BASEAPP="org.electronjs.Electron2.BaseApp" +APP_ID="nz.scuttlebutt.Patchwork" +MANIFEST="nz.scuttlebutt.Patchwork.yaml" +REPO="repo" +BUILD_DIR="build-dir" + +# 1. Install build dependencies (runtime, SDK and Electron base app) +flatpak install -y flathub \ + "${RUNTIME}//${RUNTIME_VERSION}" \ + "${SDK}//${RUNTIME_VERSION}" \ + "${BASEAPP}//${RUNTIME_VERSION}" + +# 2. Build the bundle +if ! command -v flatpak-builder >/dev/null 2>&1; then + echo "flatpak-builder is not installed." >&2 + echo "Install it with one of:" >&2 + echo " sudo apt install flatpak-builder" >&2 + echo " flatpak install flathub org.flatpak.Builder" >&2 + echo "If you used org.flatpak.Builder, run:" >&2 + echo " flatpak run --command=flatpak-builder org.flatpak.Builder --repo=${REPO} --force-clean ${BUILD_DIR} ${MANIFEST}" >&2 + exit 1 +fi +flatpak-builder --repo="${REPO}" --force-clean "${BUILD_DIR}" "${MANIFEST}" + +# 3. Install it into the current user +flatpak --user remote-add --if-not-exists --no-gpg-verify patchwork-repo "${REPO}" +flatpak --user install -y patchwork-repo "${APP_ID}" + +echo +echo "Done. Run it with: flatpak run ${APP_ID}" diff --git a/check-versions.sh b/check-versions.sh new file mode 100755 index 0000000..1260ff3 --- /dev/null +++ b/check-versions.sh @@ -0,0 +1,41 @@ +#!/bin/bash +# Verify the manifest and metainfo still match the pins in versions.sh. +# Usage: ./check-versions.sh + +set -euo pipefail +source "$(dirname "$0")/versions.sh" + +MANIFEST="nz.scuttlebutt.Patchwork.yaml" +METAINFO="nz.scuttlebutt.Patchwork.metainfo.xml" +fail=0 + +check() { + local desc="$1" expected="$2" actual="$3" + if [ "$expected" != "$actual" ]; then + echo "FAIL: $desc expected '$expected', found '$actual'" >&2 + fail=1 + else + echo "ok: $desc = '$actual'" + fi +} + +check "runtime-version" "$RUNTIME_VERSION" \ + "$(sed -n "s/^runtime-version: '\(.*\)'/\1/p" "$MANIFEST")" +check "base-version" "$RUNTIME_VERSION" \ + "$(sed -n "s/^base-version: '\(.*\)'/\1/p" "$MANIFEST")" +check "metainfo release version" "$APP_VERSION" \ + "$(sed -n "s/.* + + nz.scuttlebutt.Patchwork + CC0-1.0 + AGPL-3.0 + Patchwork + A decentralized messaging and sharing app + + Secure Scuttlebutt Consortium + + +

+ A decentralized messaging and sharing app built on top of Secure + Scuttlebutt (SSB). +

+ + nz.scuttlebutt.Patchwork.desktop + + https://www.scuttlebutt.nz/ + https://github.com/soapdog/patchwork/issues + + Network + Chat + Feed + + + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + none + intense + none + none + none + none + none + none + + + + + diff --git a/nz.scuttlebutt.Patchwork.yaml b/nz.scuttlebutt.Patchwork.yaml new file mode 100644 index 0000000..1f4b5a2 --- /dev/null +++ b/nz.scuttlebutt.Patchwork.yaml @@ -0,0 +1,52 @@ +app-id: nz.scuttlebutt.Patchwork +runtime: org.freedesktop.Platform +runtime-version: '24.08' +sdk: org.freedesktop.Sdk +base: org.electronjs.Electron2.BaseApp +base-version: '24.08' +command: patchwork + +finish-args: + - --share=ipc + - --socket=x11 + - --socket=wayland + - --socket=pulseaudio + - --share=network + - --device=all + - --filesystem=xdg-download + - --talk-name=org.freedesktop.Notifications + +modules: + - name: patchwork + buildsystem: simple + build-commands: + - mv app /app/Patchwork + - install -Dm755 patchwork.sh /app/bin/patchwork + - | + install -Dm644 /app/Patchwork/resources/app/assets/nz.scuttlebutt.Patchwork.desktop \ + /app/share/applications/nz.scuttlebutt.Patchwork.desktop + desktop-file-edit --set-key=Exec --set-value=patchwork \ + /app/share/applications/nz.scuttlebutt.Patchwork.desktop + - | + install -Dm644 /app/Patchwork/resources/app/assets/512x512.png \ + /app/share/icons/hicolor/512x512/apps/nz.scuttlebutt.Patchwork.png + - | + install -Dm644 nz.scuttlebutt.Patchwork.metainfo.xml \ + /app/share/metainfo/nz.scuttlebutt.Patchwork.metainfo.xml + sources: + - type: archive + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0.tar.gz + sha256: 15b147f35381b4e3bd1a7b5b3b9bfe924c6427c65e5ff72c25209ddf93141e7a + dest: app + only-arches: + - x86_64 + - type: archive + url: https://github.com/soapdog/patchwork/releases/download/v5.4.0/ponchowonky-5.4.0-arm64.tar.gz + sha256: c78bb91f12c55bc72d68ff8a4e90a162eefd55010d2686443a23de808901f70b + dest: app + only-arches: + - aarch64 + - type: file + path: patchwork.sh + - type: file + path: nz.scuttlebutt.Patchwork.metainfo.xml diff --git a/patchwork.sh b/patchwork.sh new file mode 100755 index 0000000..84f74a1 --- /dev/null +++ b/patchwork.sh @@ -0,0 +1,11 @@ +#!/bin/sh +set -e + +# Electron defaults to the X11 platform even on Wayland-only sessions, which +# fails when no X server or $DISPLAY is available. Use Wayland whenever a +# socket is present; otherwise fall back to Electron's default (X11). +if [ -S "${XDG_RUNTIME_DIR}/wayland-0" ]; then + exec zypak-wrapper /app/Patchwork/ponchowonky --ozone-platform=wayland "$@" +fi + +exec zypak-wrapper /app/Patchwork/ponchowonky "$@" diff --git a/versions.sh b/versions.sh new file mode 100644 index 0000000..8897014 --- /dev/null +++ b/versions.sh @@ -0,0 +1,15 @@ +#!/bin/bash +# Single source of truth for every pinned version in this packaging. +# build.sh sources this file; check-versions.sh verifies the manifest and +# metainfo still match. Bump versions here first, then run check-versions.sh. + +# Flatpak runtime/SDK/Electron BaseApp branch. These three always move +# together. The app bundles its own Electron binary from the tar.gz, so this +# only needs to satisfy the host glibc/GTK stack Electron requires -- bump to +# the next branch (e.g. 25.08) only when a newer Electron demands it. +export RUNTIME_VERSION="24.08" + +# Upstream Patchwork (Poncho Wonky) release. +export APP_VERSION="5.4.0" +export APP_SHA256_X86_64="15b147f35381b4e3bd1a7b5b3b9bfe924c6427c65e5ff72c25209ddf93141e7a" +export APP_SHA256_AARCH64="c78bb91f12c55bc72d68ff8a4e90a162eefd55010d2686443a23de808901f70b"