search

ContinuumIO / anaconda-issues

Anaconda issue tracking
648 stars 222 forks source link

Anaconda 4.4 to 5.0 update breaks KDE if it's added to PATH #6439

Open bscipio opened 7 years ago

bscipio commented 7 years ago

Hello, Issue #1206 is occurring again after an Anaconda 4.4 to 5.0.0.1 update.

This update breaks KDE if anaconda is added to $PATH I previously was using Anaconda 4.4 in my $PATH without issues.

Issue occurs despite a manual edit to /usr/bin/startkde script to explicitly point to /usr/bin/qtpaths & /usr/bin/qdbus-qt5. This edit was is mentioned in previous reported issue #1206 and in OpenSUSE forum posts below. (It doesn't appear the absolute path update is in OpenSUSE 42.3)

Also tested a completely fresh download & install on anaconda 5.0 and 4.4 and can confirm same behavior. (5.0 can't login, 4.4 ok)

My System

OpenSUSE forums:

conda info

platform : linux-64
conda version : 4.3.27
conda is private : False
conda-env version : 4.3.27 conda-build version : 3.0.23 python version : 2.7.13.final.0 requests version : 2.18.4 root environment : /home/user/sandbox/anaconda2 (writable) default environment : /home/user/sandbox/anaconda2 envs directories : /home/user/sandbox/anaconda2/envs /home/user/.conda/envs package cache : /home/user/sandbox/anaconda2/pkgs /home/user/.conda/pkgs channel URLs : https://repo.continuum.io/pkgs/main/linux-64 https://repo.continuum.io/pkgs/main/noarch https://repo.continuum.io/pkgs/free/linux-64 https://repo.continuum.io/pkgs/free/noarch https://repo.continuum.io/pkgs/r/linux-64 https://repo.continuum.io/pkgs/r/noarch https://repo.continuum.io/pkgs/pro/linux-64 https://repo.continuum.io/pkgs/pro/noarch config file : /home/user/.condarc netrc file : None offline mode : False user-agent : conda/4.3.27 requests/2.18.4 CPython/2.7.13 Linux/4.4.79-4-default openSUSE /42.3 glibc/2.22
UID:GID : 1000:100

Let me know what else is needed. Thank you!

mingwandroid commented 7 years ago

You really should not add conda to your PATH like this. Use the activate script when you want to use conda, or else add it to your non login shells only.

bscipio commented 7 years ago

Thank you for the reply. If this should not be done, why does the anaconda installation offer to the add to $PATH?

I still don't understand what changed between 4.4 and 5.0 to cause this issue to appear in 5.0. I think the root cause should at least be understood.

mingwandroid commented 7 years ago

The root cause is incompatibility between system tools and libraries and Anaconda's tools and libraries. I would like to remove the option to add to PATH or at least issue a strong warning about it.

On Oct 6, 2017 12:23 PM, "bscipio" notifications@github.com wrote:

Thank you for the reply. If this should not be done, why does the anaconda installation offer to the add to $PATH?

I still don't understand what changed between 4.4 and 5.0 to cause this issue to appear in 5.0. I think the root cause should at least be understood.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ContinuumIO/anaconda-issues/issues/6439#issuecomment-334728414, or mute the thread https://github.com/notifications/unsubscribe-auth/AA_pdM_zui2kfS2XPpWxH5EtMZTFmbmMks5spg2ygaJpZM4Pv3wQ .

bscipio commented 7 years ago

Thanks for the non-login shell tip. I think I found a workaround:

I moved setting the anaconda path from .bash_profile to .bashrc, even though I thought setting $PATH in .bashrc is atypical (vs. in .bash_proflle/.profile).

Also needed to add a key previous line of [ -z "$PS1" ] && return

I added the logic when setting $PATH to avoid duplicate anaconda path entries - since I'm now appending to $PATH in .bashrc vs. .profile/.bash_profile. Thanks to this post.

I haven't run into unintended consequences yet.

.bashrc

# If not running interactively, don't do anything
# This is required, otherwise  error at KDE login 
#   "Could not start D-bus. Can you call qdbus-qt5?"
[ -z "$PS1" ] && return

[[ ":$PATH:" =~ ":/home/user/anaconda2/bin:" ]] || PATH="/home/user/anaconda/bin:$PATH"

I would still say the specific root cause is not identified. (I do understand it "something" w/anaconda libs vs. system libs -- but which lib (qt) and why all of the sudden with this 4.4 to 5.0 version change)

Maybe some updates to the anaconda install instructions are needed with a preferred minimalist .bashrc/.profile/.bash_profile setup example.

Ref:

mingwandroid commented 7 years ago

The specific root cause is that SUSE libraries and tools are not compatible with our libraries and tools.

This is not unusual in the least.

bscipio commented 7 years ago

Your point is well understood is general, but we are missing the specific bins/libs.

As experienced here, Anaconda 4.4 was compatible and 5.0 is not.

So it could be useful to pin point the exact package(s) and versions that are the root cause. (I suspect qt ones given the previous #1206 ). Then a possible alternative to the .bashrc mod above (or being stuck at 4.4) could be to:

I'm NOT suggesting this is a great alternative - just that it could be a path someone could pursue

I'll reiterate that updates to the anaconda install instructions that include a recommended minimalist .bashrc/.profile/.bash_profile example setup would be quite useful to Linux desktop users. Updates like that should help prevent Anaconda users running into these sorts of issues.

Perhaps I should submit that request as another issue?

Thanks.

mingwandroid commented 7 years ago

When I investigated this last, OpenSUSE/KDE were running a system tool (qtpaths) without specifying the full path to it. This means they are not taking care to ensure that the exact program they need gets run, and when it doesn't, bad things happen.

mingwandroid commented 7 years ago

The old issue is at: https://github.com/ContinuumIO/anaconda-issues/issues/1206

bscipio commented 7 years ago

In my first post above, note that the

Issue occurs despite a manual edit to /usr/bin/startkde script to explicitly point to /usr/bin/qtpaths & /usr/bin/qdbus-qt5. This edit was is mentioned in previous reported issue #1206 and in OpenSUSE forum posts below. It doesn't appear the absolute path update is in OpenSUSE 42.3)

So the explicit path fixes to startkde mentioned in previous #1206 did not work for me. I had to modify my .bashrc as noted above. (and not set anaconda path in .profile or .bash_profile)

Knusper commented 6 years ago

Just to mention this here - the discussion continues in opensuse: https://bugzilla.opensuse.org/show_bug.cgi?id=1004769

I think the root cause of these issues is that .bashrc should not be read at all when starting a graphical desktop, but .profile should be used in this case:

https://bugzilla.opensuse.org/show_bug.cgi?id=1078124

mingwandroid commented 6 years ago

Thanks for the update @Knusper. Hopefully SUSE will agree and fix this on their side.

Knusper commented 6 years ago

OK - in openSUSE they would have to make some changes for some init scripts where the relevant parts have been unchanged for 17 years - (basically ~/.bashrc is sourced in a login-shell from /etc/profile, which is not standard). It might happen, depending on the responses I get from the community mailinglist.

https://bugzilla.opensuse.org/show_bug.cgi?id=1078124

Are other distros known to be affected by this? Otherwise, I think its better to change the title of this post? My feeling is, that this is a openSUSE'ism ...

mingwandroid commented 6 years ago

I have not see this anywhere else.

dryguz commented 6 years ago

I just had this problem with KDE on centos. With anaocnda adding it self to .bashr i couldn't start vncserver with kde, commenting out anaconda from .bashrc helped with vnc

Knusper commented 6 years ago

@dryguz can you try adding [ -z "$PS1" ] && return before the anaconda line?

dryguz commented 6 years ago

Yes, I saw @bscipio comment above and added

 [ -z "$PS1" ] && return
[[ ":$PATH:" =~ ":/home/user/anaconda3/bin:" ]] || PATH="/home/user/anaconda3/bin:$PATH"

to the .bashrc don't know what exactly they do, but kde in vnc and anaconda is working with them, so great :)

Knusper commented 6 years ago

[ -z "$PS1" ] && return- checks whether the prompt variable PS1 is set, which is usually only the case in interactive non-login shells. There are several ways to do this, see https://unix.stackexchange.com/questions/26676/how-to-check-if-a-shell-is-login-interactive-batch/ - but I prefer this method. I don't know if it is bullet-proof, though. Anyhow, this is not a support forum - but in order to close this bug, I would suggest that the anaconda installer adds something like this instead of the current default line to the .bashrc.

IndyMark commented 6 years ago

I tried using this in my .bashrc as recommended above

[ -z "$PS1" ] && return
[[ ":$PATH:" =~ ":/home/user/anaconda3/bin:" ]] || PATH="/home/user/anaconda3/bin:$PATH"

I can now login to the desktop fine, but if I start a TurboVNC session and try to connect to it, I still get the same "Could not start D-Bus. Can you call qdbus?" error. Any ideas on what I need to change to get VNC working too?