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.
This commit is contained in:
@@ -0,0 +1,4 @@
|
||||
.flatpak-builder/
|
||||
build-dir/
|
||||
repo/
|
||||
*.swp
|
||||
@@ -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**
|
||||
|
||||
<details><summary>Thinking</summary>
|
||||
|
||||
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 `<releases>` section
|
||||
- Use `<developer>` instead of `<developer_name>` (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
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<component type="desktop-application">
|
||||
<id>nz.scuttlebutt.Patchwork</id>
|
||||
<launchable type="desktop-id">nz.scuttlebutt.Patchwork.desktop</launchable>
|
||||
<metadata_license>CC0-1.0</metadata_license>
|
||||
<project_license>AGPL-3.0</project_license>
|
||||
<name>Patchwork</name>
|
||||
<summary>A decentralized messaging and sharing app</summary>
|
||||
<description>
|
||||
<p>Patchwork is a decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB).</p>
|
||||
</description>
|
||||
<screenshots>
|
||||
<screenshot type="default">
|
||||
<caption>Network chat feed</caption>
|
||||
<image>https://raw.githubusercontent.com/soapdog/patchwork/master/screenshot.jpg</image>
|
||||
</screenshot>
|
||||
</screenshots>
|
||||
<url type="homepage">https://www.scuttlebutt.nz/</url>
|
||||
<url type="bugtracker">https://github.com/soapdog/patchwork/issues</url>
|
||||
<developer id="nz.scuttlebutt">
|
||||
<name>Secure Scuttlebutt Consortium</name>
|
||||
</developer>
|
||||
<content_rating type="oars-1.1">
|
||||
<content_attribute id="social-chat">intense</content_attribute>
|
||||
<content_attribute id="social-info">intense</content_attribute>
|
||||
<content_attribute id="social-audio">intense</content_attribute>
|
||||
</content_rating>
|
||||
<releases>
|
||||
<release version="5.4.0" date="2026-08-12"/>
|
||||
</releases>
|
||||
</component>
|
||||
```
|
||||
|
||||
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.
|
||||
|
||||
</details>
|
||||
|
||||
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
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!-- nz.scuttlebutt.Patchwork.metainfo.xml -->
|
||||
<component type="desktop-application">
|
||||
<id>nz.scuttlebutt.Patchwork</id>
|
||||
<launchable type="desktop-id">nz.scuttlebutt.Patchwork.desktop</launchable>
|
||||
<metadata_license>CC0-1.0</metadata_license>
|
||||
<project_license>AGPL-3.0</project_license>
|
||||
<name>Patchwork</name>
|
||||
<summary>A decentralized messaging and sharing app</summary>
|
||||
<description>
|
||||
<p>Patchwork is a decentralized messaging and sharing app built on top of Secure Scuttlebutt (SSB).</p>
|
||||
</description>
|
||||
<screenshots>
|
||||
<screenshot type="default">
|
||||
<caption>Network chat feed</caption>
|
||||
<image>https://raw.githubusercontent.com/soapdog/patchwork/master/screenshot.jpg</image>
|
||||
</screenshot>
|
||||
</screenshots>
|
||||
<url type="homepage">https://www.scuttlebutt.nz/</url>
|
||||
<url type="bugtracker">https://github.com/soapdog/patchwork/issues</url>
|
||||
<developer id="nz.scuttlebutt">
|
||||
<name>Secure Scuttlebutt Consortium</name>
|
||||
</developer>
|
||||
<content_rating type="oars-1.1">
|
||||
<content_attribute id="social-chat">intense</content_attribute>
|
||||
<content_attribute id="social-info">intense</content_attribute>
|
||||
<content_attribute id="social-audio">intense</content_attribute>
|
||||
</content_rating>
|
||||
<releases>
|
||||
<release version="5.4.0" date="YYYY-MM-DD"/>
|
||||
</releases>
|
||||
</component>
|
||||
```
|
||||
|
||||
```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 `<release date="YYYY-MM-DD"/>` 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**
|
||||
|
||||
<details><summary>Thinking</summary>
|
||||
|
||||
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.
|
||||
|
||||
</details>
|
||||
|
||||
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 `<release>` 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.
|
||||
|
||||
---
|
||||
|
||||
@@ -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.
|
||||
@@ -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 `<release>` 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 `<screenshots>` section is omitted because the
|
||||
upstream screenshot URL currently returns 404. Add screenshots hosted on a
|
||||
stable CDN before submitting to Flathub.
|
||||
@@ -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}"
|
||||
Executable
+41
@@ -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/.*<release version=\"\([^\"]*\)\" .*/\1/p" "$METAINFO" | head -1)"
|
||||
|
||||
x86_url=$(grep -oE 'ponchowonky-[0-9.]+\.tar\.gz' "$MANIFEST")
|
||||
arm_url=$(grep -oE 'ponchowonky-[0-9.]+-arm64\.tar\.gz' "$MANIFEST")
|
||||
check "x86_64 asset version" "$APP_VERSION" \
|
||||
"$(echo "$x86_url" | sed 's/^ponchowonky-//; s/\.tar\.gz$//')"
|
||||
check "aarch64 asset version" "$APP_VERSION" \
|
||||
"$(echo "$arm_url" | sed 's/^ponchowonky-//; s/-arm64\.tar\.gz$//')"
|
||||
|
||||
x86_sha=$(sed -n "/ponchowonky-${APP_VERSION}\.tar\.gz/{n;s/ *sha256: *//;p}" "$MANIFEST")
|
||||
arm_sha=$(sed -n "/ponchowonky-${APP_VERSION}-arm64\.tar\.gz/{n;s/ *sha256: *//;p}" "$MANIFEST")
|
||||
check "x86_64 sha256" "$APP_SHA256_X86_64" "$x86_sha"
|
||||
check "aarch64 sha256" "$APP_SHA256_AARCH64" "$arm_sha"
|
||||
|
||||
exit "$fail"
|
||||
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"only-arches": ["x86_64", "aarch64"]
|
||||
}
|
||||
@@ -0,0 +1,59 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<component type="desktop-application">
|
||||
<id>nz.scuttlebutt.Patchwork</id>
|
||||
<metadata_license>CC0-1.0</metadata_license>
|
||||
<project_license>AGPL-3.0</project_license>
|
||||
<name>Patchwork</name>
|
||||
<summary>A decentralized messaging and sharing app</summary>
|
||||
<developer id="nz.scuttlebutt">
|
||||
<name>Secure Scuttlebutt Consortium</name>
|
||||
</developer>
|
||||
<description>
|
||||
<p>
|
||||
A decentralized messaging and sharing app built on top of Secure
|
||||
Scuttlebutt (SSB).
|
||||
</p>
|
||||
</description>
|
||||
<launchable type="desktop-id">nz.scuttlebutt.Patchwork.desktop</launchable>
|
||||
<!-- TODO(flathub): add a <screenshots> section hosted on a stable CDN.
|
||||
The upstream screenshot URL is currently 404. -->
|
||||
<url type="homepage">https://www.scuttlebutt.nz/</url>
|
||||
<url type="bugtracker">https://github.com/soapdog/patchwork/issues</url>
|
||||
<categories>
|
||||
<category>Network</category>
|
||||
<category>Chat</category>
|
||||
<category>Feed</category>
|
||||
</categories>
|
||||
<content_rating type="oars-1.1">
|
||||
<content_attribute id="violence-cartoon">none</content_attribute>
|
||||
<content_attribute id="violence-fantasy">none</content_attribute>
|
||||
<content_attribute id="violence-realistic">none</content_attribute>
|
||||
<content_attribute id="violence-bloodshed">none</content_attribute>
|
||||
<content_attribute id="violence-sexual">none</content_attribute>
|
||||
<content_attribute id="violence-desecration">none</content_attribute>
|
||||
<content_attribute id="violence-slavery">none</content_attribute>
|
||||
<content_attribute id="violence-worship">none</content_attribute>
|
||||
<content_attribute id="drugs-alcohol">none</content_attribute>
|
||||
<content_attribute id="drugs-narcotics">none</content_attribute>
|
||||
<content_attribute id="drugs-tobacco">none</content_attribute>
|
||||
<content_attribute id="sex-nudity">none</content_attribute>
|
||||
<content_attribute id="sex-themes">none</content_attribute>
|
||||
<content_attribute id="sex-homosexuality">none</content_attribute>
|
||||
<content_attribute id="sex-prostitution">none</content_attribute>
|
||||
<content_attribute id="sex-adultery">none</content_attribute>
|
||||
<content_attribute id="sex-appearance">none</content_attribute>
|
||||
<content_attribute id="language-profanity">none</content_attribute>
|
||||
<content_attribute id="language-humor">none</content_attribute>
|
||||
<content_attribute id="language-discrimination">none</content_attribute>
|
||||
<content_attribute id="social-chat">intense</content_attribute>
|
||||
<content_attribute id="social-info">none</content_attribute>
|
||||
<content_attribute id="social-audio">none</content_attribute>
|
||||
<content_attribute id="social-location">none</content_attribute>
|
||||
<content_attribute id="social-contacts">none</content_attribute>
|
||||
<content_attribute id="money-purchasing">none</content_attribute>
|
||||
<content_attribute id="money-gambling">none</content_attribute>
|
||||
</content_rating>
|
||||
<releases>
|
||||
<release version="5.4.0" date="2026-07-30"/>
|
||||
</releases>
|
||||
</component>
|
||||
@@ -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
|
||||
Executable
+11
@@ -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 "$@"
|
||||
+15
@@ -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"
|
||||
Reference in New Issue
Block a user