flatpak: Add a build manifest

[bochecha]

With this one can build Dino from master with flatpak-builder.

---

If you want to try this out, follow this procedure:

1. install Flatpak and add the Flathub repository (see instructions)
2. install the flatpak-builder package
3. checkout this branch, then build and install Dino:

   $ flatpak-builder --install-deps-from=flathub --install --force-clean --ccache app im.dino.Dino.json
   

4. you can now run Dino from your desktop by clicking on the icon, or with the command line:

   $ flatpak run im.dino.Dino
   

---

Do note that OpenPGP will not work with this build. That's because the app is sandboxed and as such doesn't have access to ~/.gnupg/.

I didn't grant it access because the only way to make this work (that I could find) is to give the app read-write access to the whole ~/.gnupg/ folder, which is a pretty big security hole.

It's not worse than non-sandboxed apps of course (they can do whatever they want anywhere in your home directory), so if you feel like the functionality is more important than the security concern (and it probably is… what good is security if you can't do anything?) then I'm happy to edit this pull requestand make it work.

I do think it's important to consider the problem and think about it though, which is why I didn't do it in the initial submission.

---

One thing that can be done with this is to have a server somewhere build the Flatpak every time the master branch is updated, and publish the app in a repo somewhere under https://dino.im/.

I'll be happy to help set this up if you're interested (it requires a few more steps than I detailed above), but this would probably come later, let's not get ahead of ourselves.

Alternatively, once Dino has a release I volunteer to get it on Flathub, if that's what you want. 🙂

[bochecha]

I forgot to mention that I've been using Dino as a Flatpak since at least November 2017. It's working great.

I have it in a personal repository (use at your own risk, this is mostly for me to test stuff out, I do not provide any support for this repository) :

$ flatpak remote-add bochecha https://www.daitauha.fr/static/flatpak/bochecha.flatpakrepo
$ flatpak install bochecha im.dino.Dino

(If you're wondering why I didn't submit this earlier, I had to wait for pull requests #220, #221, #231 and #236 to be merged first. 🙂 )

[barthalion]

Instructions for flatpak-builder could be probably somewhat simplified. SDK dependency can be installed automatically with --install-deps-from=flathub and application installed after build with --user --install. But besides this nitpick, looks good!

About storing builds somewhere, I think @TingPing was experimenting with using Travis for Citra emulator, but I'm not sure how it went.

[bochecha]

@barthalion thanks! I didn't know about --install-deps-from and --install I simplified the test instructions. Much nicer. 🙂

[TingPing]

About storing builds somewhere, I think @TingPing was experimenting with using Travis for Citra emulator, but I'm not sure how it went.

They kinda went silent for now. But the conclusion was that if you have a http server that you can copy the output artifact to and run a command on (so an isolated docker image probably) then it is pretty simple to do.

[mar-v-in]

@bochecha thanks for your work so far.

I think we should wait for flatpak adding support for a --socket=gpg-agent functionality. This was discussed several times in different issues in the flatpak community, but it might be a good idea to create a dedicated issue for it in the flatpak repo. Recently --socket=ssh-agent support was merged, so I guess it shouldn't be too hard to add gpg-agent for them.

This would be the only clean solution for the gpg issue. I dislike the idea of disabling gpg support inside the flatpak (as users will wonder why it doesn't work for them but does work for others) and as gpg now places its socket outside ~/.gnupg on some systems, just forwarding ~/.gnupg alone won't work in all cases. We would be required to start another gpg-agent inside the container which really seems to be the wrong approach to me.

What do you think?

[bochecha]

@mar-v-in I think waiting for --socket=gpg-agent would be the right thing to do, but:

1. I don't think we need to wait for it before we start reviewing this Flatpak manifest, testing it, etc… So I'd still like some feedback anyway. 🙂

2. let's make sure an issue is opened upstream Flatpak for GPG handling (I'll try and do that) so that we don't wait forever in vain.

[fiaxh]

I opened an issue for flatpak a while back: #2301: gpg-agent socket.

[phako]

Btw. with the 3.30 runtime this fails to install the libgee girfile:

 /usr/bin/install -c -m 644 Gee-0.8.gir '/usr/share/gir-1.0'
/usr/bin/install: cannot create regular file '/usr/share/gir-1.0/Gee-0.8.gir': Read-only file system

Not sure why, but in Shotwell I just disable introspection for gee. it's not necessary for building vala projects.

[bochecha]

@phako yeah, that's a classic issue we've been having for a while, since FDO//18.08 switched to pkgconf as the pkg-config implementation.

This is the root of the issue: https://git.dereferenced.org/pkgconf/pkgconf/issues/2

This is one way to work around it: https://gitlab.gnome.org/GNOME/gnome-contacts/merge_requests/26/diffs

But that's just as much a workaround as using the env vars in the first place, so I'm looking at fixing it properly once and for all now.

[bochecha]

Latest push to this branch now builds with GNOME Sdk 3.30.

[Mikaela]

Hi, are there any news on getting Dino officially to Flatpak? I am trying Dino again due to Gajim's issue with unscrollable MUC lists and I am encountering just a few issues:

• OMEMO wasn't selectable for one contact, but apparently I wasn't in their roster and when they scanned my QR that got fixed.
• #98 / #299 as open windows are distracting even if I sent them to workspace 10
• I am not able to type ` and similar characters for using fcitx, because the flatpak is missing permission --talk-name=org.freedesktop.portal.Fcitx and I was able to workaround it with flatpak override --user --talk-name=org.freedesktop.portal.Fcitx im.dino.Dino (flatpak override --user --talk-name=org.freedesktop.portal.Fcitx im.dino.Dino)

Would it be possible to have an update to the current repository in case there have been fixes since January @bochecha ? Thank you for maintaining it and in advance 💜

I prefer to use the Flatpak as Flatpaks generally seem to be more likely to receive updates timely than distribution versions and the current version of Dino in Debian is from 20181129 and thus even older.

By the way it looks like there is also org.gnome.Platform 3.32 in addition to the 3.30 which is previously mentioned here.

[bochecha]

Hi, are there any news on getting Dino officially to Flatpak?

This is still blocked on the same thing, as mentioned in #343 (comment).

There are still 3 options:

• wait for Flatpak to gain --socket=gpg-agent
• poke a hole in the sandbox so Dino has read-write access to the right paths (where the gpg agent socket is)
• accepts disabling GPG functionality in the flatpak

So far the Dino team has chosen the first option, which is perfectly reasonable. They may reevaluate at some point, and if they do I'm sure there would be activity in this pull request. As you can see there hasn't been any, so this is still the status quo.

Would it be possible to have an update to the current repository in case there have been fixes since January @bochecha ?

I do not use XMPP any more, and as such am not really interested in Dino any more. I want to state that this is through no fault of the Dino developers: Dino is without a doubt the best XMPP client I have ever used.

But as a result, I'm not going to keep updating the repository any more.

I'm happy to follow up with this pull request until it gets merged, though. 🙂

[Peque]

@bochecha Isn't that already supported? flatpak/flatpak#1438

Nevermind, I just realized you were saying gpg-agent, not ssh. 😅

[bochecha]

@Peque well, no, that closed issue is about the SSH socket, not the GPG one. 😕

[rugk]

Any news here? Why not just merge this and publish it?

[bochecha]

Any news here? Why not just merge this and publish it?

Please read the rest of the conversation before asking the same question.

#343 (comment)

[rugk]

But I don't need gpg-agent support. This would only be useful when you actually use pgp to encrypt messages, would not it?
AFAIK, dino anyway implements OMEMO as a first-citizen e2e encryption and thus pgp is only used as a fallback for those, who want it.

That's why IMHO, you don't really need to wait, do you? And if the dino devs really want to have this feature for a stable version, then why not release the current version without gpg support as "beta" or so?

[bochecha]

@rugk you're not bringing any new arguments to this discussion that haven't been considered previously. All you're doing is adding noise to this page, making it longer and harder to find anything in it. Please stop.

Issues and pull requests are a work place, not a discussion forum. If you want to try and convince people, do it in the discussion forum: the chat@dino.im room on XMPP.

As I said previously, I don't use Dino any more, but since I started this I'd like to finish it instead of disappearing. Every time someone asks the same question again when the answer is already clearly stated in this page, my motivation shrinks a bit more.

I listed earlier the 3 possibilities to make progress on this:

1. wait for Flatpak to gain --socket=gpg-agent
2. poke a hole in the sandbox so Dino has read-write access to the right paths (where the gpg agent socket is)
3. accepts disabling GPG functionality in the flatpak

The maintainers chose number 1, so we're waiting. Until that changes and either 2 or 3 (or a 4th option I could have missed) is chosen there is absolutely nothing of value to add.

To the maintainers: given all the above I'm going to unsubscribe from this pull request. Do @-mention me when the time has come to resume work on this and I will gladly help push this forward. 🙂

[rugk]

In which flatpak issue is gpg agent functionality requested/tracked?

[TingPing]

flatpak/flatpak#2301

[Kekun]

You will need something like this now:

        {
            "name": "libsignal-protocol-c",
            "buildsystem": "cmake-ninja",
            "builddir": true,
            "config-opts": [
                "-DBUILD_SHARED_LIBS=true"
            ],
            "sources": [
                {
                    "type": "archive",
                    "url": "https://github.com/signalapp/libsignal-protocol-c/archive/v2.3.2.tar.gz",
                    "sha256": "f3826f3045352e14027611c95449bfcfe39bfd3d093d578c70f70eee0c85000d"
                }
            ]
        },

[phako]

libsignal-protocol-c master seems to have some memleak fixes that sound worth including

[phako]

But on the bright sight, if you switch the runtime to 3.36 you can remove libgee from the flatpak

[Kekun]

libsignal-protocol-c master seems to have some memleak fixes that sound worth including

I picked that one because Dino master requires that very specific version apparently.

[selurvedu]

What do you think of disabling OpenPGP for Flatpak builds?

It's just a plugin that may be easily disabled when compiling Dino by a single CMake option -D DINO_PLUGIN_ENABLED_openpgp=no. I did not find any hard-coded references to it in the sources. If my observation is correct and Dino doesn't depend on it in any way, then disabling it should be totally safe.

In my humble opinion, having a usable Flatpak build now, even with a missing feature, wold be better than not having any builds at all for a few more years.