Packaging for flatpak

[microo8]

It would be great to install tofi from flatpak.

For systems without AUR (btw) and when you are forced to use Ubuntu 20.04 LTS with packages so old, that even meson version isn't enough (not to mention other dependencies).

[philj56]

I'll have a look into it, but I don't use flatpak myself (and don't really like snap / flatpak's approach), so I'm unsure when I'll get round to it.

I've run into the issues old versions of meson on Ubuntu before, and have managed to make a github action to build .debs for older versions, so I might also do that for releases of tofi.

[microo8]

I've also avoided everything even close to snap/flatpak. But then I've stumbled across this and this and also the need for newer software on an old Ubuntu. Then I've reinstalled all things that could be installed from flatpak and love it. That it makes my packages on the system more tidy, it runs everywhere the same and also the sandbox is a better feeling (when you must use ms teams).

So I've started to play around a bit. This is the com.github.philj56.tofi.yml:

app-id: com.github.philj56.tofi
runtime: org.freedesktop.Platform
runtime-version: "21.08"
sdk: org.freedesktop.Sdk
command: tofi

finish-args:
  - --filesystem=xdg-config/tofi:ro
  - --socket=wayland

modules:
  - name: tofi
    buildsystem: meson
    config-opts:
      - -Dbuild_man=true
    sources:
      - type: archive
        url: https://github.com/philj56/tofi/archive/refs/tags/v0.3.1.zip
        sha256: c7bdc8d444522b2db9e24137f90540ff9d0c970d92a6a9082e48332622f7150d

And run the building with: flatpak-builder --force-clean build-dir com.github.philj56.tofi.yml

But the meson version in org.freedesktop.Sdk is just 0.59.4 and the install_symlink is from version 0.61.0.

So that's it. Or could there be another way? To don't use install_symlink?

[eli-schwartz]

https://mesonbuild.com/Getting-meson.html describes a few different ways to get the most recent version of Meson even if your distro doesn't have it yet. As a build-time only dependency, Meson isn't so bad to manually install.

Install-time dependencies could be handled via https://mesonbuild.com/Wrap-dependency-system-manual.html to some extent. Most dependencies should be functional as fallbacks, but OTOH you don't want to override system versions, merely use a private copy, so at least you'd want to document using meson install --skip-subprojects in that case.

[philj56]

Ok, so I've had a brief play around with this on a Ubuntu 20.04 install, and thought I'd write down what I've found so far. The problems I ran into were:

• Outdated Meson, which isn't too much of an issue (thanks for the links @eli-schwartz, I hadn't thought of installing Meson via pip, which is much easier than the weird installation from future Ubuntu releases stuff I've done in the past).
• I've perhaps been a bit overzealous using c_std=c2x and the [[attribute]] syntax :stuck_out_tongue:. That can be changed back to the older __attribute__(())stuff.
• The version of Wayland included with Ubuntu 20.04 has an old version of the output protocol, which gives compile errors due to the wl_output_listener struct not having .name or .description - that could either be fixed with an #ifdef, or by building Wayland as a subproject via a wrap file.
• The version of Sway is correspondingly outdated, so can't provide the names of outputs, meaning the --output option is non-functional.
• Also from the old Sway, something funny's going on with anchoring, such that tofi can only be anchored to a screen corner, not the center of the screen or any edges (though you can fake it with --margin-*). This isn't too surprising given the unstable nature of wlr_layer_shell, but I haven't looked into it further.

With these caveats, I've got tofi building fine. Due to the simplicity of the fix for the old Wayland version, I think I'd rather go for just an #ifdef for now rather than building Wayland as a subproject.

@microo8 Thanks for getting started with the Flatpak stuff! As far as I can tell, the only issues with that are the Meson and Sway versions (seeing as you're presumably using the outdated system Sway). For Meson, I think the easiest answer is just to wait - it looks like the next release of the Freedesktop SDK will be soon (this comment states that it will freeze next week), and that includes an up to date Meson and Wayland. For Sway, the issues would be the --output option and anchoring problems described above, but there's not much I can do about them.

[philj56]

Alright, I've made the necessary changes to tofi to allow building on Ubuntu 20.04. I've left the [[attribute]] stuff in, as at least clang recognises it, so there is a path to building.

This is more relevant to future packaging considerations than this discussion directly, but I've created tofi-debian-build with some stuff to automatically build a .deb that will work on Ubuntu 20.04 (and should be trivially changeable to other versions / Debian). This is then uploaded as an artifact on the actions page. Currently it's just set to pull from a ubuntu-packaging-2 tag I've made, but it's set up ready to do each version.

@microo8, if you want to give the package from the latest run a go, that might let you use tofi in the short-term (until the next Freedesktop SDK release), and should hopefully work fine apart from the behaviour I mentioned before.

[microo8]

@philj56 wow it works great! Although it look weird :) But the fullscreen theme looks OK.

So for the flatpak version we need to wait a bit.

[philj56]

Cool, good to know! The latest run should also fix the anchoring.

[philj56]

@microo8 Freedesktop-SDK 22.08 is out now, and I've got the following somewhat working on Ubuntu 20.04 (based on your file):

app-id: com.github.philj56.tofi
runtime: org.freedesktop.Platform
runtime-version: "22.08"
sdk: org.freedesktop.Sdk
command: tofi

finish-args:
  - --filesystem=xdg-config/tofi:ro
  - --socket=wayland

modules:
  - name: tofi
    buildsystem: meson
    sources:
      - type: archive
        url: https://github.com/philj56/tofi/archive/refs/tags/v0.5.0.zip
        sha256: 5b92e4152cc086bd8cc97ef62c085773751e92998e4c7b3c5246e82ded4e7af2

I had to remove the -Dbuild_man=true to build, not sure whether that's some local change you made. As far as I know, it should be -Dman-pages=enabled, but scdoc isn't available in the freedesktop sdk.

Additionally, tofi-run and tofi-drun (via flatpak run --comand=tofi-[d]run com.github.philj56.tofi) don't work. tofi-run gives a list of binaries installed within the container, and tofi-drun gives no options at all. I couldn't get them to work with just some quick tinkering - even specifying --filesystem=host:ro doesn't work, as the environment variables $PATH and $XDG_DATA_DIRS aren't set "correctly" (i.e. pointing toward the host locations). I'm not sure if this can be fixed.

[microo8]

Yes I played with it also, but no luck with running tofi-drun. The env vars and filesystem access could be fixed, but running the internal commands is harder.

[philj56]

Ok, so I did some more playing around, and it is possible through a very ugly hack. Using the following file (same as above but updated & with --filesystem=host:ro):

app-id: com.github.philj56.tofi
runtime: org.freedesktop.Platform
runtime-version: "22.08"
sdk: org.freedesktop.Sdk
command: tofi

finish-args:
  - --filesystem=xdg-config/tofi:ro
  - --filesystem=host:ro
  - --socket=wayland

modules:
  - name: tofi
    buildsystem: meson
    sources:
      - type: archive
        url: https://github.com/philj56/tofi/archive/refs/tags/v0.6.0.zip
        sha256: d3b5b1f8bea95e6eede38d74656069bd026d6cc4c611efd55c2e768ec84571a3

I can get tofi-drun / tofi-run working properly with the following command:

flatpak run \
        --command=tofi-drun \
        --env=XDG_DATA_DIRS="/run/host/$(echo $XDG_DATA_DIRS | sed 's|:|:/run/host/|g')" \
        --env=PATH=/app/bin:/run/host/"$(echo $PATH | sed 's|:|:/run/host/|g')" \
        com.github.philj56.tofi

It's basically just prepending /run/host/ to every item in $XDG_DATA_DIRS and $PATH. This still doesn't allow tofi to see programs installed via snap, as the desktop files for those end up in /var and binaries in /snap, neither of which get mounted with --filesystem=host.

Hopefully there's a nicer way of achieving this, but I don't think it's likely.