You are not logged in.
I don't know exactly where to post this but today I started to receive the following errors after Arch switched to Python 3.6:
"
E370: Could not load library libpython3.5m.so.1.0
E263: Sorry, this command is disabled, the Python library could not be loaded.
UltiSnips: the Python version from g:UltiSnipsUsePythonVersion (3) is not available.
You need vim compiled with Python 2.6, 2.7 or 3.2 and later support
for Powerline to work. Please consult the documentation for more
details.
Press ENTER or type command to continue
"
I use the following definitions in .vimrc to load Powerline:
"
let g:powerline_pycmd="py3"
let powerlinecmd=substitute(system("which powerline"), '\n\+$', '', '')
if !empty(glob(powerlinecmd))
python3 from powerline.vim import setup as powerline_setup
python3 powerline_setup()
python3 del powerline_setup
endif
"
The E370 is error is for this line:
python3 from powerline.vim import setup as powerline_setup
Last edited by beoldhin (2017-01-13 05:56:03)
Offline
I think you should try reinstalling the plugins: it's _probably_ the same as pip packages, which all must be reinstalled so that they point to 3.6 instead than 3.5
Offline
same problem here, maybe vim as to be recompiled.
Offline
Looks like powerline needed to rebuild for python 3.6 .
About 5 hours ago powerline 2.5-2 entered community, update your systems.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
I have upgraded to powerline 2.5-2, however, the problem persists. It seems to be a vim issue:
$ strings /usr/bin/vim |grep libpython
libpython3.5m.so.1.0
libpython2.7.so.1.0
$ pacman -Q gvim
gvim 8.0.0086-1
Offline
Powerline 2.5-2 here (and no new system updates yet). The UltiSnips (mentioned above) is a fresh one from git.
Offline
:python3 echo('It works!')
Fail. Vim dynamically loads the python3 interpreter, which is why vim runs at all right now, but that doesn't help when you actually want to use the no-longer-existing python.
Reported: https://bugs.archlinux.org/task/52401
Last edited by eschwartz (2017-01-06 15:53:11)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Vim dynamically loads the python3 interpreter, which is why vim runs at all right now, but that doesn't help when you actually want to use the no-longer-existing python.
I wonder why it is compiled using the explicit libpython3's file name instead of just the link libpython3.so that should point to the current version.
Offline
Do you also wonder why soname versions exist? After all, bash should just link the libreadline.so link instead of the explicit libreadline.so.7 file name, which screwed up everyone's computers for no good reason when they did a partial update and broke bash. After all, soname version bumps are really stupid and the claim that they break backwards compatibility in the API is just a lot of FUD told by forum moderators who want to close peoples' threads for the evulz. </sarcasm>
I would assume it is because they actively want it to stop working, on account of it not actually working even if you go ahead and stuff /usr/lib full of unwise symlinks. Just like any other soname bump...
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
As a remedy, creating a symlink from libpython3.so to libpython3.5m.so.1.0 did the trick because vim is redirected to the 3.6 library.
Offline
As a remedy, creating a symlink from libpython3.so to libpython3.5m.so.1.0 did the trick because vim is redirected to the 3.6 library.
You can do whatever you want on your system, but do not suggest other people do such a dumb thing.
Online
same here
Offline
package vim-8.0.0149-1 should fix this python3 issue and it is in [extra] now. Please try it and let us know if there are any additional issues.
Last edited by anatolik (2017-01-07 18:14:09)
Read it before posting http://www.catb.org/esr/faqs/smart-questions.html
Ruby gems repository done right https://bbs.archlinux.org/viewtopic.php?id=182729
Fast initramfs generator with security in mind https://wiki.archlinux.org/index.php/Booster
Offline
fixed, thx
Offline
As a remedy, creating a symlink from libpython3.so to libpython3.5m.so.1.0 did the trick because vim is redirected to the 3.6 library.
I get the nagging feeling that you completely misinterpreted my response to your initial question. Also, I cannot help but wonder why you do not trust the Vim developers to be intelligent enough to properly link Python, but you do trust them enough to use their editor in the first place.
Once again, anyone other than you would recognize that the reason the Vim developers chose to use the latest fully-versioned library rather than libpython3.so, is because they know it will break unpredictably when you link against a different version than the one you compiled against.
Like all shared libraries, ever. Because, yet again, the reason python developers changed the library name is because it isn't backwards compatible and they are trying to warn people that if they want their software to work properly they should recompile it with python 3.6!
I eagerly await the day your computer blows up with missing symbol errors, so we can say "I told you so" and you can say "sorry, now I realized my mistake and I am ready to finally join the world of people-who-do-smart-things".
Sheesh.
Last edited by eschwartz (2017-01-08 01:01:49)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Do you also wonder why soname versions exist? After all, bash should just link the libreadline.so link instead of the explicit libreadline.so.7 file name, which screwed up everyone's computers for no good reason when they did a partial update and broke bash. After all, soname version bumps are really stupid and the claim that they break backwards compatibility in the API is just a lot of FUD told by forum moderators who want to close peoples' threads for the evulz. </sarcasm>
I would assume it is because they actively want it to stop working, on account of it not actually working even if you go ahead and stuff /usr/lib full of unwise symlinks. Just like any other soname bump...
I've switched to Arch around 10/2016. Then I was running Antergos and Cinnamon where Cinnamon required libreadline.so.6. Then libreadline was suddenly upgraded to .7, causing Cinnamon to break. It was fixed the next day. Then I moved to Arch. Then Python was upgraded, causing Vim breakage and python-plumbum (AUR) breakage. Now it seems Ruby has been upgraded, causing Puppet breakage and tmuxinator (AUR) breakage. If the random breakage can be avoided, then fine. I don't care so much about isolated breakage. What worries me more is that I can't predict what will break next (any random package) when I know it will very likely happen in the with any minor version change.
Offline
beoldhin, I'm not sure what point you are trying to make, given that you chose to respond to my post. None of these things broke because of the idea of versioned shared libraries. They broke because of a combination of:
A fundamental tenet of Arch Linux, that we ship updates as soon as reasonably possible, and we don't keep old compatibility libraries around.
An oversight that caused specific packages in the repos to not be rebuilt in [staging] against the new python/ruby/whatever.
AUR packages are the user's responsibility, and not all AUR maintainers are as responsible as I would like. As for oversights in the main repos, things happen sometimes.
If you want better guarantees, switch to a distro that actually provides them. Debian/CentOS for example.
Or perhaps use the Arch Linux Archive to pin your updates so they happen a couple days late, giving you time to watch the forums for other people reporting breakage.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline