Nixpkgs: evolution-ews missing, needed for exchange support

[jerith666]

I've got a working nix expression for evolution-ews in https://github.com/jerith666/nixpkgs/tree/evolution-ews, however:

• I had to patch it to prevent it from trying to install its libs into the evolution and evolution-data-server directories under /nix/store
• Because of that (presumably), when I run evolution, it doesn't offer "Exchange" as a server type.

I'm hoping for some guidance from the gnome maintainers, @jgeerds and @lethalman, about how to get this working. Thanks!

[jerith666]

The closest thing I've found in any other distro's packaging is https://build.opensuse.org/package/view_file/home:dwmw2:evobits/evolution-ews/evolution-ews.spec, which I think lists out the files from evolution-ews that need to be copied in. But my only idea for how to do that is to make new derivation that's just the FS-union of the evolution and evolution-ews packages. (Or maybe the evolution, evolution-data-server, and evolution-ews packages?) Seems like a horrible hack though ...

[bjornfor]

I have interest in this. I also started packaging evolution-ews at one point: https://github.com/bjornfor/nixpkgs/tree/evolution-ews (haven't looked at it in a while).

[jerith666]

I just pushed 3db27f5b, which I feel like is getting closer. In particular I now have some evolution-ews stuff showing up in /run/current-system:

$ find /run/current-system/sw/share | grep evolution-ews | grep -v /locale/
/run/current-system/sw/share/appdata/evolution-ews.metainfo.xml

$ find /run/current-system/sw/lib/evolution | grep ews
/run/current-system/sw/lib/evolution/modules/module-ews-configuration.la
/run/current-system/sw/lib/evolution/modules/module-ews-configuration.so

... however, still no "exchange" in the account setup dropdown ... :(

[lethalman]

@jerith666 you have to understand where does evolution look for modules. If it's only evolution nix store path, or also all the XDG_DATA_DIRS.

Also make sure to always check stdout, stderr and journalctl.

[jerith666]

I don't think it's XDG_DATA_DIRS, at least if I'm understanding that correctly. I didn't know which dir under the evolution-ews store path should be added to that env. var, so I just added all of them, like this:

export XDG_DATA_DIRS=${XDG_DATA_DIRS}:$(find /nix/store/k4asxzcl0xw5148g97217gvdn0kqfvp3-evolution-ews-3.18.4/ -type d | grep -v /locale | tr '\n' ':')
evolution

... and still no "exchange" entry in the account setup dropdown.

I had journalctl -f running while I did this, and didn't see anything informative there or on stdout or stderr.

(I also tried making a copy of the /nix/store/kxs9f1gj4ybvcmjjnxy5fswvk8dbchkg-evolution-3.18.4/bin/evolution bash script and pasting in the new XDG_DATA_DIRS entries; that also didn't work.)

[jerith666]

In case it helps, the dirs that actually got added to XDG_DATA_DIRS are:

$ find /nix/store/k4asxzcl0xw5148g97217gvdn0kqfvp3-evolution-ews-3.18.4/ -type d | grep -v /locale | cut -d / -f 5-100

lib
lib/evolution
lib/evolution/modules
lib/evolution-data-server
lib/evolution-data-server/addressbook-backends
lib/evolution-data-server/registry-modules
lib/evolution-data-server/calendar-backends
lib/evolution-data-server/camel-providers
share
share/evolution
share/evolution/errors
share/evolution-data-server
share/evolution-data-server/ews
share/appdata

[lethalman]

@jerith666 I wasn't clear enough. I think evolution only uses the build-time directory to lookup for modules, which would be /nix/store/kxs9f1gj4ybvcmjjnxy5fswvk8dbchkg-evolution-3.18.4/lib/evolution/modules .
You should check the sources to understand whether this is the case, or do some strace.

If that's the case, I think evolution should be patched to use a list of directories being provided at runtime (like EVOLUTION_MODULES_PATH), instead of just relying on a build-time single directory.

[jerith666]

Not ready to dive into patching evolution sources yet. The next thing I thought to try was using an FHS environment. So that's in the just-pushed ffcf86f3, but it still doesn't work. :-/

[jerith666]

comparing an strace both inside the FHS environment and outside it is somewhat interesting. Outside the FHS env.:

$ strace evolution 2>&1 | grep -v /nix/store | grep /lib | grep evolution | grep -v /opengl-driver
read(12, "volution-3.18.4/lib/evolution/li"..., 1024) = 1024

Inside the FHS env:

$ strace evolution 2>&1 | grep -v /nix/store | grep /lib | grep evolution | grep -v /opengl-driver
open("/usr/lib/tls/x86_64/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/tls/x86_64/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/tls/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/x86_64/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-shell.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-util.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-util.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
read(12, "lib/evolution/libgnomecanvas.so\n"..., 1024) = 1024
open("/usr/lib/libevolution-mail.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-mail.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-calendar.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-calendar.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-mail-composer.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-mail-composer.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-mail-formatter.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-mail-formatter.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-smime.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-smime.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-calendar-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-calendar-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-addressbook-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-addressbook-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libevolution-mail-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib32/libevolution-mail-importers.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)

So it looks like in both cases all of their successful loads come from the evolution and evolution-data-server nix store paths, nothing from the evolution-ews nix store or from any absolute /lib or /usr/lib paths. But in the FHS env, there are at least attempts to load from absolute /lib paths.

[bjornfor]

How big is EWS? Maybe we can just build it _with_ evolution-data-server? That is, build both at the same time and store in the same nix store path.

I guess making EWS work in a separate store path requires patching it, something we can do later as an optimization.

[jerith666]

It's pretty small relative to the rest of evolution.

I thought about this, but I think it would have to be built with _both_ evolution-data-server _and_ evolution, meaning (as I understand it) that those two large builds would have to be unified. At least, the expression I have for evolution-ews currently depends on both.

[bjornfor]

@jerith666: You're right, EWS also depend on evolution. Aaargh!

[bjornfor]

I applied some brute force and created a combined build of evolution-data-server, evolution and evolution-ews all in one nix store path. Now I have working Exchange email + global address list in Evolution. The calendar fails to load though.

https://github.com/bjornfor/nixpkgs/tree/evolution-ews3

(I'm running GNOME3 desktop on NixOS. I'm unsure if it still works if this "super-build" of evolution is run on a system without services.gnome3.evolution-data-server.enable = true.)

Also, I asked upstream about the possibility of loading modules / plugins from external paths: https://mail.gnome.org/archives/evolution-list/2016-May/msg00235.html. Unsurprisingly, it's not possible yet.

[bjornfor]

Pushed a fix to https://github.com/bjornfor/nixpkgs/tree/evolution-ews3 that unbreaks the calendar function (I made some typos earlier regarding install paths for ews plugin).

[bjornfor]

Now the question is, how can this (mess) be upstreamed into NixOS? :-D

[dfbm]

as I need evolution with ews support: is there anything I can do to advance this pull request?

[bjornfor]

@dfbm: "This" is just an issue, not a PR. If you're referring to https://github.com/bjornfor/nixpkgs/tree/evolution-ews3, then that needs a proper patch (that can be accepted upstream, or somehow be fairly maintainable if not accepted upstream) to allow building EWS into a separate path from the other evolution component(s). My hack of a "super build" in that tree isn't particularly nice. But it was the best I could do at the time.

[jerith666]

If you're enough of a gnome hacker to pursue the path of patching upstream to load its plugins from a runtime-specified path, that'd be ideal.

But, IMO, after a year, it's a perfectly fine interim solution if @bjornfor's "super build" gets added to nixpkgs alongside the existing evolution and evolution-data-server nix expressions. Then users can choose for themselves whether they want to sacrifice modularity in order to get this plugin working.

Some work is still needed, since as it stands now the existing evolution and evolution-data-server values are hidden. But I think if we can make it coexist peacefully, we can lobby for including it with a straight face. ;-)

[mickours]

Hi,
Any news on this?
I would like to add evolution-rss plugin based on @bjornfor's fork but I don't know if I can base my work on it to make a PR.

[jerith666]

I haven't done any more work on this myself. I think the minor cleanup I described in my previous comment is probably the minimum necessary before you could get an PR based on it to be accepted. (Though I'm not a committer so I can't say for sure.)

[gilligan]

@jerith666 I just tried to run gnome3.evolution-with-plugins from your fork. Unfortunately it fails because of some opengl symbol x__X

/home/gilligan/.nix-profile/bin/evolution: symbol lookup error: /run/opengl-driver/lib/libGL.so.1: undefined symbol: drmGetDevices2

Would love to give it a try. If I can get it to work i'd love to try to somehow move this forward to land a PR

[jerith666]

@gilligan, that sounds like @bjornfor's work (https://github.com/bjornfor/nixpkgs/tree/evolution-ews3), not mine, that you're trying to run.

Anyway, that's not an error I've seen before, I'm not sure what to make of it.

[jerith666]

Although, the first google hit for libGL.so.1: undefined symbol: drmGetDevices2 is your #26617 @gilligan ... could it be that you're in a similar situation with mismatched system and user packages again?

[steveeJ]

Is there an expression that works with evolution 3.28?

[jerith666]

I haven't done any work on this recently, so nothing from me, no. :(

[stale[bot]]

Thank you for your contributions.

This has been automatically marked as stale because it has had no activity for 180 days.

If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.

Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the related code and @ mention them in a comment.
2. Ask on the NixOS Discourse.
3. Ask on the #nixos channel on irc.freenode.net.