Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Anaconda update breaks KDE if it's added to PATH #1206

Closed
awehrfritz opened this issue Oct 31, 2016 · 27 comments

Comments

Projects
None yet
9 participants
@awehrfritz
Copy link

commented Oct 31, 2016

After updating anaconda (in particular the switch from qt4 to qt5), I'm not able to login to my KDE desktop anymore. After entering my password, a X-window pops up saying:
"Could not start D-bus. Can you call qdbus-qt5?"

A workaround is to simply comment out the line in .bashrc that adds anaconda to the path, but obviously anaconda is then not usable anymore.

If it is really necessary that anaconda ships it's own version of the qt5 libraries, then you should make sure that these libraries and programs don't take precedence over the system libraries for anything else but anaconda.

This issue has also been discussed in the openSUSE forums:
https://forums.opensuse.org/showthread.php/520628-Could-not-start-D-bus-Can-you-call-qdbus-qt5

My system:
openSUSE Leap 42.1 (x86_64)
Qt 5.5.1 (built against 5.5.1)
KDE Frameworks 5.21.0

conda info:

           platform : linux-64
      conda version : 4.2.11
   conda is private : False
  conda-env version : 4.2.11
conda-build version : 1.20.0
     python version : 2.7.12.final.0
   requests version : 2.11.1
   root environment : /home/user/anaconda2  (writable)
default environment : /home/user/anaconda2
   envs directories : /home/user/anaconda2/envs
      package cache : /home/user/anaconda2/pkgs
       channel URLs : https://repo.continuum.io/pkgs/free/linux-64
                      https://repo.continuum.io/pkgs/free/noarch
                      https://repo.continuum.io/pkgs/pro/linux-64
                      https://repo.continuum.io/pkgs/pro/noarch
        config file : None
       offline mode : False

@awehrfritz awehrfritz changed the title Anaconda update breaks breaks KDE Anaconda update breaks KDE Oct 31, 2016

@ccordoba12

This comment has been minimized.

Copy link

commented Oct 31, 2016

What if you create a symlink to Anaconda qdbus in ~/anaconda/bin called qdbus-qt5? That solves the problem for you?

@ccordoba12

This comment has been minimized.

Copy link

commented Oct 31, 2016

Could you ask in the Open Suse forums if the solution is for us to remove qtpaths? Thanks!

@ccordoba12 ccordoba12 changed the title Anaconda update breaks KDE Anaconda update breaks KDE if it's added to PATH Oct 31, 2016

@ccordoba12

This comment has been minimized.

Copy link

commented Oct 31, 2016

you should make sure that these libraries and programs don't take precedence over the system libraries for anything else but anaconda.

We leave that decision to users in our installer.

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Oct 31, 2016

If it is really necessary that anaconda ships it's own version of the qt5 libraries ..

It is really necessary, yes. Binary compatibility requires that we build these things and we cannot use the distro supplied versions in general because the distros are all too different, i.e. if we were to compile PyQt against SUSE linux's Qt5 libraries, then that PyQt would not work on CentOS, Fedora, Ubuntu or Debian (in fact it would likely only work on the SUSE linux that we compiled it against).

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Oct 31, 2016

In this case, SUSE should not run an arbitrary qtpaths, instead, as these are system packages that know exactly where they should live, it should run explicitly /usr/bin/qtpaths.

@awehrfritz

This comment has been minimized.

Copy link
Author

commented Nov 1, 2016

Thanks for the quick response!

I tested removing qtpaths from ~/anaconda2/bin and this fixes the problem. In fact, I consider this a rather clean solution, as I assume that anaconda packages only require the qt libraries and never utilize qtpaths. The further, since only ~/anaconda2/bin is added to PATH and no lib directory to LD_LIBRARY_PATH, the Qt libraries from anaconda don't take precedence over the system libraries otherwise.
To be clear, I tested the login to KDE as well as anaconda, i.e. I generated a simple plot using matplotlib with the Qt5Agg backend.

@awehrfritz

This comment has been minimized.

Copy link
Author

commented Nov 1, 2016

@ccordoba12 I am aware of the fact that this issue only occurs if anaconda is in PATH, but I would say that that's the standard case for most anaconda users, hence I consider this relevant to a wide user base.

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

qtpaths is useful for people who want to develop software using the conda Qt package. The bug lies in openSUSE somewhere as it should explicitly reference /usr/bin/qtpaths (because the software knows that is where the qtpaths that it wants is located) and not just use the first one found in PATH.

Personally, I do not recommend anyone adding a non-system software distribution to their system PATH. It is much more sensible to change environment in a more localized, deliberate way.

@awehrfritz

This comment has been minimized.

Copy link
Author

commented Nov 1, 2016

If it is really necessary that anaconda ships it's own version of the qt5 libraries ..

It is really necessary, yes. ...

Fair enough! I see your point regarding the various versions of Qt shipped for various distributions and operating systems.

@mingwandroid, I will bring up your suggestion to run /usr/bin/qtpaths instead of qtpaths in the openSUSE forums. Maybe they will come up with a fix.

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

Thanks, I'd like to know what the resolution is.

@awehrfritz

This comment has been minimized.

Copy link
Author

commented Nov 1, 2016

Personally, I do not recommend anyone adding a non-system software distribution to their system PATH. It is much more sensible to change environment in a more localized, deliberate way.

Well, this might be a good way for an occasional python user, but certainly not for an advanced user.
I personally use python (and the anaconda distribution) extensively and have dozens of terminal windows with various ipython sessions open during a regular workday. My workflow would be seriously disturbed if I was to add manually anaconda to PATH every time I start a new session.

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Nov 1, 2016

I am not suggesting manually typing export PATH= (or better <CONDA_INSTALL_LOCATION>/bin/activate root) each time you want to use Anaconda Python. I use a shell script that takes very few characters to source (e.g. . ~/mc). I could also call that from a .desktop file to allow launching it from a desktop launcher but I haven't bothered to do that yet.

@ccordoba12

This comment has been minimized.

Copy link

commented Nov 2, 2016

@mingwandroid, what about renaming our qtpaths to qtpaths-qt5?

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Nov 2, 2016

I'll do that if we have to.

@awehrfritz

This comment has been minimized.

Copy link
Author

commented Nov 2, 2016

The openSUSE developers agreed to add the absolute path to the places where qtpaths is invoked, this should fix the problem.
Though I should note that the openSUSE developers were not too happy with this solution either, so this may come up again some day. Anyway, here the link to the discussion with the openSUSE developer:
https://forums.opensuse.org/showthread.php/520628-Could-not-start-D-bus-Can-you-call-qdbus-qt5?p=2798385#post2798385

Thanks for your effort and the proposed workaround for this issue!

@awehrfritz awehrfritz closed this Nov 2, 2016

@duckdodger

This comment has been minimized.

Copy link

commented Nov 6, 2016

I'd like to point out that this issue is not exactly because of openSUSE but rather it's KDE. KDE Plasma uses a startkde script for starting Plasma which looks for the first instance of qtpaths in PATH, so it finds the Anaconda version of qtpaths and loads it.
Then it looks for qdbus-qt5 (which is how qdbus is named in openSUSE to avoid conflict with the qt4 version) in the path set by qtpaths but it fails to find it because that's not how qdbus is named in Anaconda and throws an error.

So the patch that is being applied by openSUSE to hardcode the path to qtpaths in startkde is just a workaround. Their opinion is that it can't be fixed upstream (by KDE) either because qtpaths is a way for Plasma to be independent of where the Qt5 libraries are installed (which is kinda ironic), that is, someone may choose to install Qt5 elsewhere other than /usr/bin.

Also, if qtpaths is used by something else, that also has the potential to break due to not finding the right qt5.

@LeonhardtAndreas

This comment has been minimized.

Copy link

commented Apr 23, 2018

My workaround is to check if I am in an interactive shell before including the Anaconda path in the bashrc, since I use Anaconda from the terminal only. The test can be done by checking for a prompt variable by adding the two lines around the export statement:

if [ ! -z $PS1 ]; then
    export PATH="<path-to-anaconda-bin>:$PATH"
fi

or by testing for i in $-.

@msarahan

This comment has been minimized.

Copy link
Member

commented Apr 23, 2018

@LeonhardtAndreas that is actually an excellent improvement in my opinion, and I'll recommend internally that we add this to our installers.

@mingwandroid

This comment has been minimized.

Copy link
Member

commented Apr 23, 2018

since I use Anaconda from the terminal only

but what about people who use it for all their software needs? We're moving away from recommending modifying PATH (or even setting it at all) and having conda as a shell function anyway aren't we?

@durack1

This comment has been minimized.

Copy link

commented May 1, 2018

Folks FYI this is also a problem on redhat6, I've been pulling my hair out for two days trying to get to the bottom of this, and sure enough, renaming ~/anaconda2 -> ~/anaconda2-arrrrgh solved my problem.

Automatically dropping ~/anaconda2/bin as the first entry in the PATH is going to break many things, and I would advocate it gets moved after a number of the system paths are defined

@doutriaux1 @bonfils2 @gleckler1 @hoang1

@doutriaux1

This comment has been minimized.

Copy link

commented May 1, 2018

@durack1 the newer way to do things in conda is to have nothing added in PATH, instead it sources a special bash file that defines a conda function. Of course you're not going to like like because it means no tcsh for you 😉

@durack1

This comment has been minimized.

Copy link

commented May 1, 2018

@doutriaux1 got a link describing this new way?

@mingwandroid

This comment has been minimized.

Copy link
Member

commented May 1, 2018

I would advocate it gets moved after a number of the system paths are defined

That won't work either. Instead of your distro software not working, now Anaconda Distribution software will not work. @kalefranz do you have a good reference for the new way?

@durack1

This comment has been minimized.

Copy link

commented May 1, 2018

So other folks don't pull their hair out as long as I did, here are the errors contained in the vnc log for the two environments (which can be switched by creating/editing the ~/.Xclients file, e.g. below):
GNOME2:

[duro@ocean ~/.vnc]$ more ~/.vnc/machineName:1.log
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

Xvnc TigerVNC 1.7.1 - built Jan 19 2017 18:38:20
Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 11704000, The X.Org Foundation

Tue May  1 13:44:32 2018
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on all interface(s), port 5901
 vncext:      created VNC server for screen 0
gnome-session[11015]: WARNING: Could not make bus activated clients aware of DISPLAY=:1 environment variable: Failed to connect to socket /tmp/dbus-CrmwEz22xX: Connection refused
gnome-session[11015]: WARNING: Could not make bus activated clients aware of GNOME_DESKTOP_SESSION_ID=this-is-deprecated environment variable: Failed to connect to socket /tmp/dbus-
CrmwEz22xX: Connection refused
gnome-session[11015]: WARNING: Could not make bus activated clients aware of SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/11015,unix/unix:/tmp/.ICE-unix/11015 environment variable: Fa
iled to connect to socket /tmp/dbus-CrmwEz22xX: Connection refused

And on the login screen when trying to connect using a vnc client:

Could not connect to session bus: Failed to connect to socket /tmp/dbus-a46yWcaPVt: Connection refused

Switch from redhat default GNOME to KDE:

[duro@ocean ~]$ more .Xclients
#exec startx ; # In theory this reverts to GNOME
exec startkde ; # KDE shell

And KDE:

[duro@ocean ~/.vnc]$ more ~/.vnc/machineName:1.log
_XSERVTransmkdir: Owner of /tmp/.X11-unix should be set to root

Xvnc TigerVNC 1.7.1 - built Jan 19 2017 18:38:20
Copyright (C) 1999-2016 TigerVNC Team and many others (see README.txt)
See http://www.tigervnc.org for information on TigerVNC.
Underlying X server release 11704000, The X.Org Foundation

Tue May  1 13:47:28 2018
 vncext:      VNC extension running!
 vncext:      Listening for VNC connections on all interface(s), port 5901
 vncext:      created VNC server for screen 0
startkde: Starting up...
startkde: Could not start D-Bus. Can you call qdbus?
@doutriaux1

This comment has been minimized.

Copy link

commented May 2, 2018

@durack1 for example see: https://stackoverflow.com/questions/47246350/conda-activate-not-working?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa

but the nitty gritty is the following message on newer conda:

CommandNotFoundError: Your shell has not been properly configured to use 'conda activate'.
If your shell is Bash or a Bourne variant, enable conda for the current user with

    $ echo ". ~/anaconda/etc/profile.d/conda.sh" >> ~/.bash_profile

or, for all users, enable conda with

    $ sudo ln -s ~/anaconda/etc/profile.d/conda.sh /etc/profile.d/conda.sh

The options above will permanently enable the 'conda' command, but they do NOT
put conda's base (root) environment on PATH.  To do so, run

    $ conda activate

in your terminal, or to put the base environment on PATH permanently, run

    $ echo "conda activate" >> ~/.bash_profile

Previous to conda 4.4, the recommended way to activate conda was to modify PATH in
your ~/.bash_profile file.  You should manually remove the line that looks like

    export PATH="~/anaconda/bin:$PATH"

^^^ The above line should NO LONGER be in your ~/.bash_profile file! ^^^
@durack1

This comment has been minimized.

Copy link

commented May 3, 2018

@dnadeau4 ping

@zeus86

This comment has been minimized.

Copy link

commented Mar 28, 2019

Thanks for debugging this, this really helped me out today.

One further note:
You should pay attention to this issue, when e.G. spawning a second X from a getty.
While a login-manager starts a KDE just fine, it will still fail in this context, when trying to spawn a second X from a getty-terminal or so manually, because this would be an interactive terminal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.