GNOME Bugzilla – Bug 786783
Add flatpak build configuration for Empathy
Last modified: 2018-05-22 19:18:18 UTC
To help with testing, building, and to isolate a process that receives data over the network it'd be nice to have a flatpak build for Empathy. This came up in bug #749001 There was some concern how telepathy would work over dbus between the host OS and the containerized application. But it was pointed out that Polari has a flatpak build as "prior art". So I started. It turns out Polari is actually building and shipping telepathy components. (Telepathy-logger, telepathy-mission-control, telepathy-glib, telepathy-idle) I copied what they did and and added telepathy-gabble and its dependencies. I'm still working my way through Empathy's additional dependencies.
empathy depends on libfolks, which then wants to talk to evolution data server, and I'm not sure how that would work while containerized.
Created attachment 358738 [details] [review] patch empathy to use org.gnome.Empathy.desktop
Created attachment 358739 [details] [review] Update icon name to org.gnome.Empathy
Created attachment 358740 [details] [review] Copy flatpak specific patches for telepathy from Polari
Created attachment 358741 [details] [review] patch to build Gee-0.8 in flatpak
Created attachment 358742 [details] [review] flatpak manifest Initial manifest. This probably will still need to be updated. I was able to launch Empathy via flatpak. Though there were some dbus errors like: (process:3): empathy-CRITICAL **: Failed to register Observer: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown (empathy:3): folks-WARNING **: Failed to find primary PersonaStore with type ID 'eds' and ID 'system-address-book'. Individuals will not be linked properly and creating new links between Personas will not work. The configured primary PersonaStore's backend may not be installed. If you are unsure, check with your distribution. (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'EmpathyRosterContact' (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GObject' (empathy:3): GLib-GObject-CRITICAL **: g_object_notify: assertion 'G_IS_OBJECT (object)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkLabel' (empathy:3): Gtk-CRITICAL **: gtk_label_set_text: assertion 'GTK_IS_LABEL (label)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkAlignment' (empathy:3): Gtk-CRITICAL **: gtk_alignment_set: assertion 'GTK_IS_ALIGNMENT (alignment)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkMisc' (empathy:3): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion 'GTK_IS_MISC (misc)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'EmpathyRosterContact' (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GObject' (empathy:3): GLib-GObject-CRITICAL **: g_object_notify: assertion 'G_IS_OBJECT (object)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkLabel' (empathy:3): Gtk-CRITICAL **: gtk_label_set_text: assertion 'GTK_IS_LABEL (label)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkAlignment' (empathy:3): Gtk-CRITICAL **: gtk_alignment_set: assertion 'GTK_IS_ALIGNMENT (alignment)' failed (empathy:3): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GtkMisc' (empathy:3): Gtk-CRITICAL **: gtk_misc_set_alignment: assertion 'GTK_IS_MISC (misc)' failed
Also I wasn't sure if the telepathy services needed to be included in the sandbox or not. Polari seems to include the -idle service, but then delete all the service files that'd make it work.
(In reply to Diane Trout from comment #1) > empathy depends on libfolks, which then wants to talk to evolution data > server, and I'm not sure how that would work while containerized. Yeah, that sounds like a significant challenge. I think the solution is to patch e-d-s to use a bus name specific to the Empathy flatpak. Not sure how hard that would be.
Patches look good to me. Do you want me to push them, or do you want to work more on the remaining bugs first?
Could you push the first 2 patches which modify Empathy to git, so I can point the manifest file back to git.gnome.org? (Though if you want to add the flatpak build patches now that's fine too, I doubt they're going to change) There's a few more things I'd like to tweak in the flatpak manifest file before it gets committed. Is it OK for a flatpak app to talk to the org.gnome.Shell bus? Also where do you go to ask design questions for GNOME? Merging the contact list with the chat list makes me wonder if the chat windows should still be tabbed. Also I don't think I have GNOME developer account, just KDE, Freedesktop, and Debian.
(In reply to Diane Trout from comment #10) > Is it OK for a flatpak app to talk to the org.gnome.Shell bus? I think it would be OK, if the code is prepared to degrade gracefully when running outside GNOME Shell, and when it inevitably breaks its D-Bus API in the future. > Also where do you go to ask design questions for GNOME? Best bet is #gnome-design on irc.gnome.org during European business hours. If you can't get anyone there, next best bet is desktop-devel-list@gnome.org. > Merging the contact list with the chat list makes me wonder if the chat > windows should still be tabbed. > > Also I don't think I have GNOME developer account, just KDE, Freedesktop, > and Debian. If you plan to contribute to Empathy regularly, we can get you one. In the meantime I'm happy to push occasional patches.
By the way, the single-window UI is just an experiment. Whoever winds up maintaining Empathy in the future (could be you if you're not careful!) will have to decide whether to keep it or revert back. I think it's the right direction to go in, but it's not really working well yet, so I did a 3.12.14 release with the traditional UI. Hope it works....
The following fix has been pushed: bb89c04 appFavorites: Add Empathy to rename list
Created attachment 358809 [details] [review] appFavorites: Add Empathy to rename list GUADEC beer to whomever gets a rename field into the desktop entry spec.
The following fix has been pushed: 3afb04e Rename appdata file
Created attachment 358810 [details] [review] Rename appdata file It has to exactly match the desktop file
(In reply to Michael Catanzaro from comment #12) > By the way, the single-window UI is just an experiment. Whoever winds up > maintaining Empathy in the future (could be you if you're not careful!) will > have to decide whether to keep it or revert back. I think it's the right > direction to go in, but it's not really working well yet, so I did a 3.12.14 > release with the traditional UI. Hope it works.... Most of the other popular IM programs I've seen currently follow that convention. Thank you for the commits, and the fix to the appdata file. Before applying for a GNOME git account, lets see if I have the time to implement sort by activity in the contact list.
(In reply to Michael Catanzaro from comment #8) > I think the solution is to patch e-d-s to use a bus name specific to > the Empathy flatpak. I'm not sure I follow. For example GNOME Calendar does build its own eds and it has set those D-Bus services in the list of services: https://git.gnome.org/browse/gnome-calendar/tree/org.gnome.Calendar.json#n15 Is it about that, or it's about anything else?
(In reply to Milan Crha from comment #18) > (In reply to Michael Catanzaro from comment #8) > > I think the solution is to patch e-d-s to use a bus name specific to > > the Empathy flatpak. > > I'm not sure I follow. For example GNOME Calendar does build its own eds and > it has set those D-Bus services in the list of services: > https://git.gnome.org/browse/gnome-calendar/tree/org.gnome.Calendar.json#n15 > > Is it about that, or it's about anything else? Isn't gnome-calendar's e-d-s going to conflict with the system e-d-s?
> Isn't gnome-calendar's e-d-s going to conflict with the system e-d-s? I think the e-d-s tarball produces libraries that are used as build dependencies, looking at the Calendar manifest it looks like all the communication with e-d-s happens over d-bus
Right... that's broken, since the flatpak is supposed to be independent of the host OS.
I'm not used to flatpak (yet), but my understanding is that you usually want to provide stable or development versions to users on "any" system, which means to build as much as possible with certain flatpak SDK or build it yourself. In your case, and in case of other clients of evolution-data-server factories, you want to build eds yourself and use that eds, thus you have guaranteed to run the correct and expected version of it. You might ideally not use host's XDG directories too, because underlying data of the backends could change, like it happened in the past, but also for 3.26. Those eds factories do talk over D-Bus, the C interfaces are using it in the background, though the address books are able to use so called Direct Read Access mode, which means they are accessing the underlying SQLite backend files directly for read purposes only. They still use D-Bus for writing. How to declare these all things in the flatpak builder file I do not know.
(In reply to Michael Catanzaro from comment #21) > Right... that's broken, since the flatpak is supposed to be independent of > the host OS. Is it broken or just different design goals? I was just wanting a clean way of having multiple versions for installed for testing, and I wanted to reuse all my currently existing telepathy accounts, metacontacts, and logs. (Also this implementing it this way is a simpler case) But thinking about how this should work. How should flatpak manage sharing state between flatpak and the host OS? Also bundling all of the telepathy and evolution data services over and over again also seems pretty silly. Is there a way of defining a layers that are reused? I think I saw a hint in the flatpak docks that you could depend on components other than just the .Sdk. I susepct it'd be useful to have a telepathy layer and a e-d-s layer. Especially with something like e-d-s I'd assume you could only have one component managing access to the PIM database. How should you decide if the database is managed by the host OS or the container?
(In reply to Diane Trout from comment #23) > Especially with something like e-d-s I'd assume you could only have one > component managing access to the PIM database. How should you decide if the > database is managed by the host OS or the container? Most of the questions are for flatpak developers, rather than for flatpak users. I'll try to express my point of view for the one above: The situation with for example GNOME Calendar (or bijiben, ...) is that they use eds version X (like git master) to build it, but then they expect the host system to have installed compatible (but not the same) D-Bus services to be able to run the application. That's far from the marketing of flatpak. You want to run the flatpak version both on the recent bleeding edge distro the same as on an LTS version of the distro, which can be several years old. Of course, there is still some limitation on kernel and such, but they are supposed to be fine. With respect of eds, the D-Bus API versions change only if the API changes, not when for example the backend data storage changes, which happened for 3.26. That change adds some value, it allows offline editing in calendars and books. This functionality would be missing in the flatpak version when it depends on the host OS eds version which can have the same D-Bus API versions, but different functionality and its own bugs. Yeah, there are fixed bugs in the eds backends/"server side" too. I made a flatpak version of evolution at the beginning of this week [1]. Evolution is tight to eds, similarly to GNOME Calendar and all the others, but also to the libcamel usage. My intention is to provide consistent behaviour, thus if you use evolution 3.26, then you use also eds 3.26. Thus that flatpak version is completely independent of the host OS eds, it even doesn't share any data with the host OS, it's a pure sandbox. It has its downsides, no sharing means no Online Accounts integration (that's used incorrectly wrong in the flatpak versions of GNOME Calendar and the others), missing notifications (org.freedesktop.Notifications D-Bus interface cannot be reached), but otherwise it won't break your system at all, because it doesn't touch the data in ~/.config, ~/.cache, ~/.local of the host system. I do not say this is the right way to do it, neither it's the only or the best way. The future may come with something better (like being able to use some services in the sandboxed D-Bus session, while being able to use host OS D-Bus services, like the one for notifications. That's either not possible right now, or I do not know how to do it [2]). But in any case, if you want to run up to date evolution on an ancient LTS or you want to try bleeding edge evolution without a fear of garbling your system and dealing with up and down dependencies due to reuse of eds, then it's the way to go. Honestly, flatpak channel motto is "Flatpak - The future of application distribution", but it's not ready for anything but simple standalone applications with no real dependencies and no cooperation between applications/services, like for those accessing eds. Just my opinion. [1] https://git.gnome.org/browse/evolution/commit/?id=c9eba7cc33b0cd0087c96184c513b5362541e6ae [2] I've one idea to try, which will probably not work, but if it will, then I update the script accordingly.
Created attachment 361389 [details] [review] Copy flatpak specific patches for telepathy from Polari
Created attachment 361390 [details] [review] patch to build Gee-0.8 in flatpak
Created attachment 361391 [details] [review] initial flatpak manifest
Created attachment 361392 [details] [review] initial flatpak manifest
Created attachment 361393 [details] [review] use libfolks and e-d-s
Created attachment 361394 [details] [review] Access mapping libraries
Created attachment 361395 [details] [review] Allow dbus access to gnome shell
While I was trying to organize my patches I discovered a couple of additional bus names that Empathy wanted access to, as well as it wanting access to the DRI device while under wayland. I'd previously been having some trouble with the flatpak app mysteriously dying with SIGUSR1, I've made the (uncommitted) fixes described above, and am waiting to see if it'll crash again.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/empathy/issues/902.