Flatpak support

[000exploit]

I'm too lazy to do everything manually, I just want to install and run software, not build. I think there's no point in describing what flatpak/flathub is and why it's good for end users. Just pack it in flatpak in the near future, since your project has appeared on TWIG.

[gnuntoo]

Yeah it looks useful for my librem 5. looking forward to trying it out

[DaKnig]

Will do!
btw what operating systems you all use? I might provide packages for these

[000exploit]

I can package it myself for Fedora and most of RPM-based systems using COPR. I'm still not sure about the quality of mine spec files, but I can, yes.

[ibrahim-mu]

Will do! btw what operating systems you all use? I might provide packages for these

An Arch-based distro, so an AUR package will be awesome. Or maybe just a flatpak.

[julianrichen]

Hello, I played with packaging this for Flatpak as I'm on Fedora Silverblue and everything is (generally) a Flatpak. I'll attach the yaml and steps I used to at least get it to launch, but the current way the app works likely wont work well for Flatpak.

That app spins-up a child process for mpv, which you generally can't do in Flatpak as you'd be escaping the sandbox. You may want to look into embedding the video player. Maybe using the Clapper library mentioned in the latest This Week In GNOME (TWIG): https://gitlab.gnome.org/JanGernert/clapper-rs

But then that doesn't account for needing yt-dl/yt-dlp as well... so I'm not sure really the best way to make this work.

Other packaging notes:

• You have a mix of null.daknig.dewduct (metadata) and null.daknig.DewDuct (code) for the app-id. The ID should be unified or it can cause dbus issues in flatpak when it tries to match the names. I generated a patch in the steps below to align it for the build file. Not really familiar with making patches so the steps are probably not the optimal way to do it.
• Generally app-ids are suppose to be reverse dns app-ids, in that it's tld.domain.appname. null.daknig would be the domain daknig.null, which isn't valid (to my understanding). So not sure if it would be approved on Flathub. so com.github.DaKnig.DewDuct or io.github.DaKnig.DewDuct may be better. Info: https://docs.flathub.org/docs/for-app-authors/requirements/#application-id
• I'd remove the appstreamcli step you have in the alpine linux build and what I have below. Just make generating the desktop file as part of the version release when you generate the tarball. Packaging appstreamcli was kind of tedious for Flatpak and same will apply for other formats and you'll need to account for it in each package format.

Hopefully this helps as a starting point in your testing. Interesting app with that I played around with so far :)

Build steps

# Builddir
mkdir -p ~/Projects/DewDuct
cd ~/Projects/DewDuct

# Copy null.daknig.DewDuct.yml to this folder

# Install SDKs and flatpak-builder
flatpak install org.gnome.Sdk//46
flatpak install org.freedesktop.Sdk.Extension.llvm16//23.08
flatpak install org.freedesktop.Sdk.Extension.rust-stable//23.08
flatpak install org.flatpak.Builder

# Clone cargo helpers and sources files (for flatpak-cargo-generator.py)
git clone https://github.com/flatpak/flatpak-builder-tools.git
git clone https://github.com/DaKnig/DewDuct.git

# Needed Python packages for flatpak-cargo-generator.py
python3 -m pip install --upgrade pip
python3 -m pip install aiohttp 
python3 -m pip install toml

# Generate cargo build files for offline build
python3 ./flatpak-builder-tools/cargo/flatpak-cargo-generator.py ./DewDuct/Cargo.lock -o cargo-sources.json

mkdir -p ./patch-files
cp ./DewDuct/data/null.daknig.dewduct.metainfo.xml ./patch-files/null.daknig.dewduct.metainfo.xml
sed -i '[email protected]@null.daknig.DewDuct@g' ./patch-files/null.daknig.dewduct.metainfo.xml

# Apply patch for app-id
diff -Naru ./DewDuct/data/null.daknig.dewduct.metainfo.xml ./patch-files/null.daknig.dewduct.metainfo.xml > ./meta.patch
sed -i 's@./DewDuct/data@a/data@g' ./meta.patch
sed -i 's@./patch-files@b/data@g' ./meta.patch

# Build package
flatpak run org.flatpak.Builder --user --install --force-clean dewduct-build null.daknig.DewDuct.yml

# Run once installed
flatpak run null.daknig.DewDuct

YAML

id: null.daknig.DewDuct
runtime: org.gnome.Platform
runtime-version: '46'
sdk: org.gnome.Sdk
sdk-extensions:
  # See: https://github.com/flathub/org.freedesktop.Sdk.Extension.rust-stable
  - org.freedesktop.Sdk.Extension.rust-stable
  - org.freedesktop.Sdk.Extension.llvm16
command: dewduct
finish-args:
  # X11 + XShm access
  - --share=ipc
  - --socket=fallback-x11
  # Wayland access
  - --socket=wayland
  # Graphics access
  - --device=dri
  # Network access
  - --share=network
  # File access (TBD)
  - --filesystem=host
build-options:
  # See: https://github.com/flathub/org.freedesktop.Sdk.Extension.rust-stable
  append-path: /usr/lib/sdk/rust-stable/bin:/usr/lib/sdk/llvm16/bin
  env:
    CARGO_HOME: /run/build/dewduct/cargo
    CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_LINKER: "clang"
    CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS: "-C link-arg=-fuse-ld=/usr/lib/sdk/rust-stable/bin/mold"
    CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_LINKER: "clang"
    CARGO_TARGET_AARCH64_UNKNOWN_LINUX_GNU_RUSTFLAGS: "-C link-arg=-fuse-ld=/usr/lib/sdk/rust-stable/bin/mold"
cleanup:
  - /include
  - /lib/pkgconfig
  - /man
  - /share/doc
  - /share/gtk-doc
  - /share/man
  - /share/pkgconfig
  - '*.la'
  - '*.a'
  # Only needed for appstream module, to avoid symbol conflict
  - /lib/debug
  - /lib/libappstream.so*
  - /lib/libxmlb.so*
  - /lib/libyaml.so*
modules:
  # For Build (appstreamcli)
  - name: appstream
    buildsystem: meson
    config-opts:
      - "-Dbuildtype=release"
      - "-Dstemming=false"
      - "-Dgir=false"
      - "-Dapidocs=false"
    cleanup:
      - "/bin/appstreamcli"
    sources:
      - type: git
        url: https://github.com/ximion/appstream.git
        commit: 1ee6af91310f9deb47f3863a7a7ffb22c46bcce6
        tag: v0.16.2
    modules:
      - name: libyaml
        buildsystem: autotools
        sources:
        - type: git
          url: https://github.com/yaml/libyaml.git
          commit: 2c891fc7a770e8ba2fec34fc6b545c672beb37e6
          tag: 0.2.5
      - name: libxmlb
        buildsystem: meson
        config-opts:
          - "-Dbuildtype=release"
          - "-Dintrospection=false"
          - "-Dtests=false"
          - "-Dcli=false"
          - "-Dgtkdoc=false"
        sources:
          - type: git
            url: https://github.com/hughsie/libxmlb.git
            commit: 6191220071233972d798b57841d08e4964952a17
            tag: 0.3.11

  - name: dewduct
    sources:
      - cargo-sources.json
      - type: archive
        url: https://github.com/DaKnig/DewDuct/archive/refs/tags/v0.2.2.tar.gz
        sha256: eb25d630931941f6d2dd0e0057aa28cd1887db8babaa4677b45ed4c90db234a6
      - type: patch
        path: meta.patch
    buildsystem: simple
    build-commands:
      - cargo --offline fetch --manifest-path 'Cargo.toml' --verbose
      - appstreamcli make-desktop-file data/null.daknig.dewduct.metainfo.xml null.daknig.dewduct.desktop
      - cargo --offline build --release --locked --verbose
      - install -Dm755 target/release/dewduct --target-directory=/app/bin
      - install -Dm644 data/null.daknig.dewduct.metainfo.xml /app/share/metainfo/null.daknig.DewDuct.metainfo.xml
      - install -Dm644 null.daknig.dewduct.desktop /app/share/applications/null.daknig.DewDuct.desktop
      
      # Ideally we would do this, move appstreamcli outside of flatpak and and rename the files and ID.
      # - install -Dm644 data/null.daknig.dewduct.metainfo.xml --target-directory=/app/share/metainfo
      # - install -Dm644 data/null.daknig.DewDuct.desktop --target-directory=/app/share/applications
      # - install -Dm644 data/null.daknig.DewDuct.svg --target-directory=/app/share/icons/hicolor/scalable/apps

[DaKnig]

yt-dlp and mpv: is there no way to put multiple binaries into one flatpak? yt-dlp is required by mpv to play videos and is not called directly. if it is possible to put mpv inside the same sandbox, then add it to be first in PATH or something, then you would be calling from within the sandbox something else in the same sandbox (sorry I dont have much experience with flatpak...)

integrating clapper,: I have already talked to the other person who made Rust API for that, will look into that later, currently I'd like to focus my attention on actual features of the app- I personally see embedded player as low priority, but PRs are welcome!

app ID: its one of the things blocking me. I only set a few temporary variables there, soon I'd like to change it completely to something else. I was in the process of acquiring a (sub)domain, and I dont want to be associated with github in the appid, but dw as we get closer to a working flatpak I will fix that.

appstreamcli: I never knew that it was a pain to package on flatpak, and I'd like to avoid having a .desktop file in the repo. most distros ship it so it's fine. I believe that we'd need to swap for meson to get a better build process where we can for example "compile" things other than rust, have one source of truth for version and stuff, see Fractal.

icon: still no icon :(

[julianrichen]

yt-dlp and mpv: is there no way to put multiple binaries into one flatpak? yt-dlp is required by mpv to play videos and is not called directly. if it is possible to put mpv inside the same sandbox, then add it to be first in PATH or something, then you would be calling from within the sandbox something else in the same sandbox (sorry I dont have much experience with flatpak...)

You can install multiple binaries in one flatpak but I'm unsure how it works when you fork a process in the flatpak and try and launch it. I think it should work. The issue is you'll need to package mpv and yt-dlp with the manifest and maintain a copy of the io.mpv.Mpv yaml file. So that could be a lot of work consider the changes mpv has. I'm unsure if flathub policy allows it.

Last I recall the work to allow one flatpak to call/open another flatpak is still being discuss and no xdg portal exists for it. src.

Might be a good question for the flathub forums on what others are doing. I can't imagine there isn't another app trying to do this.

integrating clapper,: I have already talked to the other person who made Rust API for that, will look into that later, currently I'd like to focus my attention on actual features of the app- I personally see embedded player as low priority, but PRs are welcome!

I would imagine it would be a lot of work to include, so makes sense.

app ID: its one of the things blocking me. I only set a few temporary variables there, soon I'd like to change it completely to something else. I was in the process of acquiring a (sub)domain, and I dont want to be associated with github in the appid, but dw as we get closer to a working flatpak I will fix that.

Totally get that. There is a deprecating feature in flathub that if the app-id changes you can mark it EOL and then move to another app-id. I think it's case by case but does exists if you did need to change it in the future. src

appstreamcli: I never knew that it was a pain to package on flatpak, and I'd like to avoid having a .desktop file in the repo. most distros ship it so it's fine. I believe that we'd need to swap for meson to get a better build process where we can for example "compile" things other than rust, have one source of truth for version and stuff, see Fractal.

It exists in the flatpak manifest above now so it'll work, it's just a couple of extra build steps to make it happen and something to consider when maintaining since you may need to bump the appstream version. TBH I'm surprised gnome/FDO SDK doesn't have it included to make it easier.

Moving to a build system like meson would avoid needing to specify the few build/install steps for each package, so that would be handy but it's to many currently.

[DaKnig]

this will be blocked on Move to meson #7

[yochananmarqos]

@ibrahim-mu

an AUR package will be awesome

I have a WIP PKGBUILD.

[DaKnig]

when you feel like it is ready then send a PR. PR should also organize it a bit better - maybe call it "packages" or w.e to include a folder for arch / alpine or whatever.