Arch Linux User Repository

If you want to use system's abseil set the _use_system_abseil to ON - default is to download from internet during build.

Just a small note from someone who changed the default CMAKE_GENERATOR: I don't really like the fact that the PKG_BUILD doesn't specify the generator when generating, but then assumes make to build, which led to an error for me and changing the CMAKE_GENERATOR temporarily before installing.

@artafinde: thanks.

@lahwaacz: this is just fixed upstream with PR 3984. [Delete your cache] and try again please.

The package does not build with Python 3.10.1:

==> Starting pkgver()...
==> Updated version: vim-youcompleteme-git r2860.ab28bd7a-1
==> Starting build()...
-- The C compiler identification is GNU 11.1.0
-- The CXX compiler identification is GNU 11.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Python3: Found unsuitable version "3.10.1", required range
  is "3.6...3.10" (found /usr/bin/python3.10, found components: Interpreter
  Development Development.Module Development.Embed)
Call Stack (most recent call first):
  /usr/share/cmake-3.22/Modules/FindPackageHandleStandardArgs.cmake:592 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake-3.22/Modules/FindPython/Support.cmake:3166 (find_package_handle_standard_args)
  /usr/share/cmake-3.22/Modules/FindPython3.cmake:490 (include)
  CMakeLists.txt:235 (find_package)


-- Configuring incomplete, errors occurred!

staletic: already done

LLVM12 has hit Extra. Time to migrate back?

LLVM 12 has just hit the official repos. You can switch back to Arch's clangd/libclang.

artafinde: Thanks for updating the package, now I have a functional YCM with clangd 12.

staletic: I still have the problem. When I create the files foo.h and foo.hpp as shown here and open foo.h in vim, YCM gives me this diagnostic:

foo.h|8 col 10 error| In included file: redefinition of 'Foo' /home/lahwaacz/foo.h:3:7: note: error occurred here /home/lahwaacz/foo.hpp:3:10: note: '/home/lahwaacz/foo.h' included multiple times, additional include site here [redefinition]

I even tried to comment out all ycm settings in my vimrc and still got the same. Do you have some some configuration which remedies the issue?

lahwaacz: Thanks it was a bug there, it should be a relative symlink and it's done to not copy the libclang.so twice as it's big.

artafinde: This command is wrong, since $pkg_ycmd_dir contains the $pkgdir:

ln -s "${pkg_ycmd_dir}/third_party/clang/lib/libclang.so" "${pkg_ycmd_dir}/third_party/clang/lib/libclang.so"

It should also probably link to the file under clangd...

lahwaacz: Just pushed an update - try rebuilding (no changes required in PKGBUILD)

artafinde: I understood your comment as it is necessary to use _use_system_clang="OFF" until clang 12 appears in the repos, then I was surprised that the package even built with _use_system_clang="ON" (that is pkgver=r2812.ab73ca25-1). Also /usr/share/vim/vimfiles/third_party/ycmd/third_party/clangd/output/ seems to be bundled regardless of the _use_system_clang value?

lahwaacz: aware of this but as I mentioned before the bundled cland12 is a temporary solution until clang12 hits the repos - it's been our for quite some time not sure what's the delay from the maintainer. Currently the _use_system_clang="OFF" is broken and not sure if I'd like to spend time on fixing something which is temporary.

Hmm, I've just tried to rebuild the package with _use_system_clang="OFF" and then I get this error in vim:

Error detected while processing VimEnter Autocommands for "*"..function youcompleteme#Enable[44]..<SNR>56_SetUpPython:
line   66:
Error while listing /usr/share/vim/vimfiles/third_party/ycmd/third_party/clang/lib/clang folder
Press ENTER or type command to continue

Seeing that the package installs the bundled clang into /usr/share/vim/vimfiles/third_party/ycmd/third_party/clangd/output/, there is probably some packaging problem...

@lahwaacz I'm using clangd12 and can't repro. This definitely has nothing to do with YCM. To be honest, if it's reproducible with clang-check, I don't think it's a problem with clangd eihter, but they may have a clue what's going on. That is if there's any problem at all, considering that I can't repro.

YouCompleteMe suffers from the same issue as I described for clang-check: header file with #pragma once leads to redefinition errors. Has anybody else noticed this? Are there some settings in YCM to solve this issue?

Latest update of YCM requires clangd >= 12.0.0. Temporary solution till clangd arrives to archlinux's repos is to use bundled clangd.

@artafinde

We've just dropped the dependency on the following:

• python-requests-futures
• python-requests

If you want to use system's abseil set the _use_system_abseil to ON - default is to download from internet during build.

As a rough first cut use the version I just published - I'll work tomorrow on sorting out the dependencies.

@dviktor As of today, YCM depends on Abseil. The library us in AUR (maybe even in the official repos, not sure), but the PKGBUILD has not been updated.

EDIT: Also, the waitress dependency should be removed.

got this error today:

[100%] Linking CXX shared library /tmp/buildcache/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/ycm_core.cpython-39-x86_64-linux-gnu.so
[100%] Built target ycm_core
==> Entering fakeroot environment...
==> Starting package()...
cp: cannot stat 'third_party/ycmd/ycm_core.so': No such file or directory
==> ERROR: A failure occurred in package().
    Aborting...

EDIT: solved after a clean rebuild

Stopped working after clang updated to version 11.1.0-1.

Error log:

2021-02-25 15:49:42,345 - ERROR - libclang.so.11: cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/utils.py", line 498, in ImportAndCheckCore
    ycm_core = ImportCore()
  File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/utils.py", line 489, in ImportCore
    import ycm_core as ycm_core
ImportError: libclang.so.11: cannot open shared object file: No such file or directory

It is looking for libclang.so.11, but with this clang version we have libclang.so.11.1.

After inspecting that error message, it seems like the advice on this page fixes the issue

https://github.com/archlinuxcn/repo/issues/319

Apologies @staletic -- I'd thought it looked similar to @David01's error, but you are right that it is different.

@artafinde -- yes, this error occurs after a clean build and fresh pacman update.

Error detected while processing function <SNR>80_PollServerReady:
line    7:
Traceback (most recent call last):
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/client/base_request.py", line 206, in Session
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    return cls.session
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
AttributeError: type object 'BaseRequest' has no attribute 'session'
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
During handling of the above exception, another exception occurred:
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
Traceback (most recent call last):
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "<string>", line 1, in <module>
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/youcompleteme.py", line 226, in CheckIfServerIsReady
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    self._server_is_ready_with_cache = BaseRequest().GetDataFromHandler(
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/client/base_request.py", line 105, in GetDataFromHandler
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    self.GetDataFromHandlerAsync( handler, timeout, payload ),
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/client/base_request.py", line 114, in GetDataFromHandlerAsync
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    return BaseRequest._TalkToHandlerAsync(
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/client/base_request.py", line 171, in _TalkToHandlerAsync
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    return BaseRequest.Session().get(
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/client/base_request.py", line 209, in Session
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
    from requests_futures.sessions import FuturesSession
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
ImportError: bad magic number in 'requests_futures': b'\x03\xf3\r\n'
Press ENTER or type command to continue
Error detected while processing function <SNR>80_PollServerReady:
line    7:
E858: Eval did not return a valid python object
Press ENTER or type command to continue

@wjhandley Did you rebuild ycm after a recent pacman full upgrade?

@wjhandley It's useful to post entire errors, not just the first line.

I'm also still getting the error

Error detected while processing function <SNR>84_PollServerReady: line 7:

Has anybody found a solution to this?

After new year's there has been a recent pacman packages update. This update was performed successfully, but there is some conflict with ycm's 2020-12-21 update:

vim filename gives:

Error detected while processing function <SNR>37_PollServerReady:
line    7:
Press ENTER or type command to continue
Error detected while processing function <SNR>37_PollServerReady:
line    7:
Traceback (most recent call last):
Press ENTER or type command to continue
Error detected while processing function <SNR>37_PollServerReady:
line    7:
  File "<string>", line 1, in <module>
Press ENTER or type command to continue
Error detected while processing function <SNR>37_PollServerReady:
line    7:
  File "/usr/share/vim/vimfiles/python/ycm/youcompleteme.py", line 226, in CheckIfServerIsReady

:scriptnames gives:

  1: /etc/vimrc
  2: /usr/share/vim/vimfiles/archlinux.vim
  3: ~/.vimrc
  4: /usr/share/vim/vim82/filetype.vim
  5: /usr/share/vim/vimfiles/ftdetect/PKGBUILD.vim
  6: /usr/share/vim/vimfiles/ftdetect/meson.vim
  7: /usr/share/vim/vim82/ftplugin.vim
  8: /usr/share/vim/vim82/indent.vim
  9: /usr/share/vim/vim82/syntax/syntax.vim
 10: /usr/share/vim/vim82/syntax/synload.vim
 11: /usr/share/vim/vim82/syntax/syncolor.vim
 12: /usr/share/vim/vim82/autoload/netrw_gitignore.vim
 13: /usr/share/vim/vimfiles/autoload/pathogen.vim
 14: /usr/share/vim/vim82/ftoff.vim
 15: ~/.vim/bundle/vim-polyglot/ftdetect/polyglot.vim
 16: ~/.vim/bundle/vim-colors-xcode/colors/xcodelighthc.vim
 17: /usr/share/vim/vimfiles/plugin/SyntaxFolds.vim
 18: /usr/share/vim/vimfiles/plugin/filebrowser.vim
 19: /usr/share/vim/vimfiles/plugin/fzf.vim
 20: /usr/share/vim/vimfiles/plugin/imaps.vim
 21: /usr/share/vim/vimfiles/plugin/indentLine.vim
 22: /usr/share/vim/vimfiles/plugin/remoteOpen.vim
 23: /usr/share/vim/vimfiles/plugin/youcompleteme.vim
 24: /usr/share/vim/vim82/plugin/getscriptPlugin.vim
 25: /usr/share/vim/vim82/plugin/gzip.vim
 26: /usr/share/vim/vim82/plugin/logiPat.vim
 27: /usr/share/vim/vim82/plugin/manpager.vim
 28: /usr/share/vim/vim82/plugin/matchparen.vim
 29: /usr/share/vim/vim82/plugin/netrwPlugin.vim
 30: /usr/share/vim/vim82/plugin/rrhelper.vim
 31: /usr/share/vim/vim82/plugin/spellfile.vim
 32: /usr/share/vim/vim82/plugin/tarPlugin.vim
 33: /usr/share/vim/vim82/plugin/tohtml.vim
 34: /usr/share/vim/vim82/plugin/vimballPlugin.vim
 35: /usr/share/vim/vim82/plugin/zipPlugin.vim
 36: /usr/share/vim/vim82/scripts.vim
 37: /usr/share/vim/vimfiles/autoload/youcompleteme.vim

Could you please help me ? Many thanks

@artafinde I see you've removed the ycmd repo from the sources array, which makes sense - now makepkg won't update the module only for git submodule update to skip back to the tracked commit.

Now the only problem with package versions is that the last 11 commits have the same message: upgpkg: vim-youcompleteme-git r2774.4496153a-1. I understand you just force-install the same package version with makepkg, but people who put the package into their custom binary repo actually need to bump pkgrel, otherwise pacman won't recognize it as an update and will just tell you that the old, cached package has become corrupted.

@lahwaacz: The -git packages in AUR are mostly pkgver of 1 since they don't represent any particular release / tag. Whoever uses them agrees in the "silent contract" that they should keep them up to date.

On top of that the vim-youcompleteme-git plugin is a bit more complicated since the upstream depends on the ycmd (server) and it's tracked as git submodule in the upstream source code. So even if the upstream youcompleteme project source code might seem as not updated the submodule (ycmd) might.

My recommendation is to rebuild the -git packages you use often.

Disclaimer: I don't use any aur helper - just makepkg so no clue on what they offer, if any.

@lahwaacz The ycmd git source is YCM's submodule, so it can't change without getting updated in the YCM repo first.

@artafinde pybind11-2.6.1-1 is out and headers now do exist in /usr/include/pybind11. This PKGBUILD should be able to add pybind11 to the rm -rf command on line 77.

The pkgver function is wrong - the PKGBUILD has 2 git repos in the sources array, but the current pkgver function considers only one of them. If the other repo changes, the build obviously results in a different package, but the pkgver stays the same.

Updated.

The clangd_binary_path has to get the same treatment as the jdt workspace - it's overridden in plugin/youcompleteme.vim. Here's the missing line:

  sed -e "s|\(ycm_clangd_binary_path',\).*\$|\1 '/usr/bin/clangd' )|" \
      -i "${srcdir}"/YouCompleteMe/plugin/youcompleteme.vim

Arch just upgraded python from python 3.8 to 3.9 which broke vim-youcompleteme-git, as libpython3.8.so was missing.

The solution was to fully uninstall vim-youcompleteme-git, purge it from cache, and re-install so that it compiles against new python 3.9 libraries.

@edacval: thanks for the contribution. I guess this happens when you maintain a package which targets developers :)

http://ix.io/2GuU Patch to fix prepare() running sed on wrong files and simplify sed substitutions:

diff --git a/PKGBUILD b/PKGBUILD
index 807a9aa..1015438 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -74,33 +74,33 @@ prepare() {

   # NOTE: Arch package for pybind11 2.6.0 doesn't ship headers
   # Force system headers/libs
-  rm -rf "${srcdir}"/ycmd/cpp/llvm || exit
+  rm -rf "${srcdir}"/YouCompleteMe/third_party/ycmd/cpp/llvm || exit

   if [[ "$_gocode" == "y" ]]; then
-    sed -e "s/\(gopls_binary_path\":\).*\$/\1 \"\/usr\/bin\/gopls\",/" \
-        -i "${srcdir}"/ycmd/ycmd/default_settings.json
+    sed -e 's|\(gopls_binary_path":\).*$|\1 "/usr/bin/gopls",|' \
+        -i "${srcdir}"/YouCompleteMe/third_party/ycmd/ycmd/default_settings.json
   fi

   if [[ "$_typescript" == "y" ]]; then
     rm -rf "${srcdir}/YouCompleteMe/third_party/ycmd/third_party/tern_runtime" || exit
-    sed -e "s/\(tsserver_binary_path\":\).*\$/\1 \"\/usr\/bin\/tsserver\",/" \
-        -i "${srcdir}"/ycmd/ycmd/default_settings.json
+    sed -e 's|\(tsserver_binary_path":\).*$|\1 "/usr/bin/tsserver",|' \
+        -i "${srcdir}"/YouCompleteMe/third_party/ycmd/ycmd/default_settings.json
   fi
   if [[ "$_java" == "y" ]]; then
-    sed -e "s/\(java_jdtls_workspace_root_path\":\).*\$/\1 \"\/tmp\",/" \
-        -e "s/\(java_binary_path\":\).*\$/\1 \"\/usr\/bin\/java\"/" \
-        -i "${srcdir}"/ycmd/ycmd/default_settings.json
+    sed -e 's|\(java_jdtls_workspace_root_path":\).*$|\1 "/tmp",|' \
+        -e 's|\(java_binary_path":\).*$|\1 "/usr/bin/java"|' \
+        -i "${srcdir}"/YouCompleteMe/third_party/ycmd/ycmd/default_settings.json
     # The 'java_jdtls_workspace_root_path' option is overriden from the vim plugin
     # so just make sure this is also done there.
-    sed -e "s/\(ycm_java_jdtls_workspace_root_path',\).*\$/\1 '\/tmp' )/" \
+    sed -e "s|\(ycm_java_jdtls_workspace_root_path',\).*\$|\1 '/tmp' )|" \
         -i "${srcdir}"/YouCompleteMe/plugin/youcompleteme.vim
   fi

-  sed -e "s/\(clangd_binary_path\":\).*\$/\1 \"\/usr\/bin\/clangd\",/" \
-      -e "s/\(rust_toolchain_root\":\).*\$/\1 \"\/usr\",/" \
-      -e "s/\(roslyn_binary_path\":\).*\$/\1 \"\/opt\/omnisharp-roslyn\/OmniSharp.exe\",/" \
-      -e "s/\(mono_binary_path\":\).*\$/\1 \"\/usr\/bin\/mono\",/" \
-      -i "${srcdir}"/ycmd/ycmd/default_settings.json
+  sed -e 's|\(clangd_binary_path":\).*$|\1 "/usr/bin/clangd",|' \
+      -e 's|\(rust_toolchain_root":\).*$|\1 "/usr",|' \
+      -e 's|\(roslyn_binary_path":\).*$|\1 "/opt/omnisharp-roslyn/OmniSharp.exe",|' \
+      -e 's|\(mono_binary_path":\).*$|\1 "/usr/bin/mono",|' \
+      -i "${srcdir}"/YouCompleteMe/third_party/ycmd/ycmd/default_settings.json
 }

 build() {

Finally, is it possible to specify the minimum version for java-environment? JDT.LS requires java 11.

Fixed

Except it now says java-environment>11, which means 12+? Or does it mean >11.0.0?

Line 133 can also be set in the default_settings.json. The key is called java_jdtls_workspace_root_path - in case you prefer sed to ln -s.

tried and didn't work ycmd doesn't seem to respect it :/

Oh... This might be annoying. It's overridden here.

As you can see, many of the things in default_settings.json are actually overridden in plugin/youcompleteme.vim. The idea behind that was a step towards completely decoupling YCM and ycmd (YCM actually does import ycmd in a few places...). That task proved to be tougher than we thought and we stopped half way through.

The relevant YCM pull request: https://github.com/ycm-core/YouCompleteMe/pull/3243

@staletic

• fixed

• tried and didn't work ycmd doesn't seem to respect it :/

• fixed

• -DUSE_PYTHON2 isn't recognized by cmake any more, because we now require python3.
• Line 133 can also be set in the default_settings.json. The key is called java_jdtls_workspace_root_path - in case you prefer sed to ln -s.
• Finally, is it possible to specify the minimum version for java-environment? JDT.LS requires java 11.

@Windfisch Thanks for the suggestion - can you please check if this is already fixed on this PKGBUILD: https://gist.github.com/inglor/6f9b9b12316b360e286f5a7f7327d810

Dear Leonidas,

Currently, Rust support is broken after YCM has moved from RLS to rust-analyzer. I have fixed this in https://github.com/Windfisch/aur-vim-youcompleteme-git (tl;dr: rls.patch needs to be adjusted to do the same for rust-analyzer).

I would be happy if you could merge my patch :)

Best regards, Windfisch

@artafinde When possible, YCM does stick to actual tags instead of random commits. The neovim PKGBUILD is outdated and also orphaned.

The reason I excluded libclang by default is because it's considered deprecated. The only reason it still exists is because clangd is missing an obscure feature. Otherwise, clangd is a much better choice.

The reason I excluded the tern completer is the same. Only now, TSserver is missing this feature.

As for JDT causing troubles... I had a feeling something was off. I can't tell what right off the bat. I may sound lazy, but currently I'm juggling 3 YCM installations, depending on what I'm doing. I really don't feel like messing that up with installing YCM globally. That said, I'd welcome anyone who wants to test these new PKGBUILDS over to the YCM's gitter to iron out any possible problems.

Finally, we've been considering making ycmd submodule possible to install through pip. That will need a lot of work, but you can track progress here.

@staletic Thanks for this I spend a few hours yesterday looking at modifying the current PKBUILD to the one you proposed. I'm also eager to move away from most submodules as it's a pain so having them as dependencies is much better (just hoping that ycm will follow the submodules' releases and not point to a random commit).

Having said that the neovim package seems a bit behind I think but since it's a -git package it might just not been built recently. I tried to keep the same build options as the current PKGBUILD and came up with the PKGBUILD

Thank you

@all: if anyone is willing to test the new PKGBUILD it will simplify the build and make it quicker.

It stopped building, packaging fails because cregex is missing:

cp: cannot stat '/home/jalon/src/aur/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/cregex': No such file or directory

As always, I am building without support for gocode, tern, typescript and java, I don't know if that might be related to the problem.

I have tried removing cregex from line 258 of the PKGBUILD, and it builds. It also seems to be working, but I do not know if maybe I'll be missing any features because of the change.

Hi, I've been away for a long time, but I've taken a look at both, this PKGBUILD and the one for neovim.

Consider looking at the PKGBUILD I've written that is up-to-date with what YCM is doing and should work on Arch.

https://gist.github.com/bstaletic/7acfafbedc7db476c0eec4714d016ea4

Getting a packaging error that cregex is missing. @artafinde: Boris Staletic from the YCM team told me that cregex has moved mrab-regex. Please exchange them in the PKGBUILD!

jdtls is being downloaded over http when downloading over https is perfectly fine

@dramm No idea about vundle, I don't use it.

@lahwaacz It was created by vundle. So I removed ycm from vundle plugin list and the a PluginClean. Now I no longer get ycm_core library not detected, So I guess it's working!

Just to clarify then, when using this package I shouldn't also add youcompleteme to the vundle list?

@dramm You are using /home/dramm/.vim/bundle/youcompleteme/third_party/ycmd/ycmd/utils.py which is not provided by this package (it has /usr/share/vim/vimfiles/third_party/ycmd/ycmd/utils.py).

@artafinde I appreciate the help. I was using syntastic so I thought that might be it.

However it's still not working... I must be doing something really dumb...

I removed all vundle Plugin calls (expect for vundle itself) and run PluginClean. I uninstalled this package, recompiled it and installed again. I added youcompleteme to the vundle list and run PluginInstall. Still nothing. So I recompiled this package again, just to make sure.

I then added this to the .vimrc

let g:ycm_global_ycm_extra_conf = /home/dramm/.vim/bundle/youcompleteme/.ycm_extra_conf.py'
let g:ycm_keep_logfiles = 1
let g:ycm_log_level = 'debug'

This is the error log

2020-07-19 11:52:46,835 - DEBUG - Global extra conf not loaded or no function YcmCorePreload
2020-07-19 11:52:46,835 - ERROR - ycm_core library not detected; you need to compile it by running the build.py script. See the documentation for more details.
Traceback (most recent call last):
  File "/home/dramm/.vim/bundle/youcompleteme/third_party/ycmd/ycmd/utils.py", line 498, in ImportAndCheckCore
    ycm_core = ImportCore()
  File "/home/dramm/.vim/bundle/youcompleteme/third_party/ycmd/ycmd/utils.py", line 489, in ImportCore
    import ycm_core as ycm_core
ModuleNotFoundError: No module named 'ycm_core'

The extra conf path config seems to have no effect on the debug message.

I tried this both on a javascript file and on a python file. I'm using gvim.

@dramm: if you installed the package normally with makepkg then you don't need to do something else. It might be another plugin interfearing with it though so disable all vim plugins and try to load. A common mistake is a plugin with depends on python2 and is loaded before YCM - see previous comments.

Hi, I installed this package with makepkg -sirc.

I added the plugin to vundle plugins list in vimrc and installed the plugin.

However I'm still getting the YCM core library not detected message.

Do I still need to run python3 install.py even though I using this package?

Thanks!

@artafinde That was it. Thanks a lot!

I updated all my plugins and whatever was still loading Python 2 now loads Python 3 apparently.

@raucao: could be something in the lines of this. See if you disable other plugins solves the issue and then enable one by one to find the culprit.

@artafinde It's the extra/vim 8.2.0717-2 package, and the version command's output confirms the same version:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled May 8 2020 23:37:13) Included patches: 1-717
Compiled by Arch Linux

@raucao what version of vim are you using? vim --version

@artafinde I have the same in my vimrc. And the package builds fine (I didn't report a build failure). The problem is that it doesn't work with the system vim anymore, throwing the aforementioned error when opening vim.

@raucao the package builds fine as is (no changes in PKGBUILD) on an up to date system in a clean-chroot (see_wiki). I am using it with vim not neovim (although it works fine with neovim also) and with the below on my .vimrc

let g:ycm_server_python_interpreter = '/usr/bin/python3'

After a recent system upgrade YCM stopped working, so I tried to update this package. Unfortunately, it doesn't work anymore, and complains about missing Python when launching vim:

YouCompleteMe unavailable: unable to load Python.

I re-installed vim, and it does have support for Python. Unfortunately, over on the YCM repo, the response is that it needs Python 3 support, and everyone just says to install Neovim to get that, but I do not wish to use Neovim. Also, it does look like the system/Arch Vim has both Python 2 and 3 support.

So, as this package is supposed to work with the normal Arch vim dependency, I am reporting it as a bug now.

(I also tried compiling my own vim with Python 3, but I couldn't figure out how this package even inserts YCM into the vim loading process in the first place. So that didn't help either.)

@staletic I tried to understand what you mean with the pinned message regarding the removal of submodules and even tried to create a PKGBUILD without them but it seems more complicated than it seems (at least to me). Using submodules it's a pain for packaging it.

Updated without version bump

I would like to suggest one more patch - this will strips reference to $srcdir from gopls and cleans go modcache after build:

diff --git a/PKGBUILD b/PKGBUILD
index 2e500ff..42a935c 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -192,7 +192,8 @@ build() {
                local _local_GOPATH="$srcdir"/YouCompleteMe/third_party/ycmd/third_party/go
                mkdir ${_local_GOPATH} || exit
                cd ${_local_GOPATH} || exit
-               GO111MODULE=on GOPATH=${_local_GOPATH} go get golang.org/x/tools/gopls@v0.4.0
+               GO111MODULE=on GOPATH=${_local_GOPATH} go get -trimpath golang.org/x/tools/gopls@v0.4.0
+               GO111MODULE=on GOPATH=${_local_GOPATH} go clean -modcache
        else
                echo 'Skipping Gocode completer...'
        fi

Getting this error:

[ 72%] Building CXX object ycm/CMakeFiles/ycm_core.dir/CodePointRepository.cpp.o
[ 75%] Building CXX object ycm/CMakeFiles/ycm_core.dir/IdentifierDatabase.cpp.o
[ 77%] Building CXX object ycm/CMakeFiles/ycm_core.dir/IdentifierCompleter.cpp.o
[ 80%] Building CXX object ycm/CMakeFiles/ycm_core.dir/IdentifierUtils.cpp.o
[ 83%] Building CXX object ycm/CMakeFiles/ycm_core.dir/Result.cpp.o
[ 88%] Building CXX object ycm/CMakeFiles/ycm_core.dir/PythonSupport.cpp.o
[ 88%] Building CXX object ycm/CMakeFiles/ycm_core.dir/Utils.cpp.o
[ 91%] Building CXX object ycm/CMakeFiles/ycm_core.dir/Word.cpp.o
[ 94%] Building CXX object ycm/CMakeFiles/ycm_core.dir/ycm_core.cpp.o
[ 97%] Building CXX object ycm/CMakeFiles/ycm_core.dir/versioning.cpp.o
[100%] Linking CXX shared library /build/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/ycm_core.so
[100%] Built target ycm_core
/startdir/PKGBUILD: line 191: cd: /build/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/go/src/golang.org/x/tools/gopls: No such file or directory

@holishing thanks for the heads up. I don't do any go development so if someone can help test this in advance I'd appreciate it. Use this PKGBUILD

https://github.com/ycm-core/ycmd/commit/f666d38fbbfdc3a5c585cb97596ef954a91763ec

this change about golang third_party part may let YCM not compilable

@Rubonnek: Try again with a latest rebuild on a clean chroot.

The server crashes on my computer -- looks like there are missing dependencies like python-watchdog and some others.

@fabwu: To disable 'go' and 'npm' dependencies set

_gocode="n"
_tern="n"
_typescript="n"

Thanks for the hint. I'm quite new to AUR so I've just changed the options in the PKGBUILD file. Is this the right way of setting build options?

@fabwu: use the build options to disable them.

Is it possible to set the dependencies to node and go as optional? All I want is auto-completion for C so I don't need the other language runtimes.

@Universebenzene Thanks for the fix.

@KarlWithK Seems that a submodule is missed in the PKGBUILD. Possible fix here: https://github.com/archlinuxcn/repo/commit/360b4605a9ac380676d9279b91f4490b720b7f10#diff-edeecce400204b781ebdbeb2625dd849

Hello, I am having problems with jedi / Python completion. Whenever I try to write a function I get this error: FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/vim/vimfiles/third_party/ycmd/third_party/jedi_deps/jedi/jedi/third_party/typeshed/stdlib'. I am not sure how to fix this or even if this is the right place to ask. Thanks for the help.

Early warning: upstream is dropping support for python2 hence this PKGBUILD will also drop support for it very soon see github

The workaround for "Parsing out the JDTLS package version from upstream" is to disable java in PKGBUILD when maually building the package. Change _java="y" into _java="n" at the beginning of the file.

I am still having the problem with JDTLS: ...

==> Starting prepare()... Parsing out the JDTLS package version from upstream... JDTLS package version matched. Downloading... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 21211 0 21211 0 0 55093 0 --:--:-- --:--:-- --:--:-- 55093

gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error is not recoverable: exiting now ==> ERROR: A failure occurred in prepare(). Aborting... Error making: vim-youcompleteme-git

The new ycm upstream add the typeshed submodule under jedi, so it should be included while packaging, or there will be errors while using ycm (e.g. completing the python code).

Yup, using Yay's --editmenu and fixing the PKGBUILD worked. Thanks @jamesljlster !

follow the advice of staletic and jamesljlster and it will build. PKGBUILD needs updating.

Checking the PKGBUILD I can see the patch from @jamesljlster is present but yet the JDTLS and not in gzip format is also present.

Apparently msbuild-stable ( https://aur.archlinux.org/packages/msbuild-stable/ ) is also a requirement for C# support.

See the Introduction section of Omnisharp-Roslyn's README: https://github.com/OmniSharp/omnisharp-roslyn

I can at least anecdotally confirm that I was not able to get C# completions working in YCM/Omnisharp (includes programs like VSCode) without msbuild-stable.

I'd recommend adding it to the optdepends

@jamesbrink @szemy @unxusr @Excelsior @dviktor

I found that JDTLS 0.45.0 is missing from "https://download.eclipse.org/jdtls/milestones/".

Official YCM build script downloads JDTLS from snapshot page.

So I make a quick fix for JDTLS package downloading issue:

From f8458252dbbb9b935e938fd227d84880550a7f80 Mon Sep 17 00:00:00 2001
From: Zheng-Ling Lai <jamesljlster@gmail.com>
Date: Tue, 8 Oct 2019 15:25:58 +0800
Subject: [PATCH] Fix JDTLS package downloading issue

---
 PKGBUILD | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/PKGBUILD b/PKGBUILD
index 05fdc0e..1ec6ee0 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -130,7 +130,7 @@ prepare() {

        if [[ "$jdtls_milestone" != "" ]] && [[ "$jdtls_buildstamp" != "" ]]; then
            echo 'JDTLS package version matched. Downloading...'
-           curl -LO http://download.eclipse.org/jdtls/milestones/${jdtls_milestone}/${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
+           curl -LO http://download.eclipse.org/jdtls/snapshots/${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
            tar xf ${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
        else
            echo 'Mismatched JDTLS version'
-- 
2.23.0

Have the same problem with JDTLS and not in gzip format

Had the same problem. I think it's caused by the incomplete downloaded jdtls packet, probably because the latest jdtls has been updated recently.

having this error also: ==> Iniciando prepare()... Parsing out the JDTLS package version from upstream... JDTLS package version matched. Downloading... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 100 21211 0 21211 0 0 40556 0 --:--:-- --:--:-- --:--:-- 40556

gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error is not recoverable: exiting now

Same here: gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error is not recoverable: exiting now ==> ERROR: A failure occurred in prepare(). Aborting... Error making: vim-yo Weird

@staletic

Its working now. Thank you!

@marcin

That is a network error. Either you have some sort of firewall/proxy messing with you, or thte jdt host is flaky. You can try downloading jdt from here and placing it wherever the package expects it to be.

@jamesbrink

I'm getting following error:

Parsing out the JDTLS package version from upstream... JDTLS package version matched. Downloading... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 37.6M 0 37.6M 0 0 59894 0 --:--:-- 0:10:58 --:--:-- 132k

gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error is not recoverable: exiting now ==> ERROR: A failure occurred in prepare(). Aborting... Error making: vim-yo

@marcin it is currently building at working we just need to clean it up. Just build it like any other package.

@jamesbrink

You should keep an eye on these two:

• https://github.com/ycm-core/ycmd/pull/1282
• https://github.com/ycm-core/ycmd/issues/1289

TL;DR: We're planning to do something like g:ycm_clangd_binary_path for go, rust and typecript.

@marcin

I haven't tried this package or the neovim alternative, but they should still work. As a YCM maintainer it's much more convenient for me to install YCM locally, outside of pacman. I also have a bad experience with third party YCM packages from a few years ago, but I'm here to change that.

In the ideal world, we'd e able to package ycmd as a python module, in site-packages and YCM in /usr/share/vim/, but we're far from there right now.

Are there any temporary instructions how to install the package till the thing gets fully sorted out?

@staletic this is awesome thank you so much for the info! I will add you as a co-maintainer. Let's get this thing cleaned up!

Hello, I'm one of YCM maintainers. I'll be happy to help with packaging YCM.

Regarding git submodules, instead of pulling from git, just purge them and install the dependencies from official repos.

This is the list of direct YCM/ycmd dependencies (let's leave ycmd bundled for now and let's hope this board supports markdown):

• python-bottle
• python-jedi
• python-regex
• python-waitress
• python-future
• python-requests
• python-frozendict
• aur/python-requests-futures

As for completers, TSServer can be installed as an optional dependency and YCM will pick it up if there's no TSServer in third_party.

If this package moves to clangd completer over libclang completer, it could be decoupled too, but the user would need to specify the following

let g:ycm_use_clangd = 1
let g:ycm_clangd_binary_path = 'clangd'

Let's fix those before we dive into decoupling all completers.

I have moved omnisearch-roslyn into it's own package and made it an optional dep. This is still a work in progress, and I will likely need more extensive patches specifically for arch in the future. There is a still a lot of cleanup needed on the git submodules as they should all be listed as sources and not pulled in dynamically per Arch packaging guidelines.

Okay, I have added a simple quick and dirty patch to ycmd that will allow this package to use the existing installed toolchains. I have tested this on my existing account and a fresh account in a chroot. Both seemed to have worked fine for me. If this is an acceptable solution we could decide to re-enable rust support by default.

Interesting regarding rust support. I found this TODO in upstream

https://github.com/ycm-core/ycmd/blob/master/ycmd/completers/rust/rust_completer.py#L89

#TODO: allow users to pick a custom toolchain.

Contemplating making a patch here for this package that could possibly just use the existing default rustup toolchain. The default rustup package actually drops an /usr/bin/rls file which links to rustup and I assume it handles the magic of finding it within each users home directory.

I don't install the package, but follow this to help find bugs when updating you complete me.

I just use:

function! BuildYCM(info)
    if a:info.status == 'installed' || a:info.status == 'updated' || a:info.force
        !./install.py --all --system-libclang
    endif
endfunction

You could probably edit my vim function for bash to just pass all of the flags you need when building different variations of ycm.

@Foucault I am also pretty torn on this, I think anyone doing rust development would be more likely to have rustup installed over rust but I could be wrong. What is very clear though is we need to get rid of this duplication.

Based on the feedback I have gone ahead and disabled building rust support by default in the build options. I will look into cleaning this up a bit more. My initial concern was just getting everything building and working. Again I appreciate all the feedback and suggestions.

People using rust completion probably already have one rust toolchain installed. It's wasted space duplicating everything. What is not completely clear from the installation guide is whether this can be avoided as it requires the nightly version of rust so if your system defaults to stable (the archlinux rust package does) then you cannot work with completion at all.

Personally I would just use the rust language server plugin for vim separately rather than installing loads and loads of duplicate stuff.

@jamesbrink Split packages would make sense for a binary repo, but the killer feature of the manual build options is that we can choose not to build some parts at all.

@artafinde

This is one of my concerns, I am going to dig into it in the morning. There is likely a much much much better way to do this. The original package would not build for me at all. I think having it a split package with something like vim-youcompletme-rust-git or something would be better than all these manual build options. Then you could simply choose which parts to install. All the being said i suspect the instructions on the installation guide are not the best approach, especially for rust.

https://github.com/ycm-core/YouCompleteMe#full-installation-guide

Thank you for the feedback! I will get some changes in here soon

@jamesbrink It compiles OK but the build size is increased from ~150M to 1.1G. Is that expected, seems rather big (I think it's coming from the fact that it includes a rust installation which instead you should be using the installed rust. Maybe switch the default options to n instead of y to reduce complexity or even deprecate some options (like python2).

I have made some updates, the build appears to be working fully for me. I will continue to iterate on this PKGBUILD and clean it up as I can. I welcome any suggestions and co-maintainers. I suspect I might eventually make split packages or add other AUR packages as deps to reduce the complexity of this build.

Hey guys, I just took over this package. It is wildly out of date. I am in the process of cleaning it up. Can who had an existing build give me an idea on what the original package size was?

@Oncer there are a number of changes that need to be made. In the meantime you can disable go in the build options.

The build currently aborts with the following error message: PKGBUILD: line 141: cd: aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/go/src/github.com/mdempsky: No such file or directory

This is due to a change from upstream: https://github.com/ycm-core/ycmd/commit/2650dfd4ed441e1c16788c487ad0a6994ee066ed#diff-15230e5dad94ffaefa7b526c0c1e89e5

A fix to the golang 'use of internal package [...] not allowed' problem that @dlin and others are experiencing can be found in the YCM upstream Full Install Guide (section 6) in the README. It says to build the go packages with 'GOPATH=$(realpath ../../../..) go build', not just 'go build'. Modify the two go build lines and golang completion should build fine for everyone again.

considering the really big amount of build dependencies, do you think it would make sense to also have a vim-youcompleteme-bin?

YCM maintainer here. A few corrections about the PKGBUILD:

• Lines 67, 68, 69 and 70: There are dependencies of "requests", not direct ycmd dependencies.
• Instead of cloning "requests", "requests-futures", "bottle", "frozendict", "python-future", "waitress" and "regex", you can just install the packages system wide and save some space.
• ncurses5-compat-libs is not needed any more
• There's a experimental clangd based completer for C family of languages, if you want to prepare that, but maybe leave it off by default.

Started getting this error because clang has been upgraded to version 8:

13 ctypes.cdll.LoadLibrary( libclang_path ) 14 File "/usr/lib/python3.7/ctypes/init.py", line 434, in LoadLibrary 15 return self._dlltype(name) 16 File "/usr/lib/python3.7/ctypes/init.py", line 356, in init 17 self._handle = _dlopen(self._name, mode) 18 OSError: libclangAST.so.7: cannot open shared object file: No such file or directory

Had to uninstall ycm: sudo pacman -Rdns vim-youcompleteme-git and install again so that it recompiles against new clang.

I have the same experience with tjc. However, apparently removing youcompleteme from my plugin list solves the issue.

Now to contemplate whether installing this package and removing it from my vimrc, or manually compiling it and keeping it in my vimrc is the better thing to do.

Works fine with makepkg -sif for me.

Without a list of steps to reproduce the problem, I'm not able to help.

Can't makepkg,

-> Building Gocode completer... client.go:17:2: use of internal package github.com/mdempsky/gocode/internal/gbimporter not allowed client.go:18:2: use of internal package github.com/mdempsky/gocode/internal/suggest not allowed ==> ERROR: A failure occurred in build().

I don't have more info =(. I install my plugins using vim +PluginInstall +qall. Youcompleteme is in my .vimrc. Then I install YCM "correctly" using the flow I described which is from their front page. It works. If I swap that flow with yay -S vim-youcompleteme-git, then I get: "The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). YCM core library not detected; you need to compile YCM before using it. Follow the instructions in the documentation."

The only instructions that work are those that are on their front page.

@tjc I'm going to need more info. Could you share any error messages or logs?

Even when I build from scratch after creating an nspawn container with:

# pacstrap -i archlinux base base-devel

# systemd-nspawn -b -D archlinux

installing yay and running yay -S vim-youcompleteme-git, I'm not able to reproduce this issue.

YCM only asks for set encoding=utf-8 in my vimrc.

@rubonek using geo, not neo. Running in archlinux/base docker container.

sudo pacman -Syyu python python-pip git gvim

yay -S vim-youcompleteme-git

This clones the correct git files into ~/.vim/bundle/YouCompleteMe, and seems to run a build. However, if I run vim, I get: "The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). YCM core library not detected; you need to compile YCM before using it. Follow the instructions in the documentation."

If, Instead, I install it myself with

cd .vim/bundle/YouCompleteMe git clean -f; git pull; git submodule update --recursive --init; ./install.py --clang-completer

then it works fine. So I don't think it's a YCM issue, I think this package isn't doing something that flow does. I also don't think it's a vimrc issue (I thought maybe it was picking up the wrong python or something) because I am not specifying a specific python version or anything in the latter flow.

@tjc could you please provide the steps to reproduce the problem? Which architecture are you on? Are you using neovim?

This package does not seem to install YCM. After running this package, opening Vim still shows that "YCM:core" is not found. To get around this, I am running:

cd .vim/bundle/YouCompleteMe git clean -f; git pull; git submodule update --recursive --init; ./install.py --clang-completer

This seems to actually install YCM.

@adam900710 Are you sure you are not missing a .ycm_extra_conf.py file? USE_SYSTEM_LIBCLANG is enabled by default in the PKGBUILD.

It looks like clang-completer is not built by default now. "NOT using libclang, no semantic completion for C/C++/ObjC will be available"

Would anyone mind to add -DUSE_CLANG_COMPLETER=ON?

@Trent Thanks for the changes! Looks good to me!

Hello, there are several changes to the ycmd submodule now, that seem to require changes to prepare() and package(). Kind regards! https://pastebin.com/raw/KME34qzJ

@ak-il @Trent thanks for pointing those out! PKGBUILD updated!

@cgorichanaz: read about the -i flag of makepkg: https://wiki.archlinux.org/index.php/Makepkg#Usage

I needed to first install mono:

==> Making package: vim-youcompleteme-git r2451.a53ccefc-1 (Sat 19 Jan 2019 01:53:05 PM PST)
==> Checking runtime dependencies...
==> Missing dependencies:
  -> mono

git+<https://github.com/defnull/bottle.git> has been moved to git+<https://github.com/bottlepy/bottle.git>.

Hello, there is another change to a submodule. Kind regards!

https://pastebin.com/yayK2Yrc or, sed -i.bak 's/kennethreitz/requests/g' PKGBUILD

@urxvtcd-256 looks good to me! Thanks for the patch!

Modified PKGBUILD to also support Typescript: https://pastebin.com/rHmc1tTm First time I'm doing it but it seems to be working :)

@Trent thanks for the changes! Looks good to me!

Several submodules are added or removed. So I made an updated PKGBUILD.

https://pastebin.com/raw/KYQ4XDUA

@petronny please provide more details. How can I reproduce the problem? What are the steps?

@wald00 Change your build directory. IIRC there's a setting in yaourt to tweak that.

Building this package can easily surpass the size of tmpfs.

Hi, could you remove groups=('vim-plugins') from the PKGBUILD? It's not necessary for AUR. And if a third-party repository provides the binary version of this package, it will alter the behavior of installing vim-plugins which may causes somethings, such as tutorials for beginners, fail.

Hello @Rubonnek, I trying to install the package but I have problem compiling. Could you see the logs and give us some tips.

https://pastebin.com/kRVTNtnu

Thanks in advance.

Anytime!

Thanks for fixing. After deleting the pyc files and rebuilding, it's working for me as well now.

@Rubonnek Awesome - works as you suggested. Removed package, delete pyc files under ycmd and recompiled with python3. Changed interpreter to python3 and works fine. Cheers!

@artafinde you have to delete the cached files. python2 bytecode is incompatible with python3. No wonder you had to turn on the python2 interpreter.

Your issue is no different then.

@lahwaacz: rogue files: https://ptpb.pw/EpIR

@artafinde Could you show us the output of this command? (adapted from the wiki)

comm -23 <(find /usr/share/vim/vimfiles | sort) <(pacman -Qlq | sed 's|/$||' | sort)

Also, you did not say if you deleted any of the python bytecode files or even whether pacman complained about it.

@Rubonnek: Might as well be different indeed. The log files empty and the timestamp pyc files are not there. I've tried running without .vimrc and same crash with empty log. strace without .vimrc file: https://ptpb.pw/3mP7

Found a workaround for now. Compiled with _use_system_clang="OFF" and _use_python2="ON". Changed the g:ycm_server_python_interpreter to python2 and now it's working.

Edit: no deletions.

@artafinde that chmod command you are running only changes the permissions to the directory, not the files under it which means that other users will not be able to overwrite the files. Add -R before 777 to chmod and let me know if that helps.

To expose what @lahwaacz said more explicitly, adding the python bytecode files (i.e. the cached files) to the package means that pacman will auto-update those python cached files or removed them when they are unneeded. Which also implies that changing the permissions on those files should be unnecessary.

I think your issue could different that what we've seen so far. Are you YCM logs empty too? Did you delete any of the python bytecode files when pacman complained (if it did)? Any chance you could share them if they are not empty? Have you also tried running vim or gvim without a resource file such as ~/.vimrc or ~/.gvimrc?

Please provide as much information as possible including other things you might have tried. Like I previously said, I'm having a hard time reproducing the crashes you guys are experiencing.

@Rubonnek didn't help on my case. The changes introduced from python 3.7 with PEP-552 is on the way python calculates the byte code to check (see PycInvalidationMode and --invalidation-mode for compileall mode) if it needs to update the cache or not. I think that might be irrelevant though to the issue because even if I give permissions to all users after installing the package (using something like sudo find /usr/share/vim/vimfiles/third_party/ycmd/ -type d -name "__pycache__" -exec chmod 777 {} \;) to write on __pycache__ directories the crash still happens. I have confirmed with strace that the "Permission denied" error is not appearing after the chmod change but the crash still happens.

For the first part of the cache update I'd look on how the repo python packages deal with cache this and try to implement something similar (if needed).

For the crash to me it's still pending, so I can provide the two strace logs.

One without changes, just build vim-youcompleteme-git and start vim. https://ptpb.pw/nmWO

Second is after I've given permission to all users to write on __pycache__ directories under /usr/share/vim/vimfiles/third_party/ycmd https://ptpb.pw/c1ys

@lahwaacz you are absolutely right. I honestly forgot that youcompleteme would run as root and generate the python bytecode files where they show up. I thought however that shouldn't cause any issues with python, but I guess I was wrong.

My eyes completely skipped over the "C++ source code" part. I thought you were talking about compiled libraries. We definitely don't need that. Thanks for that too!

@everyone You'll probably get file conflicts when attempting to install this package now if you ran vim as root previously, but only remove the files that pacman complains about and YouCompleteMe should just work.

@Rubonnek They are not found on my system either, I guess Python creates them as temporary files and then renames them to have just the .pyc suffix. The issue is that the vim-youcompleteme-git package should provide those .pyc files so that they are properly tracked by pacman. Since they are not packaged, they were created automatically when I run vim as root (because normal users don't have permissions to write in the /usr/share/vim/vimfiles/ tree) and I guess the old .pyc files from previous versions of vim-youcompleteme-git were causing the crash, because deleting them apparently fixed it.

As for the C++ sources, I don't think that anything in a Python-based plugin depends on them. Since they are installed manually in the PKGBUILD [1] I don't understand how their omission would cause any troubles with building the package.

[1] https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=vim-youcompleteme-git#n270

Forgot to point out that those .pyc files with dates attached at the end of the filename cannot be found in my system.

If you are experiencing crashes, please open up an issue at the upstream repository. I don't think it's a packaging issue at all now.

@lahwaacz That's quite strange. Trying to open those .pyc files is normal python interpreter behavior, but I do not get system calls trying to open files with epoch times at the end.

The main reasoning for keeping the files where they are is in case there are library or configuration dependencies that make use of relative paths. It may not be necessary to keep them at that exact location, but it's much easier to just build packages that way.

In my strace output I can see many lines such as this:

openat(AT_FDCWD, "/usr/share/vim/vimfiles/third_party/ycmd/third_party/requests/requests/__pycache__/adapters.cpython-37.pyc.140474561687024", O_WRONLY|O_CREAT|O_EXCL|O_CLOEXEC, 0644) = -1 EACCES (Permission denied)

While the package does not provide the bytecode files (.pyc), I still don't understand why it tries to open the files including the timestamp (or whatever) at the end. Anyway, I've uninstalled the package, deleted all those orphaned .pyc files, installed again and now it seems to work...

On a related note, what's the reason for packaging C++ source code files in /usr/share/vim/vimfiles/third_party/ycmd/cpp/?

@doragasu I also tried what you said and I still can't reproduce the crash.

@doragasu for C and C++, are you providing the .ycm_extra_conf.py?

If so, and are still getting a crash, could you post an strace too? I'm looking into this a bit more now.

I also have the crash problem. I have built the plugin from scratch, disabling all the languages (I only need it for C/C++). It crashes each time I open any file, with empty logs.

The crash occurs also with empty .vimrc.

Sure: https://github.com/skddc/vim-config/blob/master/vimrc

I also tried removing all plugins, but same result. It looks to me like the crash is happening within ycmd itself.

Yeah, I don't see anything obvious from the strace either.

@raucao Any chance you could share your ~/.vimrc?

Yup, that's empty. Same as Foucault reported. Hence our vague reports. There's no obvious way to find an actual error. :/

In line 6193 of the strace it reads:

Unexpected exit code 1. Type ':YcmToggleLogs ycmd_38599_stderr_og0n6rv3.log' to check the logs.

Is that log empty too?

Thanks. It's almost 11K lines of log, but here you go: <deleted>

Edit: btw, it's not specific files, it's just opening vim at all that crashes it. So it's not due to a specific language I think.
Edit 2: Sorry, I had to delete that one. I'll post another link.
Edit 3: New log: https://gist.githubusercontent.com/skddc/ea473893710b9d4ffb3e79b53ae41578/raw/b4ab617f35b120b9086c9c99b24853dfdd8a5d74/vim-youcompleteme-strace.log

If ycmd is crashing, then that means the program was launched at some point.

You can do:

strace vim some_file_that_crashes_ycmd.py 2>&1 | tee strace_log

Then just wait a couple of seconds, and type :q to exit vim

Put the strace_log somewhere I can take a look at it. It could be through any of the pastebin clients or just using curl like mentioned in the wiki too: https://wiki.archlinux.org/index.php/List_of_applications#Pastebin_clients

I have already cleared the cache and rebuilt everything before posting here.

I don't know how to use strace in order to trace a program that hasn't been launched yet. Any pointers on how I would use it in this case?

If the issue is still happening, could someone post an strace somehwere?

I'm not able to reproduce the crash at all, not even in a minimal archlinux nspawn. YouCompleteMe only asked to set the encoding to utf-8 in the vimrc.

@raucao, @lahwaacz, have you both built the package from scratch? If you are using an AUR helper, try deleting it's cache for this package. Otherwise downloading the package snapshot, decompressing and running makepkg should just work.

@Rubonnek Crashes with every language for me.

I have the same problem with ycmd crashing right after starting vim/gvim. The log is empty and YcmDebugInfo is very unhelpful

Client logfile: /tmp/whatever
Server errored, no debug info from server
Server running at: <http://whatever>
Server process ID: PID; I can see it spinning up in top and immediately exiting
Server logfiles: stdout + stderr completely empty

Client log file:

2018-10-22 00:49:57,279 - ERROR - The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). Unexpected exit code 1.

This is while editing a python file. Same with a C file. Is this an upstream issue? Of course, fresh install etc.

@Rubonnek It crashes for both Python and C++, I haven't built support for any other language.

I'm not able to reproduce this. Does the crash shows up when editing a file of a specific programming language?

@raucao Hmm, you're right - I have the same problem.

@lahwaacz Yes, that's what I did. I meant to say completely fresh install with fresh sources and everything.

@raucao Re-install will not help, you need to re-compile.

I had just updated my packages yesterday. Upon starting vim it told me to choose a Python 3 interpreter for g:ycm_server_python_interpreter. However, when I set that (or nothing so it uses the default), the server now crashes with an empty error log every time I start vim. Just says "Unexpected exit code 1".

I tried to re-install the entire thing. No errors during installation, same result afterwards. So it looks like that last change broke something.

Thanks for pointing it out. I was looking into it earlier and I think I figured it out. The package should now use python3 by default.

4.18.12-arch1-1 here.

Just downloaded and installed on vim 8.1 huge version with both Python 2.7 and 3.7 dynamically loaded. When launching vim picks python3. For that reason, and because the YCM server is compiled with python2.7 in mind it is necessary to arrange for: let g:ycm_server_python_interpreter = 'python2' in ~/.vimrc. Without the above YCM server crashes make it impossible to work. This is not well documented (let's say "easily derived or found" ;-) ) from available sources ("doc" included!).
I am reporting this here because the AUR way of installing vim-youcompleteme-git is not the one recommended by YCM's developers for x86_64 hosts, and so you may be under the impression that your install was unsuccessful as you come across the above crash reports.

Thanks! I completely missed that last night.

It appears that wget needs to be added to the makedepends array. I ran into this missing dependency when I tried to build in a clean chroot.

Thank you!

@MarcelPa Thanks for the patch!

Did anyone have problems installing the package including golang lately? I had and resolved that modifying the following lines around line 225 in PKGBUILD:

export GOPATH="$GOPATH:$srcdir/YouCompleteMe/third_party/ycmd/third_party/go"
msg2 'Building Gocode completer...' # BuildGoCode()
cd "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/github.com/mdempsky/gocode" || exit
cd "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/github.com/rogpeppe/godef" || exit

And around line 288:

mkdir -p "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/gocode"
mkdir -p "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/go/src/github.com/mdempsky/gocode"
mkdir -p "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/go/src/github.com/rogpeppe/godef"
cp "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/github.com/mdempsky/gocode/gocode" \
    "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/go/src/github.com/mdempsky/gocode/gocode"
cp "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/github.com/rogpeppe/godef/godef" \
    "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/go/src/github.com/rogpeppe/godef/godef"

This may only be a quick hotfix, but also may help someone. I guess this is due to a change in the "third_party" directory which changed the directory structure for dependencies of golang (they were moved into separate folders). Cheers

You are right, it's not needed.

Are the install.sh messages still applicable/recommended/required? There is no file at this location for me.

"echo "==> add: \"let g:ycm_global_ycm_extra_conf = '/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py'\" to your vimrc"
echo "==> remove: \"let g:ycm_global_ycm_extra_conf = '/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/.ycm_extra_conf.py'\" in your vimrc"
"

@edacval Thanks for the patch!

Thank you for pointing that out!

Refactored dependencies. Disabling unwanted completion engines should minimize package size.

Java completion engine has been added to the PKGBUILD.

Hi, just commenting that there is Java support now, too. Would be nice to see :)

@dummys Could you provide more details? Are you using an AUR helper? If so, consider switching to another helper like aurman

'-git' packages from the AUR have a tendency of doing that with certain AUR helpers since their PKGBUILD version are dynamically updated by the pkgver function inside their PKGBUILD

I have a problem with the package, every time it says that It need to be updated, but nothing is updated inside. It always say that it is already installed.

Could you change the PKGBUILD so that mono, nodejs, rust are added to depends and cargo, go, mono, npm to makedepends only when needed? (I.e. when _omnisharp, _gocode, _rust or _tern are set to y.) The same should probably be done with the source array, but I don't know which repo is needed for which option.

I was having a problem with this package where the JediHTTP submodule refused to fetch its files from $srcdir. I resolved the problem by manually copying the repository into the location the submodule was supposed to be, but I couldn't figure out what was actually going wrong.

I am getting this error:

/OmniSharpServer

Unhandled Exception: System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.TypeInitializationException: The type initializer for 'System.ConsoleDriver' threw an exception. ---> System.Exception: Magic number is wrong: 542 at System.TermInfoReader.ReadHeader (System.Byte[] buffer, System.Int32& position) [0x00028] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 at System.TermInfoReader..ctor (System.String term, System.String filename) [0x0005f] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 at System.TermInfoDriver..ctor (System.String term) [0x00055] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 at System.ConsoleDriver.CreateTermInfoDriver (System.String term) [0x00000] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 at System.ConsoleDriver..cctor () [0x0004d] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 --- End of inner exception stack trace --- at System.Console.SetupStreams (System.Text.Encoding inputEncoding, System.Text.Encoding outputEncoding) [0x00007] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 at System.Console..cctor () [0x0008e] in <0cc37f4786fa491387f4cb0ad6d68b47>:0 --- End of inner exception stack trace --- at Mono.XBuild.CommandLine.MainClass.ShowDeprecationNotice () [0x00000] in <febca784b6eb4d049a5ce01e1348bc2b>:0 at Mono.XBuild.CommandLine.MainClass.Execute () [0x0004d] in <febca784b6eb4d049a5ce01e1348bc2b>:0 at Mono.XBuild.CommandLine.MainClass.Main (System.String[] args) [0x00005] in <febca784b6eb4d049a5ce01e1348bc2b>:0 ==> ERROR: A failure occurred in build(). Aborting... :: failed to build vim-youcompleteme-git package(s)</febca784b6eb4d049a5ce01e1348bc2b></febca784b6eb4d049a5ce01e1348bc2b></febca784b6eb4d049a5ce01e1348bc2b>

@devl_archer: you can just change the line:

xbuild /property:Configuration=Release

to:

TERM=xterm xbuild /property:Configuration=Release

This way you make sure this variable is only set for that command.

the mono part is failing to build - one has to add "export TERM=xterm" to fix it. But i am a bit too stupid to do it correctly in the PKGBUILD file - it fails if i put the line there but it will work when i do it in my terminal before installing via pacaur.

I've managed to build it by setting TERM=xterm before the build command

@nodekey: had the same error on mono and I managed to build it in clean chroot.

My YCM doesn't work after I rolling updated my arch. It seems that it relates to mono( just upgraded ), because when I tried to reinstall YCM, I get some error with it.

Is it possible we can get -DUSE_PYTHON2=OFF added to the PKGBUILD file? python3 seems much more appropriate for ArchLinux than Python2 for a vim plugin.

@karel thanks. It is not a problem due to python2/python3 (I can achieve the same result by passing -DUSE_PYTHON2=OFF to cmake). I'm getting the error only with this package (It works if I install it with vim-plug using the provided install.py)

Added an option _neovim to the PKGBUILD file to enable installing directly to neovim.

If anyone finds it useful, or if @0x76 wants to merge; patch is here: https://gist.github.com/illis/da5b2c09641f0a37fcdf211725687087/revisions?diff=split#diff-dfa7cdd9c34798e1af82f172b0822f08

I'm getting an error in the latest version (2258.02f11703-1):

The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). Unexpected exit code 1. Type ':YcmToggeLogs ycmd_xxxxx_stderr_xxxxxxx_.log' to check the logs.

The problem is that the logs are empty... Any ideas? Thanks in advance.

@glitch_cat @bradsk88 I have updated the PKGBUILD, so now installing should work again. I have left out the rm -rf, because I could not replicate the mentioned unicode issue however if that issue still persists after updating please mention it so I can change the PKGBUILD.

@bradsk88 I did everything you recommended and also removed an item from the sha256 hash vector and it worked. Thank you very much.

I was able to get this working again by removing all references to "argparse" from the PKGBUILD file. argparse is rolled into python now so it's no longer needed.

I also had to add this line to the top of my build() function. rm -rf $srcdir/YouCompleteMe/python/ycm/tests

This was to get around an issue with a unicode filename.

@glitch_cat it looks like there was a breaking change upstream: https://github.com/Valloric/ycmd/commit/33b04c92b6bebe02655d450c5e3e3097c730d32d#diff-8903239df476d7401cf9e76af0252622L4

-> Building Tern completer... /tmp/yaourt-tmp-glitch_cat/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/tern_runtime npm notice created a lockfile as package-lock.json. You should commit this file. npm WARN tern_runtime No repository field. npm WARN tern_runtime No license field.

added 28 packages in 1.432s ==> Entering fakeroot environment... ==> Starting package()... cp: cannot stat '/tmp/yaourt-tmp-glitch_cat/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/argparse': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build vim-youcompleteme-git. ==> Restart building vim-youcompleteme-git ? [y/N] ==> ---------------------------------------------- ==>

using yaourt

@bluehood For errors about failing to verify ncurses5-compat-lib please look here: https://aur.archlinux.org/packages/ncurses5-compat-libs/ (more specifically at the first pinned comment) instead of flagging this out-of-date

I think that "boost" is the build dependency and "boost-libs" is the runtime requirement.

Also, at first the plugin fails because it is compiled with python2 and loaded with python3 (this can be worked around by setting a vim variable).