Evolution doesn't run

[jrmoserbaltimore]

• A brief description

Evolution doesn't work.

• Expected results

Evolution should start and run properly.

• Actual results (with terminal output if applicable)

Evolution produces a dialogue box claiming "error sending credentials".

• Your Windows build number

Anniversary edition

• Steps / commands required to reproduce the error

sudo apt-get install evolution evolution

• Required packages and commands to install

Xming, as installed by 'choco install xming' if you have chocolatey (via powershell).

Ensure DISPLAY=:0.0 by adding the following to ~/.bashrc:

export DISPLAY=:0.0

[fpqc]

Two things, have you set dbus to listen on TCP, and have you tried vcXsrv?

Also, there is atm no official support for gui applications, and some require a number of hacks (for example, getting gtk applications running properly requires a few hacks, including the dbus fix and also running unity-settings-daemon)

[iz0eyj]

I think that at the present only XFCE runs fine (ignoring warnings).

[sunilmut]

With better support for AF_LOCAL socket, dbus seems to be happy and evolution also works. Fixes are moving fast to the release build. Keep an eye on the release notes.

[jrmoserbaltimore]

Yeah the problem appears to be I'm not using dbus/tcp, just default settings. I'm using xming, which is working for many things; however, if you forward X over ssh, you have to use an IP address DISPLAY value instead of :0.0.

Looking forward to this fix. AF_LOCAL/AF_UNIX should provide a huge step up in general.

[fpqc]

@bluefoxicy Don't forward X over ssh. Launch the X applications directly from your bash console in Windows with DISPLAY=:0 (remote X). The dbus fix was necessary because GTK applications all require dbus connections (I'm not positive, but one of the reasons they do this is because they connect to the GTK resources through dbus and the settings daemon through dbus).

WSL does not have access to graphics hardware (yet, although maybe we can hope for some kind translation layer for DRM to WDDM), so you're still going to need to do both X over TCP and AIGLX/Software rendering, and since vcXsrv does not properly implement texture_from_pixmap, most GTK3 is going to actually fall back to software rendering, with the substantial performance hit that entails.

Eventually, once they document and add security features on the Windows-side of the COM interface (right now, accessing it from the Windows side requires Administrator elevation), it will be possible to attach a special kind of daemon with a socket on the Linux side (imagine something like a bridge between dbus and the LXSS bus) and an X server on the Windows side (vcXsrv would have to learn how to interface with dbus, probably) to the LXSS bus, which would finally mean you no longer had to set DISPLAY=:0 (see Alex Ionescu's lxss repo on github for a proof of concept). However, the benefits of this would not be that huge in terms of performance by itself.

The team hasn't given any information about implementing a DRM layer for WSL, but maybe more information will emerge as the team begins to reach some of their internal milestones (since it looks like they are aiming to have a 1.0 release with Redstone 2 later this year, and therefore they are still really focusing hard on the non-graphical use case).

[iz0eyj]

@sunilmut OK Sunil, please check also Socket Shutdown.

[sunilmut]

Just FYI that most or all of the AF_LOCAL fixes should be available starting build 14915. We would appreciate if you can try out the scenarios again without the dbus workaround and close out the issues. The only changes required to start the dbus daemon is in /etc/init.d/dbus, changing

from: DAEMON=/usr/bin/dbus-daemon UUIDGEN=/usr/bin/dbus-uuidgen

to: DAEMON=/bin/dbus-daemon UUIDGEN=/bin/dbus-uuidgen

then: sudo /etc/init.d/dbus start should work.

[fpqc]

@sunilmut There is still a problem with some of these things relating to dbus authentication, so it might be necessary to still edit the dbus file to use dbus cookies instead of "external" authentication.

[sunilmut]

@fpqc I wasn't aware of that issue with dbus, thanks for bringing it to my notice. Are these problems documented somewhere (or on some git hub post)? I would like to understand them better.

[fpqc]

@sunilmut Check here

https://github.com/microsoft/bashonwindows/issues/637 https://github.com/Microsoft/BashOnWindows/issues/482

In the second thread, @therealkenc mentions exactly what the problem is. It has to do with some kind of authentication used by dbus, and I'm not sure if it's a sockets problem or some kind of unimplemented syscall that does the authentication step.

I pinged Ken because maybe he'll give you the details on all of this stuff. I'm not even sure what it is, just that it can cause minor dbus-related problems. The thing is that it was something that was usually ignored when you turned dbus into tcp mode, since it automatically falls back to the cookie authentication in that case.

[therealkenc]

@sunilmut this is #706. I mentioned d-bus here. That issue is also blocking other stuff, including some uses of GIO/GTK which I just discovered yesterday.

[therealkenc]

I should mention much of the point of the system bus is to talk to systemd on PID 1, which WSL doesn't have because of other missing surface (udev). So while you can connect to the system bus over AF_LOCAL with the steps you describe, the actual reason a program connects to it is not functional. Nice progress though.