Package Details: vim-youcompleteme-git r2918.3ededaed-1

Git Clone URL: (read-only, click to copy)
Package Base: vim-youcompleteme-git
Description: A code-completion engine for Vim
Upstream URL:
Keywords: completion engine neovim vim ycm
Licenses: GPL3
Submitter: thestinger
Maintainer: artafinde
Last Packager: artafinde
Votes: 165
Popularity: 2.30
First Submitted: 2013-02-05 21:32 (UTC)
Last Updated: 2022-06-14 09:12 (UTC)

Dependencies (19)

Sources (2)

Pinned Comments

artafinde commented on 2021-04-10 13:03 (UTC)

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

Latest Comments

kaffeekind commented on 2022-06-15 13:26 (UTC)

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.

lahwaacz commented on 2021-12-13 17:57 (UTC)

@artafinde: thanks.

artafinde commented on 2021-12-13 13:08 (UTC)

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

lahwaacz commented on 2021-12-13 11:42 (UTC) (edited on 2021-12-13 11:43 (UTC) by lahwaacz)

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!

artafinde commented on 2021-06-10 06:42 (UTC)

staletic: already done

staletic commented on 2021-06-10 06:12 (UTC)

LLVM12 has hit Extra. Time to migrate back?

staletic commented on 2021-06-05 09:51 (UTC)

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

lahwaacz commented on 2021-05-21 22:15 (UTC)

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?

artafinde commented on 2021-05-21 14:05 (UTC)

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

lahwaacz commented on 2021-05-21 13:55 (UTC)

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

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

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

artafinde commented on 2021-05-21 13:36 (UTC)

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

lahwaacz commented on 2021-05-21 11:40 (UTC)

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?

artafinde commented on 2021-05-21 11:35 (UTC)

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.

lahwaacz commented on 2021-05-21 11:28 (UTC)

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...

staletic commented on 2021-05-21 09:41 (UTC)

@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.

lahwaacz commented on 2021-05-21 08:10 (UTC)

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?

artafinde commented on 2021-05-18 20:48 (UTC) (edited on 2021-05-18 20:48 (UTC) by artafinde)

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

staletic commented on 2021-05-01 16:38 (UTC)


We've just dropped the dependency on the following:

  • python-requests-futures
  • python-requests

artafinde commented on 2021-04-10 13:03 (UTC)

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

artafinde commented on 2021-04-09 18:39 (UTC)

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

staletic commented on 2021-04-09 18:35 (UTC) (edited on 2021-04-09 18:37 (UTC) by staletic)

@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.

dviktor commented on 2021-04-09 18:12 (UTC)

got this error today:

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

Herbort11 commented on 2021-02-25 15:10 (UTC) (edited on 2021-02-25 15:25 (UTC) by Herbort11)

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 - cannot open shared object file: No such file or directory
Traceback (most recent call last):
  File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/", line 498, in ImportAndCheckCore
    ycm_core = ImportCore()
  File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/", line 489, in ImportCore
    import ycm_core as ycm_core
ImportError: cannot open shared object file: No such file or directory

It is looking for, but with this clang version we have

wjhandley commented on 2021-02-18 23:43 (UTC)

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

wjhandley commented on 2021-02-18 23:26 (UTC) (edited on 2021-02-18 23:27 (UTC) by wjhandley)

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/", 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/", 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/", 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/", 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/", 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/", 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

artafinde commented on 2021-02-18 12:07 (UTC)

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

staletic commented on 2021-02-18 09:39 (UTC)

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

wjhandley commented on 2021-02-18 09:12 (UTC)

I'm also still getting the error

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

Has anybody found a solution to this?

David01 commented on 2021-01-03 02:33 (UTC) (edited on 2021-01-03 02:34 (UTC) by David01)

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/", 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

lahwaacz commented on 2020-12-12 09:49 (UTC)

@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.

artafinde commented on 2020-12-09 08:20 (UTC)

@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.

staletic commented on 2020-12-09 01:23 (UTC)

@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.

lahwaacz commented on 2020-12-08 23:13 (UTC)

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.

artafinde commented on 2020-12-07 21:33 (UTC)


staletic commented on 2020-12-07 21:19 (UTC)

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

marcin commented on 2020-12-05 08:02 (UTC)

Arch just upgraded python from python 3.8 to 3.9 which broke vim-youcompleteme-git, as 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.

artafinde commented on 2020-12-04 18:23 (UTC) (edited on 2020-12-04 18:36 (UTC) by artafinde)

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

edacval commented on 2020-12-04 17:01 (UTC) Patch to fix prepare() running sed on wrong files and simplify sed substitutions:

diff --git a/PKGBUILD b/PKGBUILD
index 807a9aa..1015438 100644
@@ -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

   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
   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

-  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() {

staletic commented on 2020-11-29 20:01 (UTC)

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


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:

artafinde commented on 2020-11-29 19:35 (UTC) (edited on 2020-11-29 19:36 (UTC) by artafinde)


  • fixed

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

  • fixed

staletic commented on 2020-11-29 18:27 (UTC)

  • -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.

artafinde commented on 2020-11-24 13:29 (UTC)

@Windfisch Thanks for the suggestion - can you please check if this is already fixed on this PKGBUILD:

Windfisch commented on 2020-11-23 20:24 (UTC)

Dear Leonidas,

Currently, Rust support is broken after YCM has moved from RLS to rust-analyzer. I have fixed this in (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

staletic commented on 2020-11-16 21:14 (UTC)

@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.

artafinde commented on 2020-11-15 11:33 (UTC) (edited on 2020-11-15 16:08 (UTC) by artafinde)

@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.

doragasu commented on 2020-11-14 16:07 (UTC) (edited on 2020-11-14 16:07 (UTC) by doragasu)

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.

staletic commented on 2020-11-14 14:22 (UTC)

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.

coldspark commented on 2020-11-14 12:12 (UTC) (edited on 2020-11-14 12:37 (UTC) by coldspark)

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!

commented on 2020-11-10 18:15 (UTC)

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

lahwaacz commented on 2020-07-19 16:06 (UTC)

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

dramm commented on 2020-07-19 15:41 (UTC)

@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?

lahwaacz commented on 2020-07-19 15:22 (UTC)

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

dramm commented on 2020-07-19 15:06 (UTC) (edited on 2020-07-19 15:08 (UTC) by dramm)

@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/'
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 script. See the documentation for more details.
Traceback (most recent call last):
  File "/home/dramm/.vim/bundle/youcompleteme/third_party/ycmd/ycmd/", line 498, in ImportAndCheckCore
    ycm_core = ImportCore()
  File "/home/dramm/.vim/bundle/youcompleteme/third_party/ycmd/ycmd/", 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.

artafinde commented on 2020-07-19 09:32 (UTC)

@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.

dramm commented on 2020-07-18 15:31 (UTC) (edited on 2020-07-18 15:33 (UTC) by dramm)

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 even though I using this package?


raucao commented on 2020-05-11 12:11 (UTC)

@artafinde That was it. Thanks a lot!

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

artafinde commented on 2020-05-11 11:07 (UTC)

@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.

raucao commented on 2020-05-11 10:57 (UTC)

@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

artafinde commented on 2020-05-11 10:53 (UTC)

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

raucao commented on 2020-05-11 10:40 (UTC)

@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.

artafinde commented on 2020-05-11 10:37 (UTC) (edited on 2020-05-11 10:37 (UTC) by artafinde)

@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'

raucao commented on 2020-05-11 10:20 (UTC)

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.)

artafinde commented on 2020-04-28 17:00 (UTC)

@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.

artafinde commented on 2020-04-20 12:36 (UTC) (edited on 2020-04-20 12:36 (UTC) by artafinde)

Updated without version bump

edacval commented on 2020-04-20 10:53 (UTC)

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
@@ -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
+               GO111MODULE=on GOPATH=${_local_GOPATH} go get -trimpath
+               GO111MODULE=on GOPATH=${_local_GOPATH} go clean -modcache
                echo 'Skipping Gocode completer...'

petronny commented on 2020-04-20 06:52 (UTC)

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/
[100%] Built target ycm_core
/startdir/PKGBUILD: line 191: cd: /build/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/go/src/ No such file or directory

artafinde commented on 2020-04-19 11:12 (UTC)

@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

holishing commented on 2020-04-18 12:14 (UTC)

this change about golang third_party part may let YCM not compilable

artafinde commented on 2020-04-14 10:31 (UTC)

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

Rubonnek commented on 2020-04-13 14:37 (UTC)

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

artafinde commented on 2020-03-30 17:38 (UTC)

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


fabwu commented on 2020-03-30 17:25 (UTC)

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?

artafinde commented on 2020-03-30 08:34 (UTC)

@fabwu: use the build options to disable them.

fabwu commented on 2020-03-29 11:34 (UTC)

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.

KarlWithK commented on 2019-12-04 17:21 (UTC)

@Universebenzene Thanks for the fix.

Universebenzene commented on 2019-12-04 12:04 (UTC)

@KarlWithK Seems that a submodule is missed in the PKGBUILD. Possible fix here:

KarlWithK commented on 2019-12-04 11:23 (UTC)

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.

artafinde commented on 2019-11-09 12:54 (UTC)

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

marcin commented on 2019-11-04 23:52 (UTC)

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.

MasterMax commented on 2019-10-28 13:23 (UTC)

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

Universebenzene commented on 2019-10-25 08:06 (UTC) (edited on 2019-10-25 08:07 (UTC) by Universebenzene)

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).

Wrexes commented on 2019-10-15 20:24 (UTC)

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

CountMurphy commented on 2019-10-11 15:13 (UTC)

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

kumala commented on 2019-10-11 13:52 (UTC)

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

Derin commented on 2019-10-10 08:09 (UTC) (edited on 2019-10-10 08:10 (UTC) by Derin)

Apparently msbuild-stable ( ) is also a requirement for C# support.

See the Introduction section of Omnisharp-Roslyn's README:

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

jamesljlster commented on 2019-10-08 07:28 (UTC) (edited on 2019-10-08 07:30 (UTC) by jamesljlster)

@jamesbrink @szemy @unxusr @Excelsior @dviktor

I found that JDTLS 0.45.0 is missing from "".

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 <>
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
@@ -130,7 +130,7 @@ prepare() {

        if [[ "$jdtls_milestone" != "" ]] && [[ "$jdtls_buildstamp" != "" ]]; then
            echo 'JDTLS package version matched. Downloading...'
-           curl -LO${jdtls_milestone}/${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
+           curl -LO${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
            tar xf ${jdtls_package_name}-${jdtls_milestone}-${jdtls_buildstamp}.tar.gz
            echo 'Mismatched JDTLS version'

dviktor commented on 2019-10-07 19:17 (UTC)

Have the same problem with JDTLS and not in gzip format

Excelsior commented on 2019-10-07 07:57 (UTC)

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

unxusr commented on 2019-10-04 20:55 (UTC)

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

szemy commented on 2019-10-04 13:41 (UTC)

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

marcin commented on 2019-07-23 00:19 (UTC)


Its working now. Thank you!

staletic commented on 2019-07-22 13:28 (UTC)


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.

marcin commented on 2019-07-22 11:05 (UTC)


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

jamesbrink commented on 2019-07-21 20:41 (UTC)

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

staletic commented on 2019-07-21 09:14 (UTC)


You should keep an eye on these two:

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


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.

marcin commented on 2019-07-21 04:57 (UTC)

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

jamesbrink commented on 2019-07-19 22:15 (UTC)

@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!

staletic commented on 2019-07-19 13:11 (UTC)

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.

jamesbrink commented on 2019-07-15 08:26 (UTC)

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.

jamesbrink commented on 2019-07-15 01:50 (UTC)

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.

jamesbrink commented on 2019-07-15 00:27 (UTC)

Interesting regarding rust support. I found this TODO in upstream

#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.

zerophase commented on 2019-07-14 23:14 (UTC) (edited on 2019-07-14 23:15 (UTC) by zerophase)

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
        !./ --all --system-libclang

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

jamesbrink commented on 2019-07-14 22:55 (UTC)

@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.

jamesbrink commented on 2019-07-14 22:17 (UTC)

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.

Foucault commented on 2019-07-14 17:45 (UTC) (edited on 2019-07-14 17:49 (UTC) by Foucault)

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.

lahwaacz commented on 2019-07-14 10:20 (UTC)

@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.

jamesbrink commented on 2019-07-14 10:13 (UTC)


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.

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

artafinde commented on 2019-07-14 09:19 (UTC)

@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).

jamesbrink commented on 2019-07-14 07:27 (UTC)

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.

jamesbrink commented on 2019-07-14 04:39 (UTC)

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?

Trent commented on 2019-07-11 12:11 (UTC)

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

Oncer commented on 2019-07-09 08:46 (UTC)

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/ No such file or directory

This is due to a change from upstream:

jaywalker commented on 2019-05-02 23:06 (UTC)

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.

gunix commented on 2019-05-01 12:17 (UTC)

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

staletic commented on 2019-04-15 19:38 (UTC)

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.

marcin commented on 2019-04-06 04:16 (UTC) (edited on 2019-04-06 04:30 (UTC) by marcin)

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/", line 434, in LoadLibrary 15 return self._dlltype(name) 16 File "/usr/lib/python3.7/ctypes/", line 356, in init 17 self._handle = _dlopen(self._name, mode) 18 OSError: 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.

LucidComplex commented on 2019-03-29 19:22 (UTC) (edited on 2019-03-30 08:35 (UTC) by LucidComplex)

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.

Rubonnek commented on 2019-03-20 23:30 (UTC)

Works fine with makepkg -sif for me.

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

dlin commented on 2019-03-20 03:34 (UTC)

Can't makepkg,

-> Building Gocode completer... client.go:17:2: use of internal package not allowed client.go:18:2: use of internal package not allowed ==> ERROR: A failure occurred in build().

tjc commented on 2019-03-13 23:23 (UTC)

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.

Rubonnek commented on 2019-03-13 18:50 (UTC) (edited on 2019-03-13 18:52 (UTC) by Rubonnek)

@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.

tjc commented on 2019-03-12 22:18 (UTC) (edited on 2019-03-12 23:10 (UTC) by tjc)

@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; ./ --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.

Rubonnek commented on 2019-03-12 20:59 (UTC)

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

tjc commented on 2019-03-12 19:35 (UTC)

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; ./ --clang-completer

This seems to actually install YCM.

Rubonnek commented on 2019-02-25 16:56 (UTC)

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

adam900710 commented on 2019-02-25 07:34 (UTC)

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?

Rubonnek commented on 2019-01-31 02:32 (UTC)

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

Trent commented on 2019-01-30 10:23 (UTC)

Hello, there are several changes to the ycmd submodule now, that seem to require changes to prepare() and package(). Kind regards!

Rubonnek commented on 2019-01-20 01:31 (UTC)

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

lahwaacz commented on 2019-01-19 22:13 (UTC)

@cgorichanaz: read about the -i flag of makepkg:

cgorichanaz commented on 2019-01-19 21:57 (UTC)

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

alexkubica commented on 2019-01-08 13:45 (UTC)

git+<> has been moved to git+<>.

Trent commented on 2019-01-08 00:42 (UTC) (edited on 2019-01-08 00:44 (UTC) by Trent)

Hello, there is another change to a submodule. Kind regards! or, sed -i.bak 's/kennethreitz/requests/g' PKGBUILD

Rubonnek commented on 2018-12-23 01:26 (UTC)

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

urxvtcd-256 commented on 2018-12-22 22:56 (UTC)

Modified PKGBUILD to also support Typescript: First time I'm doing it but it seems to be working :)

Rubonnek commented on 2018-12-19 23:08 (UTC)

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

Trent commented on 2018-12-12 08:13 (UTC) (edited on 2018-12-12 08:23 (UTC) by Trent)

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

Rubonnek commented on 2018-11-30 09:36 (UTC)

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

Rubonnek commented on 2018-11-30 09:35 (UTC)

@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.

petronny commented on 2018-11-30 08:06 (UTC)

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.

wald00 commented on 2018-11-29 13:22 (UTC)

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

Thanks in advance.

Rubonnek commented on 2018-10-30 17:00 (UTC)


raucao commented on 2018-10-30 15:10 (UTC)

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

artafinde commented on 2018-10-30 07:39 (UTC)

@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!

Rubonnek commented on 2018-10-30 00:20 (UTC)

@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.

artafinde commented on 2018-10-29 23:21 (UTC)

@lahwaacz: rogue files:

lahwaacz commented on 2018-10-29 23:05 (UTC)

@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.

artafinde commented on 2018-10-29 22:54 (UTC) (edited on 2018-10-29 23:07 (UTC) by artafinde)

@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:

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.

Rubonnek commented on 2018-10-29 21:41 (UTC)

@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.

artafinde commented on 2018-10-29 19:36 (UTC)

@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.

Second is after I've given permission to all users to write on __pycache__ directories under /usr/share/vim/vimfiles/third_party/ycmd

Rubonnek commented on 2018-10-27 18:49 (UTC)

@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.

lahwaacz commented on 2018-10-27 15:53 (UTC)

@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.


Rubonnek commented on 2018-10-27 15:42 (UTC)

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.

Rubonnek commented on 2018-10-27 14:30 (UTC)

@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.

lahwaacz commented on 2018-10-27 14:05 (UTC) (edited on 2018-10-27 14:05 (UTC) by lahwaacz)

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/?

Rubonnek commented on 2018-10-27 13:42 (UTC)

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

Rubonnek commented on 2018-10-27 13:41 (UTC)

@doragasu for C and C++, are you providing the

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

doragasu commented on 2018-10-27 13:10 (UTC)

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.

raucao commented on 2018-10-26 08:19 (UTC)


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

Rubonnek commented on 2018-10-25 20:15 (UTC)

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

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

raucao commented on 2018-10-25 16:09 (UTC) (edited on 2018-10-25 16:09 (UTC) by raucao)

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

Rubonnek commented on 2018-10-25 16:00 (UTC)

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?

raucao commented on 2018-10-25 14:09 (UTC) (edited on 2018-10-25 15:12 (UTC) by raucao)

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:

Rubonnek commented on 2018-10-25 13:56 (UTC)

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

You can do:

strace vim 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:

raucao commented on 2018-10-25 13:06 (UTC)

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?

Rubonnek commented on 2018-10-25 00:50 (UTC)

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

Rubonnek commented on 2018-10-25 00:49 (UTC)

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.

raucao commented on 2018-10-22 09:50 (UTC)

@Rubonnek Crashes with every language for me.

Foucault commented on 2018-10-21 23:56 (UTC) (edited on 2018-10-21 23:57 (UTC) by Foucault)

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.

lahwaacz commented on 2018-10-21 17:50 (UTC)

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

Rubonnek commented on 2018-10-21 15:26 (UTC)

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

lahwaacz commented on 2018-10-21 08:04 (UTC)

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

raucao commented on 2018-10-20 13:33 (UTC)

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

lahwaacz commented on 2018-10-20 11:39 (UTC)

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

raucao commented on 2018-10-20 09:39 (UTC)

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.

Rubonnek commented on 2018-10-18 02:20 (UTC)

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.

Cbhihe commented on 2018-10-15 17:49 (UTC) (edited on 2018-10-15 17:52 (UTC) by Cbhihe)

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.

Rubonnek commented on 2018-10-10 23:29 (UTC)

Thanks! I completely missed that last night.

alaskanarcher commented on 2018-10-10 18:41 (UTC)

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!

Rubonnek commented on 2018-10-08 23:59 (UTC)

@MarcelPa Thanks for the patch!

MarcelPa commented on 2018-10-08 08:32 (UTC) (edited on 2018-10-08 08:35 (UTC) by MarcelPa)

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/" || exit
cd "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/" || 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/"
mkdir -p "$pkgdir/$vimfiles_dir/third_party/ycmd/third_party/go/src/"
cp "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/" \
cp "$srcdir/YouCompleteMe/third_party/ycmd/third_party/go/src/" \

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

Rubonnek commented on 2018-10-04 01:43 (UTC)

You are right, it's not needed.

ixil commented on 2018-10-01 14:42 (UTC)

Are the 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/'\" to your vimrc"
echo "==> remove: \"let g:ycm_global_ycm_extra_conf = '/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/'\" in your vimrc"

Rubonnek commented on 2018-09-13 23:31 (UTC)

@edacval Thanks for the patch!

Rubonnek commented on 2018-09-12 10:39 (UTC)

Thank you for pointing that out!

Rubonnek commented on 2018-09-11 23:04 (UTC)

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

Java completion engine has been added to the PKGBUILD.

commented on 2018-09-10 13:04 (UTC)

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

Rubonnek commented on 2018-08-22 21:34 (UTC)

@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

dummys commented on 2018-08-22 19:27 (UTC)

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.

lahwaacz commented on 2018-08-16 12:43 (UTC)

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.

journcy commented on 2018-07-27 03:29 (UTC)

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.

1CatchMe1 commented on 2018-04-14 23:00 (UTC)

I am getting this error:


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>

swiftscythe commented on 2018-04-06 11:38 (UTC)

@devl_archer: you can just change the line:

xbuild /property:Configuration=Release


TERM=xterm xbuild /property:Configuration=Release

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

devl_archer commented on 2018-04-03 09:53 (UTC)

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.

swiftscythe commented on 2018-03-27 20:53 (UTC)

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

artafinde commented on 2018-03-27 20:47 (UTC)

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

nodekey commented on 2018-03-23 04:08 (UTC)

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.

camio commented on 2018-03-09 16:27 (UTC)

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.

swiftscythe commented on 2018-02-23 08:47 (UTC)

@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

illis commented on 2018-02-15 23:19 (UTC)

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:

swiftscythe commented on 2018-02-14 10:01 (UTC)

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.

0x76 commented on 2018-02-13 20:24 (UTC)

@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.

glitch_cat commented on 2018-02-13 19:19 (UTC)

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

bradsk88 commented on 2018-02-13 06:04 (UTC)

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.

bradsk88 commented on 2018-02-13 05:21 (UTC) (edited on 2018-02-13 05:22 (UTC) by bradsk88)

@glitch_cat it looks like there was a breaking change upstream:

glitch_cat commented on 2018-02-13 01:46 (UTC)

-> 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

0x76 commented on 2017-12-20 20:25 (UTC)

@bluehood For errors about failing to verify ncurses5-compat-lib please look here: (more specifically at the first pinned comment) instead of flagging this out-of-date

ejno commented on 2017-12-09 04:41 (UTC)

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).

commented on 2017-10-31 20:26 (UTC)

Is there any reason ycm_core is compiled with python2 instead of python3?

edacval commented on 2017-09-22 20:34 (UTC)

@unxusr Just rebuild and will work again

unxusr commented on 2017-09-22 16:29 (UTC)

Not working after arch update clang to 5.0. Got the error: ImportError: cannot open shared object file: No such file or directory.

zerophase commented on 2017-09-22 02:31 (UTC)

Anyone else recently see YCMD start failing to compile the C# portions? Which package should I get the Roslyn compiler from?

Disinterpreter commented on 2017-08-25 12:36 (UTC)

@lahwaacz ok, thanks.

lahwaacz commented on 2017-08-25 08:41 (UTC)

@CookDark: That's irrelevant here, see

Disinterpreter commented on 2017-08-25 08:38 (UTC)

==> Retrieving sources... -> Downloading ncurses-6.0-20170527.tgz... % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 curl: (22) The requested URL returned error: 404 Not Found ==> ERROR: Failure while downloading Aborting... ==> ERROR: Makepkg was unable to build ncurses5-compat-libs.

wijagels commented on 2017-08-06 18:29 (UTC)

@linsinn make sure gcc is installed and not broken.

linsinn commented on 2017-08-06 17:34 (UTC)

"checking for C compiler default output... configure: error: C compiler cannot create executables" This error occurred when installed ncurses5-compat-libs, any ideas?

ericvipo commented on 2017-07-29 11:49 (UTC)

I installed "vim-youcompleteme-git" correctly but this does not work :/ can anybody help me? ►

lahwaacz commented on 2017-06-29 15:34 (UTC)

@rrt: The ncurses5-compat-libs package builds just fine. You should invest some time to learn how to use the PGP signature verification properly - read the pinned comment of the ncurses5-compat-libs package:

rrt commented on 2017-06-29 15:23 (UTC)

Is it possible to change the ncurses5-compat-libs dependency to something more up-to-date which seems to have quite some issues with the PGP signature verification & automation?

lahwaacz commented on 2017-06-26 09:13 (UTC)

The depends and makedepends fields should depend on the build options specified by the user at the top of the PKGBUILD:

Poroing commented on 2017-05-03 20:29 (UTC)

@wijagels Okay it was actualy an error from my part, sorry, I didn't cleaned the old build directory before rebuilding the package so I guess the old which was present in the directory was used to build YCM.

lahwaacz commented on 2017-05-03 19:23 (UTC)

@edacval: Simply try to rebuild the package first when it stops working instead of raging on the AUR...

lahwaacz commented on 2017-05-03 17:32 (UTC)

@edacval: It's the user's responsibility to rebuild AUR packages, not the packager's.

wijagels commented on 2017-05-03 16:42 (UTC)

@Poroing there's nothing wrong with the build, it just needs to be completely rebuilt because of the update to clang 4.0.

Poroing commented on 2017-05-03 16:40 (UTC)

YouCompleteMe can't start because it can't found It is apprentely searching, I don't know where and I don't know how to force YCM to print where it is searching out I saw that in the PKGBUILD USE_SYSTEM_LIBCLANG is set to ON and in the makepkg log for the build command I saw that the external path for libclang was set to src/clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-14.04/lib/ but the version of libclang on my system is, and a find / -name ** told me that is nowhere but in the build directory of the package Could there be an issue with the build process?

wijagels commented on 2017-03-22 17:45 (UTC)

The python2 dependency for tern is because of node-gyp which only works with python2. However, it doesn't have to manually be set in npm flags anymore, that's been fixed for a while now.

Fandekasp commented on 2017-03-12 10:09 (UTC)

@edacval, are you sure? l.46, python2 is a dependency, and l.146, the Tern completer is installed with python2, sounds like it might cause some issues.

MasterMax commented on 2017-03-11 15:24 (UTC)

@victorheld: yeah "let g:ycm_server_python_interpreter = '/usr/bin/python2'" fixed it :)

0x76 commented on 2017-03-10 16:05 (UTC)

@MasterMax I'm not exactly sure why this error occurs but maybe "ycm_core library compiled for Python 2 but loaded in Python 3." has something to do with it. You could try setting "let g:ycm_server_python_interpreter - '/usr/bin/python2' " in your .vimrc to try if that fixes the problem. Otherwise I'm afraid I can't help you.

MasterMax commented on 2017-03-10 15:43 (UTC)

the update from 2017-03-08 breaks the plugin: I added let g:ycm_global_ycm_extra_conf = '/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/'to my .vimrc as displayed on installation (not adding this also results in youcompleteme not working). auto completion is missing completely. :YcmDebugInfo shows ... -- Server errored, no debug info from server ... the error-log shows: 2017-03-10 16:37:36,900 - ERROR - Error occurred while loading global extra conf /usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/ Traceback (most recent call last): File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/../ycmd/", line 95, in _CallGlobalExtraConfMethod module = Load( global_ycm_extra_conf, force = True ) File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/../ycmd/", line 174, in Load module = LoadPythonSource( _RandomName(), module_file ) File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/../ycmd/", line 392, in LoadPythonSource return importlib.machinery.SourceFileLoader( name, pathname ).load_module() File "<frozen importlib._bootstrap_external>", line 399, in _check_name_wrapper File "<frozen importlib._bootstrap_external>", line 823, in load_module File "<frozen importlib._bootstrap_external>", line 682, in load_module File "<frozen importlib._bootstrap>", line 251, in _load_module_shim File "<frozen importlib._bootstrap>", line 675, in _load File "<frozen importlib._bootstrap>", line 655, in _load_unlocked File "<frozen importlib._bootstrap_external>", line 678, in exec_module File "<frozen importlib._bootstrap>", line 205, in _call_with_frames_removed File "/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm/", line 32, in <module> import ycm_core ImportError: dynamic module does not define module export function (PyInit_ycm_core) 2017-03-10 16:37:36,901 - ERROR - ycm_core library compiled for Python 2 but loaded in Python 3. Traceback (most recent call last): File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/", line 95, in CompatibleWithCurrentCore ycm_core = ImportCore() File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/", line 87, in ImportCore import ycm_core as ycm_core ImportError: dynamic module does not define module export function (PyInit_ycm_core)

AKSoo commented on 2017-01-30 17:39 (UTC)

@biosin That directory has been recently removed. Just removing retries in PKGBUILD should work. Flagged.

OneObsession commented on 2017-01-29 17:50 (UTC)

@biosin yes, i have the same problem. A few days ago it didn't occur.

commented on 2017-01-29 17:11 (UTC)

package() fails with error: cp: cannot stat '/home/[user]/.cache/pacaur/vim-youcompleteme-git/src/YouCompleteMe/third_party/retries': No such file or directory Anyone else got the same problem?

yan12125 commented on 2016-12-29 03:56 (UTC)

@leemeng0x61 The binary package (*.pkg.tar.xz) is not provided by @tata but Stephen Zhang. Ask him for why his package is broken.

leemeng0x61 commented on 2016-12-29 03:43 (UTC)

Broken pkg, vim-youcompleteme-git-1969.8161d350-4-x86_64.pkg.tar.xz invalid or corrupted package (PGP signature) error msg ```bash error: vim-youcompleteme-git: signature from "Stephen Zhang (lazy...) <>" is invalid :: File /var/cache/pacman/pkg/vim-youcompleteme-git-1969.8161d350-4-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). ```

wijagels commented on 2016-11-03 21:29 (UTC)

@tata could you update this package to properly install the clang_includes folder? Zemen's PKGBUILD worked very well for me.

zemen commented on 2016-10-05 13:10 (UTC)

@tata: Here are my PKGBUILD and PKGBUILD: I also slightly modified pkgbuild in order to be able to choose completers for building

eberan commented on 2016-09-26 19:25 (UTC)

I'll be disowning the package now; No time to put into it right now. Keep it going please :-]

tata commented on 2016-09-24 14:23 (UTC)

@lahwaacz: sorry for that. I had fix it. I dont wanna impolite. @zemen: could you please send me your PKGBUILD ? cheers Tarek

lahwaacz commented on 2016-09-13 06:57 (UTC)

Removing the past maintainers and contributors from the PKGBUILD [1] is impolite at best. Also, you've failed to enter your name - instead, Erik Beran is listed twice. [1]

zemen commented on 2016-09-12 22:10 (UTC)

Clang completion still works improperly as clang is unable to find <float.h>. I fixed the problem this way: 1. Included "YouCompleteMe/third_party/ycmd/cpp" and "YouCompleteMe/third_party/ycmd/clang_includes" folders into the package in PKGBUILD(at this moment they are just ignored). 2. Set relative_to = "/usr/share/vim/vimfiles/third_party/ycmd/cpp/ycm" instead of "DirectoryOfThisScript()" in my at the end of default config). 3. Added '-isystem', '../../clang_includes/include' to the list of flags in

tata commented on 2016-09-12 10:53 (UTC)

Hi, @carmelo12341, @wijagels: Thanks for your help! I have just pushed a new version, were I have cleaned up the pkg code and also add and tested the _COMPLETER="USE_SYSTEM_LIBCLANG" flag. :) Shold work now. @lahwaacz: Thanks for that tip :)

commented on 2016-09-11 05:05 (UTC)

@wijagels I fixed the C/C++ issue by adding this line to the file: _COMPLETER="USE_SYSTEM_LIBCLANG" In the commit about using system clang, that line was removed (maybe none of the mantainers use c/c++ to notice the issue). Right now the PKGBUILD has a bunch of unused variables and references to non existing ones, I expect it to be fixed in next commit.

wijagels commented on 2016-09-08 14:36 (UTC)

This package has stopped working for me on C/C++ files, claims not to have any semantic completers for the filetype. ``` 2016-09-08 10:33:26,552 - ERROR - No semantic completer exists for filetypes: [u'cpp'] Traceback (most recent call last): File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/../ycmd/", line 100, in FiletypeCompletionAvailable self.GetFiletypeCompleter( filetypes ) File "/usr/share/vim/vimfiles/third_party/ycmd/ycmd/../ycmd/", line 90, in GetFiletypeCompleter current_filetypes ) ) ValueError: No semantic completer exists for filetypes: [u'cpp'] ```

lahwaacz commented on 2016-08-18 19:51 (UTC)

Please revert this commit: People can easily set MAKEFLAGS in makepkg.conf if they want parallel build. Particularly, there is no reason to eat 200% of people's CPU...

NeoTheFox commented on 2016-08-14 10:50 (UTC)

We don't need an external clang for x86_64 anymore I think - it builds just fine for me with 3.8.1-1

Universebenzene commented on 2016-08-02 02:44 (UTC)

error: failed to prepare transaction (could not satisfy dependencies) :: vim-youcompleteme-git: installing clang (3.8.1-1) breaks dependency 'clang=3.8.0' Maybe some dependencies need changing...

tata commented on 2016-07-02 07:28 (UTC)

@eberan Thanks, I did it. How do you handle the pkg version?

eberan commented on 2016-07-01 23:18 (UTC)

@tata Don't forget to update the .SRCINFO as well. (I usually build a source package then extract it)

tata commented on 2016-07-01 00:16 (UTC)

Depends now fixed in 607d9263c5e91ba306e32281225c1c9237f9aedd

eberan commented on 2016-06-30 22:06 (UTC)

@tata I've made you co-maintainer. Can you fix/change the dependency mentioned by @confusedfla and try pushing up?

tata commented on 2016-06-26 16:28 (UTC)

@eberan: If you want, I can maintain that package.

eberan commented on 2016-06-24 19:53 (UTC)

@confusedfla Thanks for the update, I'll make the change soon. As a general notice, I'll be stepping away from maintaining this package (soon-ish). If someone would step up as maintainer or co-maintainer, it would be appreciated.

confusedfla commented on 2016-06-20 00:31 (UTC)

It seems like ncurses5-compat-libs now replaces libtinfo5.

eberan commented on 2016-05-28 04:17 (UTC)

commit 155682421348b6d2c2eb591eb1ee95440b9200dc Date: Fri May 27 21:12:58 2016 -0700 Updating depends for libtinfo-5 Replacing libtinfo-5 with libtinfo5, as the former is a deprecated package name.

hav3lock commented on 2016-05-24 22:32 (UTC)

libtinfo-5 will be now called libtinfo5, please update your package accordingly.

shmilee commented on 2016-05-22 12:41 (UTC)

About ERROR: unknown public key 0FC3042E345AD05D If I use `makechrootpkg` to make package, where should I run "gpg --recv-keys 0FC3042E345AD05D"?

vnen commented on 2016-05-10 16:01 (UTC)

@ericklopez76 it means you don't have the PGP key. Run "gpg --recv-keys 0FC3042E345AD05D" and try again.

ericklopez76 commented on 2016-05-09 07:13 (UTC)

==> Verifying source file signatures with gpg... clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D) ==> ERROR: One or more PGP signatures could not be verified! ==> ERROR: Makepkg was unable to build vim-youcompleteme-git.

eberan commented on 2016-05-04 21:31 (UTC)

@Sam_DM Fixed, thanks for the notification.

Sam_DM commented on 2016-05-03 15:14 (UTC)

Using yaourt, I get the following error while building: ``` -> Building Tern completer... /tmp/yaourt-tmp-sam/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/tern_runtime npm WARN tern_runtime No repository field. npm WARN tern_runtime No license field. ==> Entering fakeroot environment... ==> Starting package()... cp: cannot stat '/tmp/yaourt-tmp-sam/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/': No such file or directory ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build vim-youcompleteme-git. ``` I tried finding in the Valloric/ycmd github repo, and I found out it was deleted in commit 85d5f6.

eberan commented on 2016-04-30 22:28 (UTC)

@blueyed fixed. Could've sworn I got that in the last commit! >_<

blueyed commented on 2016-04-30 15:52 (UTC)

.SRCINFO needs to be updated for the libtinfo-5 fix/change.

eberan commented on 2016-04-20 19:50 (UTC)

@rrego6 It looks like you had vim-youcompleteme installed in your user ~/.vim directory. You shouldn't use package along with your own install, whether it be manual, Vundle or any other vim plugin manager. If you want to use this package, remove your local user install and .vimrc install directive (i.e. Plugin 'Valloric/vim-youcompleteme.git'). This package installs under the global vim directory, and so its use is available to all users.

rrego6 commented on 2016-04-18 23:17 (UTC) (edited on 2016-04-19 05:49 (UTC) by rrego6)

edit2: It works I was getting this error ( ycm_core.[so|pyd|dll] not detected; you need to compile YCM before using it. Read the docs!). When I tried to use vim, I also got an error looking like this whenever I start vim. I copied over the files in the /usr/share/vim/vimfiles/third_party/ycmd folder into my ~/.vim/bundle/YouCompleteMe/third_party and YCM seems to work now (tested a C file). Is there a reason that we use the /usr/shar/vim directory? It looks like the PKGBUILD specifically chooses to copy everything there.

eberan commented on 2016-04-18 19:22 (UTC)

@rrego6 I've never seen that output before. How are you building? Can you verify that you have the files installed in /usr/share/vim/vimfiles/third_party/ycmd? Note that ycm_client_support is no longer built or required by ycm[d].

eberan commented on 2016-04-18 19:18 (UTC)

@yan12125 Thanks for the notification. commit a5423dd02e56851f04302d9ede980fa4a824400d Author: Erik Beran <> Date: Mon Apr 18 12:14:43 2016 -0700 Updating libtinfo dependency libtinfo has dropped its libtinfo*.5 creation, and so libtinfo-5 replaces libtinfo as a dependency. libtinfo-5 in turn has another dependency that requires gpg verification. Please see that AUR package page for details.

rrego6 commented on 2016-04-18 18:44 (UTC)

AUR package seems to install 'sucessfully'. However, there doesn't seem to be any change in YCM. The 'ycm_client_support.[so|pyd|dll] and ycm_core.[so|pyd|dll] not detected; you need to compile YCM before using it.' error message is show when starting vim. Are there any extra step to follow?

yan12125 commented on 2016-04-18 06:47 (UTC)

As libtinfo removes, ycm should now depend on libtinfo-5.

Melon_Bread commented on 2016-04-14 23:46 (UTC)

@yan12152 Your steps worked perfectly on neovim after installing this package

yan12125 commented on 2016-04-13 18:45 (UTC)

Here are my steps: 1. Install neovim and python3-neovim 2. Add the following line to .vimrc (or init.vim in neovim) let g:ycm_python_binary_path = '/usr/bin/python3' 3. Use vim files in neovim: if has('nvim') set runtimepath+=/usr/share/vim/vimfiles endif 4. `$ nvim` and happy completing :D I don't know how to force authentic vim to run with Python 3, though.

whynothugo commented on 2016-04-13 18:34 (UTC)

@yan12125 That's the same link I provided. It does not answer my question which is "Has anyone else had different results [on arch, with arch's vim package]?"

yan12125 commented on 2016-04-13 17:52 (UTC)


whynothugo commented on 2016-04-13 17:46 (UTC)

Upstream states that this should work with python3 now. Has anyone gotten this packages working out-of-the-box with python3? It seems that for some reason, vim tries to use python2 to run the server, so it fails: Has anyone else had different results?

eberan commented on 2016-04-12 17:46 (UTC)

@idiotbox I understand, thank you for posting. It's important that everyone does that when they have issues, whether it's building, packaging, installing, or using. The issue with PGP isn't specifically with you, but a trend. I will look into communicating the requirement to add the key more visibly. We will keep the PGP requirement for the time being. @siosm I appreciate your use-case (actually reading the PKGBUILD), as without doing so, or watching the build process, the key/signature verification doesn't add security. Let's keep the verification for now at least.

idiotbox commented on 2016-04-12 05:30 (UTC) (edited on 2016-04-12 06:49 (UTC) by idiotbox)

@eberan: I apologize. My intent was actually to help. I mistaked the PGP error for a SHA256SUM error. Thanks for the reply.

Siosm commented on 2016-04-12 01:55 (UTC)

@eberan: It's really a shame that people rush to post unhelpful comments without even reading error messages :(. Even though I think the GPG verification does improve security, if you really want to remove it then at least keep it in the PKGBUILD but as a commented line. Those that actually do read PKGBUILDs before building them may uncomment it :).

eberan commented on 2016-04-12 01:32 (UTC)

Considering the gpg requirement is tripping up a lot of people, and doesn't provide a whole lot of security since I, or any maintainer, can just replace that portion of the PKGBUILD script anyway I think I will be removing the signature verification. Since I check the SHA256SUM and signature prior to packaging anyway, I see the key verification as redundant and an annoyance. Any comments are welcome, before I make the change.

eberan commented on 2016-04-12 01:25 (UTC)

@idiotbox you need to add the pgp key to your keychain for verification. Please check to verify the correct fingerprint and run: gpg --recv-keys 0fc3042e345ad05d

idiotbox commented on 2016-04-11 21:50 (UTC)

Getting shasum fail in clang+lvvm libs. ==> Verificando assinatura de arquivo fonte com gpg... clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz ... FALHOU (chave pública desconhecida 0FC3042E345AD05D) ==> ERRO: Uma ou mais assinaturas PGP não puderam ser verificadas! ==> ERRO: Makepkg não conseguiu compilar .

eberan commented on 2016-04-09 00:01 (UTC)

@hobarrera It looks like your patch is to (re)include python-futures as a package dependency, rather than using the one in the source/package. Is that correct? I made the change *away* from the package dependency as it seemed to/was causing issues and upstream had no interest in supporting us with custom dependencies. Unless you have a compelling reason to make that change, I'd rather keep things as close to upstream as possible. (see the comment history, from around beginning of March, for the relevant conversation and issues.)

eberan commented on 2016-04-08 23:55 (UTC)

@colonelmo I mean if you're using makepkg, make sure you're building from an empty directory as apposed to one with older builds in it. My build was broken until I removed the llvm 3.7.0 package and headers for example. I believe pacaur will always build in a new/clean directory (/tmp/<something>)

colonelmo commented on 2016-04-08 12:34 (UTC)

@eberan Thanks, but what do you mean "clean environment"?

whynothugo commented on 2016-04-07 23:31 (UTC)

Actually, it doesn't require an account - I made the silly mistake of creating a private snippet. I've made it public now. :)

eberan commented on 2016-04-07 23:01 (UTC)

@hobarrera gives me a 404

eberan commented on 2016-04-07 22:56 (UTC)

@hobarrera FYI gitlab requires an account. I'll create one anyway but gist/pastebin is more publicly accessible.

whynothugo commented on 2016-04-07 22:49 (UTC)

I've been working on a branch that uses system libs rather than pulling the source for so many. Here's a sample diff that uses the system python2-requests: If these changes would be acceptable to you, I'll work on applying these changes to all the other submodules. Note that right now, build fails for me with the below error, but other than that, this works fine.

whynothugo commented on 2016-04-07 22:46 (UTC)

==> Starting build()... -> Building ycmd... CMake Error at CMakeLists.txt:32 (project): The CMAKE_C_COMPILER: /usr/lib/hardening-wrapper/bin/cc is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. CMake Error at CMakeLists.txt:32 (project): The CMAKE_CXX_COMPILER: /usr/lib/hardening-wrapper/bin/c++ is not a full path to an existing compiler tool. Tell CMake where to find the compiler by setting either the environment variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path to the compiler, or to the compiler name if it is in the PATH. -- Configuring incomplete, errors occurred! See also "/home/hugo/workspace/Build/aurdata/vim-youcompleteme-git/src/ycmd_build/CMakeFiles/CMakeOutput.log". ==> ERROR: A failure occurred in build().

eberan commented on 2016-04-07 17:29 (UTC)

@colonelmo I hadn't updated yet, but it should be up now. Please try again, with a clean environment (the clang 3.7 package/headers screwed up my build)

colonelmo commented on 2016-04-07 10:08 (UTC)

I installed libtinfo and ycm still fails to build: cannot stat '/home/colonelmo/aur/ycm/src/ycmd_build/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/lib/': No such fil│ e or directory

eberan commented on 2016-04-07 02:08 (UTC)

3.8.0 issue solved; just needed a clean environment. New issue; libclang requires This is only provided by the AUR package libtinfo, which just symlinks to Unfortunately, makepkg cannot pull dependencies from AUR, so we may be stuck with a manual install of that package...

eberan commented on 2016-04-07 00:55 (UTC)

@artafinde thanks for the info; I ran the installer just a few days ago and it was working fine with 3.7.0, strange! Anyway, I've locally updated to 3.8.0 but there seem to be some build errors in ycm_core clang completer. Will push the 3.8.0 update when I get it sorted out.

johntyree commented on 2016-04-06 18:09 (UTC)

Another handy way to get this to work is force it to use your system clang install (which of course you'll have to install). I did it by editing the pkgbuild to remove all of the x86_64 specific parts.

artafinde commented on 2016-04-06 09:16 (UTC)

The build fails. Seems like it's downloading 3.8.0 clang instead of using the package version? Error is ==> Starting package()... cp: cannot stat '/home/inglor/cowerPkg/vim-youcompleteme-git/src/ycmd_build/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/lib/': No such file or directory

oryband commented on 2016-04-03 08:36 (UTC)

@marmistrz Note that you can easily install YCM via vim-plug plugin manager (a newer, maintained and version of Vundle with parallel support), and supply the language parameters for ./ on your on. Check their readme.

marmistrz commented on 2016-04-03 08:29 (UTC)

@eberan: I'd rather go for a minimal version which would enable only what's found in here, listing the others as optional dependencies. All the other could be either enabled manually or by some script or by reinstalling.

eberan commented on 2016-04-01 21:16 (UTC)

@marmistrz regarding unused language support; right now this package will enable all features/languages available. I may, or someone else can, fork this package enabling only specific features (such as those available through clang, or only js/ts or similar). At the very least I will try to make it apparent what to remove from the current script to disable language, but I have no ETA on this.

eberan commented on 2016-04-01 20:51 (UTC)

@marmistrz I guess I should add a readme or something; you need to add the ubuntu packagers public (gpg) key for clang/llvm package verification. Something like this, but please check yourself: gpg --recv-keys 0fc3042e345ad05d

marmistrz commented on 2016-04-01 16:30 (UTC) (edited on 2016-04-01 16:30 (UTC) by marmistrz)

Cannot install YCM: ==> Verifying source file signatures with gpg... clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D) Besides, is it possible to make go, cargo, rust optdepends? I don't program in them, and I'd rather avoid polling 330 MB of my disk space for these packags.

oryband commented on 2016-03-13 13:24 (UTC) (edited on 2016-03-13 13:24 (UTC) by oryband)

@eberan yup, this fixes it. Thanks for the tech support! :) Note the "can't translate pathname" issue I mentioned still persists.

eberan commented on 2016-03-11 05:05 (UTC)

@oryband It looks like the PR was merged; did it fix your issue?

oryband commented on 2016-03-09 21:10 (UTC) (edited on 2016-03-09 21:17 (UTC) by oryband)

UPDATE: PR is here, waiting for it to be merged: @ebearn i've started seeing similar issues upstream: EDIT: notice the easy reproducible steps there: 1. let g:ycm_seed_identifiers_with_syntax = 1 2. open vim 3. `:setf git` I'm using to machines regularly, and after upgrading the second one today I've started seeing the same errors too (the unicode error and the pacakging errors in the other message i wrote). I'm using latest zsh, vim, both machines use ext4. Nothing extraordinary that I can think of. File system is ext4 on both. My .vimrc is here, nothing special there: I think this has something to do with the new python 3 support, and not something specific to Arch.

eberan commented on 2016-03-09 18:04 (UTC)

@oryband Interesting, I wonder if anyone else is seeing this issue. Try disabling other vim plugins you might have enabled? Maybe try with an otherwise vanilla vimrc? Ensure your other AUR packages are up-to-date. Your packaging issue is really strange; I can't remember if makepkg always uses the same shell or uses the user/current shell; maybe that has some effect, what shell are you using? I doubt that filesystems would be an issue, but what fs is this on?

oryband commented on 2016-03-09 13:39 (UTC)

@eberan This happens without using a virtualenv and happens randomly when `git commit`ing stuff, which causes Vim to open in a gitcommit buffer. I'll try building it manually. If you have any other suggestion I'd be happy to hear.

eberan commented on 2016-03-08 23:15 (UTC)

@oryband I'm not seeing the packaging error. I'm also not getting your git commit errors; I get one error in the log when the server starts up but it doesn't seem to effect anything. Perhaps something in your (virtual) environment is disagreeing with ycmd? It would be interesting to see if you get the runtime errors with a non-packaged build of ycmd (i.e. clone and build into install location as per upstream installation guide). If it is reproducible we can push it upstream, assuming they support such an environment.

oryband commented on 2016-03-08 09:27 (UTC)

In addition, there are some errors in the installation: ==> Creating package "vim-youcompleteme-git"... -> Generating .PKGINFO file... -> Generating .BUILDINFO file... -> Adding install file... -> Generating .MTREE file... -> Compressing package... bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.userprefs: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.userprefs' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.sln: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.sln' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.csproj: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/a project.csproj' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Properties/: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Properties/' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Program.cs: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Program.cs' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Properties/AssemblyInfo.cs: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/cs/testdata/неприличное слово/Properties/AssemblyInfo.cs' to UTF-8 bsdtar: usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/testdata/filename_completer/inner_dir/foo漢字.txt: Can't translate pathname 'usr/share/vim/vimfiles/third_party/ycmd/ycmd/tests/testdata/filename_completer/inner_dir/foo漢字.txt' to UTF-8 ==> Leaving fakeroot environment. ==> Finished making: vim-youcompleteme-git 1747.381b213-1 (Tue Mar 8 11:20:41 IST 2016)

oryband commented on 2016-03-08 09:08 (UTC)

@eberan very well. In addition, I also started getting tons of UnicodeDecodeError in gitcommit buffer types and sometimes randomly in other buffer types as well. Needless to say there aren't any esoteric unicode chars in the buffer. "~/Documents/.git/COMMIT_EDITMSG" 9L, 379C Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: Traceback (most recent call last): Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "<string>", line 1, in <module> Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "/usr/share/vim/vimfiles/autoload/../python/ycm/", line 266, in OnFileReadyToParse Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: self._AddSyntaxDataIfNeeded( extra_data ) Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "/usr/share/vim/vimfiles/autoload/../python/ycm/", line 623, in _AddSyntaxDataIfNeeded Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: syntax_parse.SyntaxKeywordsForCurrentBuffer() ) Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "/usr/share/vim/vimfiles/autoload/../python/ycm/", line 93, in SyntaxKeywordsForCurrentBuffer Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: return _KeywordsFromSyntaxListOutput( syntax_output ) Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "/usr/share/vim/vimfiles/autoload/../python/ycm/", line 97, in _KeywordsFromSyntaxListOutput Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: group_name_to_group = _SyntaxGroupsFromOutput( syntax_output ) Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: File "/usr/share/vim/vimfiles/autoload/../python/ycm/", line 113, in _SyntaxGroupsFromOutput Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: lines = syntax_output.split( '\n' ) Error detected while processing function youcompleteme#Enable[70]..<SNR>145_OnBufferVisit[18]..<SNR>145_OnFileReadyToParse: line 13: UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 989: ordinal not in range(128)

eberan commented on 2016-03-07 20:10 (UTC)

I know this will get lost as more comments come in but; Don't post bugs to upstream unless you know for a fact there is an issue not to do with packaging or dependencies. It's generally better to just let me, or any interested co-maintainer, investigate and fix the issue and/or deal with filing upstream issues.

eberan commented on 2016-03-07 20:04 (UTC)

commit c1cf1eb5ab34510916068d73f136756a5d0179e4 Author: Erik Beran <> Date: Mon Mar 7 11:59:25 2016 -0800 Using bundled python-future package, clearer PKGBUILD src dependencies Correctly pulling python-future source for bundle rather than package dependency. There is potential for using the system one..needs some testing, but we will guarantee loss of upstream support (which I guess we already have because of system level packaging). Reordered git module URLs and added some tags as to where they exist or what project depends on them.

oryband commented on 2016-03-07 13:29 (UTC) (edited on 2016-03-07 15:00 (UTC) by oryband)

I've started getting this inside virtualenvs after updating: "The ycmd server SHUT DOWN (restart with ':YcmRestartServer'). Logfile was deleted; set 'g:ycm_server_keep_logfiles' to see errors in the future." Completion for Python 2 in virtualenv stopped working since this crashed the server. Notice that YCM added Python 3 support lately, which might have screwed things over: EDIT: I fixed it by "pip install future" with the virtualenv activated. Can't we make virtualenvs fallback to the the global (non virtualenv) future package if not installed inside the virtualenv? EDIT: I've opened an issue upstream, and they pointed there's no need to install the package stated above, as it is bundled in YCM. You should probably remove this. Flagging as out of date

tata commented on 2016-03-04 15:07 (UTC)

@eberan Thanks! The problem wars the package rust-git from AUR

eberan commented on 2016-03-04 01:01 (UTC)

@tata I just did a clean rebuild/packaging without issue. Here is the output from my build, for that particular library. I have the official rust 1.6 package installed. Compiling typed-arena v1.1.0 ~/.cargo/registry/src/ 81:39 warning: lint raw_pointer_derive has been removed: using derive with raw pointers is ok ~/.cargo/registry/src/ #![allow(bad_style, raw_pointer_derive)]

tata commented on 2016-03-03 14:27 (UTC)

There seems going something wrong while compiling 8 Warning(s) 0 Error(s) Time Elapsed 00:00:23.4199100 -> Building Gocode completer... /tmp/yaourt-tmp-tata/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/gocode /tmp/yaourt-tmp-tata/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/godef -> Building Rust completer... /tmp/yaourt-tmp-tata/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/racerd Compiling strsim v0.3.0 Compiling unicode-xid v0.0.3 Compiling traitobject v0.0.3 Compiling unsafe-any v0.4.1 Compiling libc v0.1.12 Compiling typed-arena v1.1.0 /home/tata/.cargo/registry/src/ 82:36 error: use of unstable library feature 'append': new API, waiting for dust to settle /home/tata/.cargo/registry/src/ result.append(&mut vec); ^~~~~~~~~~~~~~~~ note: in expansion of for loop expansion /home/tata/.cargo/registry/src/ 83:10 note: expansion site /home/tata/.cargo/registry/src/ 82:36 help: add #![feature(append)] to the crate attributes to enable error: aborting due to previous error Compiling winapi-build v0.1.1 Build failed, waiting for other jobs to finish... Could not compile `typed-arena`.

eberan commented on 2016-03-01 06:29 (UTC)

SHA1: 16dbdc34 Fixes for python2-future and ycm_support_libs Adding python2-future as dependency Removing build target and packaging of ycm_support_libs, as it was removed upstream. This may have an effect on OmniSharp completions, though the author sees it as negligible.

Tazmain commented on 2016-02-29 20:34 (UTC) (edited on 2016-02-29 20:35 (UTC) by Tazmain)

Keep getting Your C++ compiler supports C++11, compiling in that mode. Using Clang archive: /home/Tazmain/Downloads/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/cpp/../clang_archives/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz Using libclang to provide semantic completion for C/C++/ObjC Using external libclang: /home/Tazmain/Downloads/vim-youcompleteme-git/src/ycmd_build/clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04/lib/ -- Configuring done -- Generating done -- Build files have been written to: /home/Tazmain/Downloads/vim-youcompleteme-git/src/ycmd_build make: *** No rule to make target 'ycm_support_libs'. Stop. ==> ERROR: A failure occurred in build(). Aborting...

Rhinoceros commented on 2016-02-27 01:11 (UTC)

I agree with ammonaur. This package is broken without python2-future. When launching vim, it says "YouCompleteMe unavailable: No module named future", and fails to load. Installing python2-future fixes it for me.

ammonaur commented on 2016-02-25 01:59 (UTC)

This package should depend on python2-future. Without it, YouCompleteMe doesn't work on my machine.

eberan commented on 2016-02-19 08:38 (UTC)

@munikarmanish Upstream project change repository for bottlepy. I recommend cleaning that whole directory and building fresh. (or you could just delete bottle and makepkg again, fetching the newer version.)

munikarmanish commented on 2016-02-19 07:59 (UTC)

-> Updating argparse git repo... Fetching origin ==> ERROR: /home/manish/aur/vim-youcompleteme-git/bottle is not a clone of Aborting...

whynothugo commented on 2016-02-14 06:48 (UTC)

@eberan I've a private CI runner I use with some project on GitLab. I'll try so set up CI with that, and let you know when that works. :)

eberan commented on 2016-02-14 05:52 (UTC)

@hoberrera I appreciate it! It's not that much work tbh, but it would be made easier with a CI server; I don't have the time to constantly run the build on my personal machine for testing. Maybe someday I'll plonk down the change for a linode vps, but until then there may be delays in updates when something breaks (i.e. you guys may have to report it before I realize the issue).

whynothugo commented on 2016-02-12 05:57 (UTC)

Wow, this is probably a real PITA to maintain. And manually installing YCM is a pain too. A huge thanks for maintain this package and making life easier for us!

eberan commented on 2016-02-09 22:08 (UTC)

Godef has been added.

eberan commented on 2016-02-09 18:10 (UTC)

I am considering forking this package into at least 2 others, keeping this as is; one for dynamic/managed language (js/ts, python, go, c#) and one for native/system language (c-family, rust). I personally don't mind having the dependencies on things like mono and npm, but I understand it's a burden on some. Comments and suggestions welcome.

eberan commented on 2016-02-09 18:04 (UTC)

tern -> tern_runtime fixed. Updated .SRCINFO as well.

moby commented on 2016-02-07 13:56 (UTC)

For PGP issues related to clang-llvm, as per @eberan @atweiden "Check for the PGP sig (Hans Wennborg <> 0x0FC3042E345AD05D). After verifying the correct key fingerprint, you can do something like this: gpg --recv-keys 0fc3042e345ad05d "

tmplt commented on 2016-02-06 23:21 (UTC) (edited on 2016-02-06 23:58 (UTC) by tmplt)

Currently broken. "tern" must be replaced with "tern_runtime" on line 146 and 172.

johntyree commented on 2016-02-01 00:59 (UTC)

I have the same PGP issue. You can probably work around it by installing the official clang and commenting out that conditional in the PKGBUILD script.

zbb commented on 2016-01-29 14:22 (UTC)

The installation is failing for me because the clang+llvm sources do not have a valid PGP signatures. Has anyone else encountered this issue, or does anyone have any ideas around this problem?

eberan commented on 2016-01-19 00:27 (UTC)

mono is required for csharp support with OmniSharp[Server] rust is required for rust support with Racerd nodejs is required for javascript support with Tern With the exception of mono, which was improperly missing before, these are newly added features in the upstream project. I understand you might not make use of all of these languages, indeed I do not, but for this package all options are enabled. That said, it might be possible to set them as optional depends for runtime use; I haven't tested how Ycmd would react in such a scenario. Also, this might leave people without the functionality they thought they were getting (in the case that make-depends don't cover the runtime ones).

zsrkmyn commented on 2016-01-18 03:51 (UTC) (edited on 2016-01-18 03:55 (UTC) by zsrkmyn)

Why `mono`, `rust` and `nodejs` are dependencies of this package? I think making these three packages YCM's dependencies is not necessary. They can be makedepends, which are necessary building the package, and optdepends, which are optional for users to install. For me, I don't need `rust`, `nodejs` and `mono` at all.

eberan commented on 2016-01-12 10:22 (UTC)

@yan12125 Sorry for the delay, this should be fixed now. @Tazmain Yes, racerd, as well as tern, have been enabled by default. Note, to get full stdlib analysis requires some extra steps; see racerd for more details (regarding rustc source path). @atweiden Thanks for the update; I've made the files more similar, should be easier to keep in sync now.

atweiden commented on 2016-01-12 07:22 (UTC)

I have an updated version of a similar YCM pkgbuild here, but it's meant to work in concert with vim-plug:

Tazmain commented on 2016-01-11 17:59 (UTC)

I am also getting the jedi issue. Will rust support be added for this package, it is available --racer-competer in the

yan12125 commented on 2016-01-11 14:00 (UTC)

Since [1] JediHTTP is used instead of jedi. As a result the following error occurs: ==> Starting package()... cp: cannot stat '/build/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/jedi': No such file or directory [1]

danbruegge commented on 2016-01-03 18:29 (UTC)

@eberan thanks for the info. Sad to hear that it is not so easy to have one package with different dependencies. For now, i'm fine with `neovim-symlinks`, Thanks. :)

eberan commented on 2015-12-27 21:24 (UTC)

@Fuelen Take a look at the comments below. This error is raised because you have not added a key to your keychain (as a trusted source). See artafinde commented on 2015-12-04 09:08

Fuelen commented on 2015-12-26 15:22 (UTC)

error clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz ... unknown public key 0FC3042E345AD05D

eberan commented on 2015-12-11 20:15 (UTC)

@danbruegge Sorry, that's "neovim-symlinks"..not "vim-symlinks" :-]

eberan commented on 2015-12-11 20:12 (UTC)

@danbruegge I don't see a way to have optional dependencies (PKGBUILD/script doesn't have that ability unless I am missing something). What you could do is install the vim-symlinks package, which provides 'vim' and should therefore satisfy this packages dependencies. Another option is (for me?) to clone this package and make one specific for Neovim. I'm ok with either, but the former would require no overhead of maintaining/merging the packages whenever they need updating. @artafinde I purposely didn't post the instructions for importing the key as I wanted people to research and understand what they were doing. But yeah...that'll work.

danbruegge commented on 2015-12-10 11:32 (UTC)

Is it possible to make the package depends on vim OR on neovim. Because i want to remove vim completely from my system. But this package depends on it.

commented on 2015-12-05 11:15 (UTC)

@artafinde +1

artafinde commented on 2015-12-04 09:08 (UTC)

On a 64x system I got Verifying source file signatures with gpg... clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz ... FAILED (unknown public key 0FC3042E345AD05D) Solved it if I installed the gpg key from ubuntu servers: $ gpg --keyserver --recv-keys 0FC3042E345AD05D

eberan commented on 2015-11-24 22:51 (UTC)

@yan12125 Mmm, so my understanding is that checking the hash of the signature is redundant because only the keys whos fingerprint is in 'validpgpkeys' can verify/validate the signature. That makes sense. I'll make the change locally and push it up when the next large(r) change requires an update. Thanks for pointing that out.

yan12125 commented on 2015-11-24 09:42 (UTC)

Oh forgot to mention one thing: in PKGBUILDs I've ever seen (there are some examples in [1]) .sig files are marked as 'SKIP' in md5sums/sha1sums/... Maybe ycm should do that too? Such a change does not affect builds, so maybe changing it at the next update is better to prevent two updates in a short time. [1]

yan12125 commented on 2015-11-23 17:38 (UTC)

Glad to see it's fixed. Just the last step: pkgver in .SRCINFO is not updated.

eberan commented on 2015-11-23 01:41 (UTC)

Fixed; 'requests' submodule was removed upstream because it was (already) in the 'ycmd' submodule.

eberan commented on 2015-11-19 01:40 (UTC)

@zsrkmyn it looks like that submodule has been removed, so the PKGBUILD needs updating. Unfortunately I am unable to change/test/upload a new script because of travel, anyone willing to do the changes feel free to post them here. Moving forward, I'm happy to add maintainers to this project to avoid delayed fixes like this, just let me know.

zsrkmyn commented on 2015-11-18 09:52 (UTC)

Sorry but it seems that I cannot build the package with this PKGBUILD. There may be something wrong there. ==> Starting package()... cp: cannot stat '/build/vim-youcompleteme-git/src/YouCompleteMe/third_party/requests': No such file or directory

eberan commented on 2015-11-09 02:01 (UTC)

Quick update to fix a typo in the packaging step; it missed pulling in clang_includes and libclang.

eberan commented on 2015-11-08 06:03 (UTC)

PKGBUILD has been updated. As the upstream maintainer signature has been added to the source list for verification, you will need to add his key. As @atweiden said: "Check for the PGP sig (Hans Wennborg <> 0x0FC3042E345AD05D)." After verifying the correct key fingerprint, you can do something like this: gpg --recv-keys 0fc3042e345ad05d Also updated is the OmniSharp server, now being built as Release rather than Debug. Chime in if you have any issues!

atweiden commented on 2015-10-15 00:04 (UTC)

Yep. My vim packages are custom installed to the user's $HOME, so you should only use the parts that work. For starters:

eberan commented on 2015-10-14 01:43 (UTC)

@atweiden that looks pretty interesting! I think much of that code can be copied over, however I'm a little unsure about the packaging script. Am I right in understanding this is a user-specific package/installer (I guess that's how plugged works...)?

atweiden commented on 2015-10-12 01:33 (UTC)

To override YCM's own clang binary download on x86_64 with Pacman checking the sha256sums and PGP sigs, reverting to system libclang on non-x86_64 architectures, see: Clang download vars were taken from: Check for the PGP sig (Hans Wennborg <> 0x0FC3042E345AD05D).

eberan commented on 2015-10-07 18:39 (UTC)

@nivata Great! Thanks for the patch. I wonder if we should also include as that is what is linked into the clang completer. We might get some more traction when asking for support upstream as well.

nivata commented on 2015-10-04 21:42 (UTC)

Well, so it seems that using the bundled version of clang works. For the record here is the modified PKGBUILD I used: Too bad it doesn't seem to work with the system clang library though. Maybe you can update the PKGBUILD to reflect this? This has been discussed before (bundled version of vs using the system one), but since apparently using the system version doesn't work currently, this PKGBUILD should use the other option.

nivata commented on 2015-09-30 20:52 (UTC)

@eberan: Yes, I saw your message, but I wasn't sure it still applied, because it was posted a few month ago. So I'm not sure what I should do here. Change the PKGBUILD to use a bundled version of clang? Or change my to include the directory you are talking about? If the latter, can you provide a configuration example?

eberan commented on 2015-09-30 18:22 (UTC)

@nivata I've had issues with c/c++ as well. I think it's because using system clang vs the 'official' clang release. See my post from 2015-5-21: I just noticed c/c++ has some issues with the current packaging scheme; it would seem that the 'clang_includes' directory needs to be included as it is set with '-isystem' (check YcmDebugInfo). Without that directory in the package clang shows errors for things it shouldn't ('unknown type size_t' in my case). This doesn't seem to be fixable by pointing to the systems clang_include with -isystem (despite the content being identical).

nivata commented on 2015-09-30 18:16 (UTC)

Hi, I'm having some trouble configuring YouCompleteMe correctly using C++ and CMake. I opened a topic on the forum and I was curious if anyone using this package had similar issues:

swiftscythe commented on 2015-09-24 07:45 (UTC)

You can just comment out the lines you don't need. This is the modified version I use:

adam900710 commented on 2015-09-24 05:51 (UTC)

Hi, Any idea to custom the supported languages? I only need Jedi and C/C++ support, mono and go is quite huge packages and are totally unused in my case. I was using vim-clang-completion originally, but it has bugs with latest vim and will cause display go crazy. How can I disable them? Thanks

eberan commented on 2015-09-09 05:25 (UTC)

@ekkelett & @Autokill677; Fixed, apologies for the delay. Thank you for the patch!

ekkelett commented on 2015-09-02 11:51 (UTC)

To follow on what @Autokill677 said: diff --git a/PKGBUILD b/PKGBUILD index 8191465..74f9b05 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -1,4 +1,5 @@ # Maintainer: Erik Beran <eberan AT_gmail_DOT com> +# Contributor: Thor K. H. <thor at roht dot no> # Contributor: Babken Vardanyan <483ken 4tgma1l # Contributor: mikezackles # Contributor: z33ky @@ -12,7 +13,7 @@ # Contributor: archdria pkgname=vim-youcompleteme-git -pkgver=1393.4436d51 +pkgver=1517.a2808ee pkgver() { cd "YouCompleteMe" echo $(git rev-list --count master).$(git rev-parse --short master) @@ -97,7 +98,7 @@ package() { "$pkgdir/usr/share/vim/vimfiles" cp -r "$srcdir/YouCompleteMe/third_party/"{pythonfutures,requests,requests-futures,retries} \ "$pkgdir/usr/share/vim/vimfiles/third_party" - cp -r "$srcdir/YouCompleteMe/third_party/ycmd/"{ycmd,,,,EXPECTED_CORE_VERSION} \ + cp -r "$srcdir/YouCompleteMe/third_party/ycmd/"{ycmd,,,,CORE_VERSION} \ "$pkgdir/usr/share/vim/vimfiles/third_party/ycmd" cp -r "$srcdir/YouCompleteMe/third_party/ycmd/third_party/"{argparse,bottle,frozendict,jedi,waitress} \ "$pkgdir/usr/share/vim/vimfiles/third_party/ycmd/third_party"

Autokiller677 commented on 2015-08-20 14:46 (UTC)

Install fails with: cp: „/tmp/yaourt-tmp-<user>/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/EXPECTED_CORE_VERSION“ is not possible. File or directory not found. Solution: EXPECTED_CORE_VERSION is now CORE_VERSION. Just replace in PKGBUILD and it works.

eberan commented on 2015-07-29 19:19 (UTC)

@archdria The change has been committed, thanks! @thaigowfix Thanks for the patch, I'll try to run through it soon.

swiftscythe commented on 2015-07-03 08:52 (UTC)

Files "" and "EXPECTED_CORE_VERSION" need to be installed as well: cp -r "$srcdir/YouCompleteMe/third_party/ycmd/"{ycmd,,,,EXPECTED_CORE_VERSION} \ "$pkgdir/usr/share/vim/vimfiles/third_party/ycmd"

thiagowfx commented on 2015-06-07 21:02 (UTC)

I tried to refactor the PKGBUILD a little bit. Do you consider this relevant? Here: Purpose: just to be slightly less repetitive, thus, less error-prone. Warning: not tested, though.

eberan commented on 2015-05-21 16:49 (UTC)

I just noticed c/c++ has some issues with the current packaging scheme; it would seem that the 'clang_includes' directory needs to be included as it is set with '-isystem' (check YcmDebugInfo). Without that directory in the package clang shows errors for things it shouldn't ('unknown type size_t' in my case). This doesn't seem to be fixable by pointing to the systems clang_include with -isystem (despite the content being identical). This directory will be included in the package and reported upstream, though I don't expect any change/fix as Valoric wants to deprecate/hide the USE_SYSTEM_CLANG option.

eberan commented on 2015-05-06 17:17 (UTC)

PKGBUILD update: gocode added, thanks foobster (adds new make requirement 'go') gocode and now OmniSharp only copy executables/binaries during packaging, so that should cut away a few MB from the package and install size. Future changes: Build 'Release' configuration of OmniSharp; requires upstream change to YouCompleteMe as it only attempts to load OmniSharp from 'bin/Debug' path. Look into precompiling python to .pyc

eberan commented on 2015-05-06 14:53 (UTC)

Nevermind, it looks like a known issue when OmniSharp is either unable to load or unable to find the program solution/project file. I will upload the updated PKGBUILD later today.

eberan commented on 2015-05-06 01:11 (UTC)

I'm just about to update the PKGBUILD with gocode and slightly better packaging but; Is anyone else not able to get C#/OmniSharp working properly? I keep getting network connection errors in the log when I try to get some autocompletion.

foobster commented on 2015-05-01 01:44 (UTC)

@eberan - Oops, sorry about that. I also had vim-go installed and adding the directory was enough to make the work in conjunction with YCM. I added a build statement cd "$srcdir/YouCompleteMe/third_party/ycmd/third_party/gocode" go build pwd but it still doesn't seem to work without vim-go also installed. Gocode itself does not have a go dependency but vim-go does. I'm not sure why it doesn't seem to be working without vim-go, the above build command is the same as what's in third_party/ycmd/

eberan commented on 2015-04-30 22:28 (UTC)

@foobster thanks for the patch. Looks like it was missing the build step and is probably packaging more files than necessary (though that is a systemic problem right now). Do you know if gocode just needs the go dependency for building, or for execution as well? (it looks like it is just for building the gocode executable, which doesn't have any dependencies beyond libc/pthread)

foobster commented on 2015-04-30 12:57 (UTC)

Thanks for maintaining this useful package. Could you possibly add golang support? A modified PKGBUILD that does this can be found here (

eberan commented on 2015-04-22 02:31 (UTC)

@marsoft Yeah it looks like your environment is a little screwy, with libclang being selected from your Android SDK path. I suppose this wouldn't happen if we went with the non-system clang library. I'd say the slightly more proper way of building in your case is to set LIBRARY_PATH (and maybe PATH?) to /usr/lib, as that is where your system libs live. #LIBRARY_PATH=/usr/lib makepkg That said, I would recommend you clean your $path up a little, as it could make other programs

marsoft commented on 2015-04-21 19:52 (UTC)

Had an issue, when after building I got error message like this: [ 85%] Built target ycm_client_support Linking CXX shared library /tmp/packerbuild-1000/vim-youcompleteme-git/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/ /opt/android-sdk/build-tools/19.0.3/ error adding symbols: Incorrect file format What helped was to export PATH=/usr/bin and clean rebuild: $ export PATH=/usr/bin $ makepkg -C The strange thing is that android SDK paths were in PATH but *after* /usr/bin, so in theory it should not influence anything... My PATH is: /home/mars/bin:/home/mars/GNUstep/Tools:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/android-sdk/build-tools/19.0.3/:/opt/android-sdk/platform-tools:/opt/android-sdk/tools:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/mars/.gem/ruby/2.1.0/bin:/opt/arm-cs-tools/bin Anyway, hope this will help.

eberan commented on 2015-04-14 22:02 (UTC)

@SevenHong Don't build packages as root. Take a look at the makepkg wiki entry; "makepkg does not support building as root as of v4.2."

commented on 2015-04-13 03:00 (UTC)

I was using packer and I got this error: makepkg: invalid option '--asroot' The build failed. Any help?

eberan commented on 2015-03-26 18:47 (UTC)

@yan12125 Well it sounds like rpath isn't being used (when using system lib) and wont be fixed or at least there is no plan to. Considering we've been using the system lib forever anyway, with no reported ill effects outside of needing a rebuild, we can explicitly not package it without changing behavior.

yan12125 commented on 2015-03-25 18:08 (UTC)

Valloric responded again. Any further ideas? By the way, I prefer the latter solution by @eberan, too.

swiftscythe commented on 2015-03-23 17:52 (UTC)

@eberan, I am more inclined to the latter. I've been using YCM for more than a year and the developer has always updated the plugin for API/ABI changes in libclang almost as soon as they are released, which is before it even hits the arch repos.

eberan commented on 2015-03-23 17:47 (UTC)

@yan12125 Valloric responded: "...@rpath and other wonkiness is there to ensure that that libclang is loaded." Interesting, I never used rpath before! Thanks for posting to github though, that helps in deciding what to do with packaging; Essentially we need to pull in the libclang dependencies as well. Alternatively we could just use system libraries and hope the ABI etc don't break on system upgrades. The former bloats the plugin just a little, the latter breaks if the system library is incompatible with the API/ABI of *and* might not be fixable until upstream updates their code to the latest clang/llvm (i.e. just rebuilding the plugin may not help). Opinions are welcome, but I'm leaning towards the former; include dependencies in the package.

yan12125 commented on 2015-03-23 08:39 (UTC)

Sorry it seems an upstream issue. I've reported it at

eberan commented on 2015-03-23 06:31 (UTC)

@yan12125 Indeed, I had totally forgotten about link paths (LD_LIBRARY_PATH/PYTHONPATH). It doesn't seem like this package has anything that would set that by default, unless vim/python sets up the environment for plugins/modules.

yan12125 commented on 2015-03-22 10:44 (UTC)

I've noticed that on my system ycmd shared objects depends on /usr/lib/ instead of /usr/share/vim/vimfiles/third_party/ycmd/ Does that mean there's no need to install in package()? I've removed /usr/share/vim/vimfiles/third_party/ycmd/ via 'sudo rm' and ycm seems working fine as before. Here are the results from ldd calls: $ ldd /usr/share/vim/vimfiles/third_party/ycmd/ (0x00007ffff7d98000) => /usr/lib/ (0x00007f9e9caf9000) => /usr/lib/ (0x00007f9e9bbc4000) => /usr/lib/ (0x00007f9e9b8b5000) => /usr/lib/ (0x00007f9e9b5af000) => /usr/lib/ (0x00007f9e9b399000) => /usr/lib/ (0x00007f9e9aff6000) => /usr/lib/ (0x00007f9e9add8000) => /usr/lib/ (0x00007f9e9abd4000) => /usr/lib/ (0x00007f9e9a9d1000) => /usr/lib/ (0x00007f9e9878b000) /usr/lib64/ (0x00007f9e9d28b000) => /usr/lib/ (0x00007f9e98575000) => /usr/lib/ (0x00007f9e9836b000) => /usr/lib/ (0x00007f9e9812f000) => /usr/lib/ (0x00007f9e97eca000) $ ldd /usr/share/vim/vimfiles/third_party/ycmd/ (0x00007ffc54fbf000) => /usr/lib/ (0x00007fa710882000) => /usr/lib/ (0x00007fa710573000) => /usr/lib/ (0x00007fa71026e000) => /usr/lib/ (0x00007fa710057000) => /usr/lib/ (0x00007fa70fcb4000) => /usr/lib/ (0x00007fa70fa97000) => /usr/lib/ (0x00007fa70f892000) => /usr/lib/ (0x00007fa70f68f000) /usr/lib64/ (0x00007fa710f33000)

eberan commented on 2015-03-17 17:20 (UTC)

@shmilee From the looks of it, which we copy from the system during packaging, has a dependency on I believe LLVM was recently updated from 3.5 to 3.6, thereby removing the required dependency for the ycmd If you clean/rebuild this project, it should update the and remove your dependency on llvm35-libs. This boils down to the need to update the packaging script, whether that means including the system together with clang, to avoid similar system update breakage. Or remove from the package, relying solely on current system lib (and hope it remains compatible with ycmd).

shmilee commented on 2015-03-17 15:25 (UTC)

An ERROR: RuntimeError: Error importing ycm_core. Are you sure you have placed a version 3.2+ libclang.[so|dll|dylib] in folder "/usr/share/vim/vimfiles/third_party/ycmd"? See the Installation Guide in the docs. Full error: cannot open shared object file: No such file or directory Then I installed llvm35-libs to fix that. What about clang35 ?

eberan commented on 2015-02-12 19:14 (UTC)

@archdria Thanks for posting. @wsha The ycm_support_libs build target does not include OmniSharp. Take a look at the ycmd/ Main(), the build configuration is in two parts.

wsha commented on 2015-02-12 13:08 (UTC)

Could someone explain why the three lines below are necessary? cd "$srcdir/YouCompleteMe/third_party/ycmd/third_party/OmniSharpServer" pwd xbuild Doesn't the "make ycm_support_libs" command execute these lines already?

swiftscythe commented on 2015-02-12 08:38 (UTC)

I've been using this package with this modification on line 91: cp -r "$srcdir/YouCompleteMe/third_party/ycmd/"{ycmd,,} \ The other files are not necessary. Thank you :)

eberan commented on 2015-02-05 19:44 (UTC)

Thanks @shmilee, PKGBUILD has been updated.

shmilee commented on 2015-02-05 14:11 (UTC)

eberan commented on 2015-01-22 08:13 (UTC)

@swiftscythe Yes there are definitely files that can be ignored when packaging, though it also means more maintenance of the package script. It probably wouldn't be a problem. Regarding libclang; this happens to be how ycmd builds though I'm not sure exactly why. I want to ask the devs to see what their reasoning is before removing it from the package. That said, that *is* your system lib, just copied locally during the build process, so it's probably ok remove with the exception that any ABI changes when updating the system's clang would require a rebuild of ycmd. Anyway, I'll look into cleaning up the package script when I have time, patches welcome (use gist, pastebin, or similar please).

swiftscythe commented on 2015-01-21 11:46 (UTC)

I think you don't need to copy, since the package uses the system one. I've removed it from the PKGBUILD and the plugin still continues to work OK. I also think the other stuff copied, like {,,,,}, is not needed, as the plugin works without them.

eberan commented on 2015-01-21 02:09 (UTC)

@yan12125 Done.

yan12125 commented on 2015-01-20 07:22 (UTC)

Could you use git+https protocol instead of git+git in sources? Git protocol seems blocked by the firewall from my place.

eberan commented on 2015-01-20 03:35 (UTC)

@johntyree Thanks for the notice, as it made me look more at the packaging script; It could use a good cleaning for sure, as there are a bunch of build files and scripts in the resulting package. I'll at least have a fix for this issue up pretty soon.

johntyree commented on 2015-01-19 22:47 (UTC)

==> Entering fakeroot environment... ==> Starting package()... cp: cannot stat ‘/var/cache/pacman/pkg/vim-youcompleteme-git8299/vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/’: No such file or directory ==> ERROR: A failure occurred in package(). Aborting...

axper commented on 2014-10-19 14:51 (UTC)

@wil93 mono is needed for omnisharp/C# completion. Just remove it from depends.

wil93 commented on 2014-10-19 14:48 (UTC)

Why is mono a dependency? How do I install this plugin without mono?

eberan commented on 2014-10-05 18:54 (UTC)

All pull requests have been merged, so I'm switching back to the upstream repositories (Valloric on github).

doragasu commented on 2014-10-03 07:16 (UTC)

It builds now, THANKS!

mexus commented on 2014-10-02 19:18 (UTC)

Thank you very much, it's very nice of you as a package maintainer!

eberan commented on 2014-10-02 19:09 (UTC)

I've temporarily updated the PKGBUILD to point to the forked repo's for YouCompleteMe and ycmd. When they accept the pull request and update their repo's I'll switch back. This should get you going for the time being.

eberan commented on 2014-10-02 17:46 (UTC)

Sorry for the delay. It turns out there was a regression in the OmniSharpServer, so just updating to latest broke the test/QA. They merged my fix so now I'm just waiting on ycmd to test and merge the updated OmniSharpServer submodule. (

mexus commented on 2014-10-02 16:15 (UTC)

eberan, could you please post a link to your repo/commit? It looks like Valloric hadn't fixed it yet =(

eberan commented on 2014-09-30 19:39 (UTC)

Ok, it looks like there was an issue with OmniSharp + Mono 3.8. It has been fixed upstream, but the Valloric/ycmd repo has not updated the submodule commit id to or beyond the fix(es). I can verify that building with HEAD OmniSharp(Server) repo works fine. I'll put in a merge request for Valloric.

eberan commented on 2014-09-30 18:53 (UTC)

I get the same error when building. I'll look into it.

doragasu commented on 2014-09-30 15:46 (UTC)

I have the same problem, trying to build on an x64 arch install I get exactly the same 4 errors :(

MasterMax commented on 2014-09-29 08:17 (UTC)

I have installed it, but I am getting this error recently: "The ycmd server SHUT DOWN (restart with :YcmRestartServer). Stderr (last 30 lines)" Rebuilding it fixed this error on my pc (about a week ago), but I cant't rebuild it on my laptop (same system basically). I think those are the compile errors, which might help you: Errors: /tmp/yaourt-tmp-max/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/OmniSharpServer/OmniSharp.sln (default targets) -> (Build target) -> /tmp/yaourt-tmp-max/aur-vim-youcompleteme-git/src/YouCompleteMe/third_party/ycmd/third_party/OmniSharpServer/OmniSharp/OmniSharp.csproj (default targets) -> /usr/lib/mono/4.5/Microsoft.CSharp.targets (CoreCompile target) -> Bootstrapper.cs(41,37): error CS0121: The call is ambiguous between the following methods or properties: `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task<Nancy.Response>>,System.Func<Nancy.NancyContext,Nancy.Response>>.AddItemToStartOfPipeline(System.Func<Nancy.NancyContext,Nancy.Response>)' and `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task<Nancy.Response>>,System.Func<Nancy.NancyContext,Nancy.Response>>.AddItemToStartOfPipeline(Nancy.PipelineItem<System.Func<Nancy.NancyContext,Nancy.Response>>, bool)' Bootstrapper.cs(42,36): error CS0121: The call is ambiguous between the following methods or properties: `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task>,System.Action<Nancy.NancyContext>>.AddItemToEndOfPipeline(System.Action<Nancy.NancyContext>)' and `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task>,System.Action<Nancy.NancyContext>>.AddItemToEndOfPipeline(Nancy.PipelineItem<System.Action<Nancy.NancyContext>>, bool)' Bootstrapper.cs(46,41): error CS0121: The call is ambiguous between the following methods or properties: `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task<Nancy.Response>>,System.Func<Nancy.NancyContext,Nancy.Response>>.AddItemToStartOfPipeline(System.Func<Nancy.NancyContext,Nancy.Response>)' and `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task<Nancy.Response>>,System.Func<Nancy.NancyContext,Nancy.Response>>.AddItemToStartOfPipeline(Nancy.PipelineItem<System.Func<Nancy.NancyContext,Nancy.Response>>, bool)' Bootstrapper.cs(47,40): error CS0121: The call is ambiguous between the following methods or properties: `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task>,System.Action<Nancy.NancyContext>>.AddItemToStartOfPipeline(System.Action<Nancy.NancyContext>)' and `Nancy.AsyncNamedPipelineBase<System.Func<Nancy.NancyContext,System.Threading.CancellationToken,System.Threading.Tasks.Task>,System.Action<Nancy.NancyContext>>.AddItemToStartOfPipeline(Nancy.PipelineItem<System.Action<Nancy.NancyContext>>, bool)'

commented on 2014-09-11 06:28 (UTC)

@eberan, Yes I have the same error, I have not rebuilt ycm again. At office, so cannot rebuild it now, but soon I will rebuild it and report back. Thanks.

eberan commented on 2014-09-10 23:48 (UTC)

After running pacman -Syu I got some (localhost) network connection issue with vim/youcompleteme, but no crash. After rebuilding this package, I no longer had any issue and still no crashes. Can you confirm that you've rebuilt/installed this package?

commented on 2014-09-10 18:21 (UTC)

The latest clang update seems to have broken ycm. The ycm server crashes everytime vim starts

axper commented on 2014-08-19 15:47 (UTC)

Yep, C# works fine - good job! BTW for anyone wondering - see the wiki on how to set up a C# project.

eberan commented on 2014-08-18 20:49 (UTC)

I fixed the existing PKGBUILD, without removing the Mono/C# features:

axper commented on 2014-08-18 16:03 (UTC)

@CIB just comment/delete the all lines which have "OmniSharpServer" in them. Except for: mkdir -p "$pkgdir/usr/share/vim/vimfiles/third_party/ycmd/third_party/OmniSharpServer/OmniSharp" change it to: mkdir -p "$pkgdir/usr/share/vim/vimfiles/third_party/ycmd/third_party" Haven't tested myself, but should work

CIB commented on 2014-08-18 14:36 (UTC)

@eberan: Yep, I'm getting issues with OmniSharpServer as well. Since I don't personally need it, an option to just disable it would be nice.

eberan commented on 2014-08-18 07:02 (UTC)

Has anyone else had issues with OmniSharpServer not populating properly? It seems it has submodules of its own which perhaps are not being init/updated?

axper commented on 2014-07-07 16:02 (UTC)

Alright. Just do what you think is right.

vodik commented on 2014-07-07 05:58 (UTC)

Old maintainer here, sorry for the absense, I was preoccupied with my transition from school to work. @axper There isn't a need for dozens of extra packages like 'vim-youcompleteme-clang-jedi-git' and co. Just make a split package with ycm-core and ycm-<completer>. I'll clean up and share what I'm using now if you want.

axper commented on 2014-06-13 07:07 (UTC)

@mikezackles Done, thanks!

mikezackles commented on 2014-06-12 22:23 (UTC)

So (I think) the CMake find_library stuff for ycmd_core somehow ends up searching PATH to find before it looks in more appropriate places. This is a problem for people who have android-sdk installed from AUR, which adds the build_tools directory to PATH, which also contains This seems like an upstream issue, but for now an easy workaround is to just specify the path to explicitly as done in the updated PKGBUILD here: Apologies if I'm somehow mistaken, and thanks for maintaining!

axper commented on 2014-05-21 14:35 (UTC)

@z33ky I think the best approach would be to split into several packages rather than variablies. This one (vim-youcompleteme-git) will have all the completion engines. You can create new packages like vim-youcompleteme-clang-jedi-git which will have only clang and jedi, etc.

z33ky commented on 2014-05-21 10:38 (UTC) This includes the clang completer and the OmniSharp completer with the YCM package, but they are optional and you can toggle them with the first two variables in the PKGBUILD. It also cuts some of the sources in favor of simple dependencies - python-frozendict is an exception, because no such package exists yet, so it is also included in the YCM package. I tested the omni (not OmniSharp) completer, the clang completer and the jedi completer (now also an optional dependency). Also the LTO build (with gcc 4.9) is corrupt, so build without LTO. I also didn't increase the pkgrel yet, so if you upload this PKGBUILD as-is you should probably do that.

z33ky commented on 2014-05-19 20:04 (UTC)

I'll try in the next few days and see what I can accomplish. I could take over the maintenance of this package, but I only use the non-semantic and clang completion engines. Perhaps this package should be split into entirely different packages for the completion engines, if it is possible to build, install and maintain them separately. If I succeed I shall test with YCM and the clang-completion engine, perhaps someone will step up and test with jedi and OmniSharp.

axper commented on 2014-05-19 13:48 (UTC)

@z33ky Write a pkgbuild with your proposals and I'll merge it. Alternatively I can disown the package and you can do it yourself.

z33ky commented on 2014-05-18 21:49 (UTC)

I think there are still some unnecessary files in this version of the package. I've put up a list of files in my previous package, before the split into YouComleteMe & ycmd, up here for reference: Some things I am spotting: test directories - I presume these are not actually useful at run-time - aren't we explicitly linking against system clang? (And semantic completion indeed still works on my system when I remove /usr/share/vim/vimfiles/third_party/ycmd/ Partially these are also just new dependencies, such as waitress (I believe). There are also some dependencies, such as jedi, that could be optdepends instead. Perhaps it's more prone to breakage if the YCM submodules get out of sync with the system packages. A split-package with vim-youcompleteme-$COMPLETIONENGINE-git might work. Otherwise, having a few variables at the top of the PKGBUILD to easily toggle their installation would be pleasant. You might not even need to checkout the submodules that you don't want to install if they're not actually part of the YCM build but are just checked out for installing/packaging.

axper commented on 2014-05-18 20:50 (UTC)

@z33ky Thanks for report. I removed the cpp directory and bunch of files/dirs from OmniSharp. The .pkg.tar.xz file now on my system is 6.8M.

z33ky commented on 2014-05-18 13:49 (UTC)

I'm pretty sure the package() function copies too many files. For one, the whole source code of ycmd gets packaged, but even after taking out these ~28MB the package gets ~19MB larger than before.

axper commented on 2014-05-17 20:29 (UTC)

Updated, thank you all!

stykr commented on 2014-05-17 19:59 (UTC)

git config submodule.requests.url "$srcdir/requests" Should be: git config submodule.third_party/requests.url "$srcdir/requests" By the way, the version of OmniSharpServer YouCompleteMe uses does not require cecil or NRefactory. See:

axper commented on 2014-05-17 19:56 (UTC)

This should be what you are asking for: But still, it re-downloads the whole 11 repos.

stykr commented on 2014-05-17 19:55 (UTC)

Try something like this:

stykr commented on 2014-05-17 19:40 (UTC)

@axper: I'm referring to: cd "$srcdir/YouCompleteMe" git submodule init git config submodule.requests.url "$srcdir/requests" git config submodule.requests-futures.url "$srcdir/requests-futures" git config submodule.ycmd.url "$srcdir/ycmd" git config submodule.argparse.url "$srcdir/argparse" git config submodule.bottle.url "$srcdir/bottle" git config submodule.frozendict.url "$srcdir/python-frozendict" git config submodule.jedi.url "$srcdir/jedi" git config submodule.waitress.url "$srcdir/waitress" git config submodule.OmniSharpServer.url "$srcdir/OmniSharpServer" git submodule update Since the submodules argparse and down in that list are contained within the ycmd submodule, the initial git submodule init will not initialize these submodules.

axper commented on 2014-05-17 19:33 (UTC)

@stykr I commented OmniSharpServer's submodules temporarily only for demonstration

stykr commented on 2014-05-17 19:29 (UTC)

git submodule init does not initialize the submodules recursively. You have to do it manually.

axper commented on 2014-05-17 19:28 (UTC)

@Svenstaro That's still cloning the whole repo, am I doing something wrong?

Svenstaro commented on 2014-05-17 19:07 (UTC)

I put a proper git with submodules tutorial into the wiki: That should clean some things up.

axper commented on 2014-05-17 11:53 (UTC)

@KaiSforza Good idea, thanks, updated

KaiSforza commented on 2014-05-17 11:08 (UTC)

@axper: something you could do is just 'ln -s' instead of 'cp -R' for the submodules. Save time and disk IO.

axper commented on 2014-05-17 11:01 (UTC)

@stykr In that case, everyone would have to fetch all the 10+ repos every time when building the package. Currently it will simply git pull/update the repos and won't waste your bandwidth and overload github servers.

stykr commented on 2014-05-17 10:55 (UTC)

There's a lot of unnecessary copying in the PKGBUILD. Call git submodule update --init --recursive instead, and remove the other github repositories from the sources list.

axper commented on 2014-05-17 10:19 (UTC)

@ilpianista I installed android-sdk while built with -DUSE_SYSTEM_LIBCLANG=ON and cannot report any problems

axper commented on 2014-05-17 10:04 (UTC)

Updated, added C# support.

axper commented on 2014-05-17 05:47 (UTC)

This works for me for C++ Can someone please test if it works for other languages as well before I push it here?

Svenstaro commented on 2014-04-08 22:18 (UTC)

Orphaning and fixing since maintainer hasn't reacted for 3 weeks. Maintainer, feel free to take it again if you like, or anybody else for that matter.

Svenstaro commented on 2014-03-28 06:17 (UTC)

Why did you remove the external clang stuff again? You had it in and you removed it again. What's up?

ilpianista commented on 2014-03-22 08:31 (UTC)

There is currently a problem if you have multiple in your system in standard paths. This is the case, for instance, if you have android-sdk installed. Please use this: cmake -DEXTERNAL_LIBCLANG_PATH=/usr/lib/

bparker commented on 2014-02-28 17:56 (UTC)

I don't think it is a good idea to have a dependency on a GUI package since not everyone is using vim on a desktop with GUI. I think a better solution is to switch the dependency to vim-python2 or ask the regular vim package maintainer to include python support.

axper commented on 2014-02-13 11:52 (UTC)

Can you please add C# support?

vodik commented on 2014-01-31 20:11 (UTC)

Sorry guys, had an insane month of work. Time to catch up @Hspasta: It doesn't. While jedi supports both python2 and python3, it can only complete for the version of python its run as. And youcompleteme is python2. It also may be possible to make jedi complete different versions of python in the future as well. See various issues opened upstream. @swiftscythe: find ${pkgdir} -name .git -exec rm -fr {} + I'll add it.

swiftscythe commented on 2014-01-28 08:39 (UTC)

What about adding these lines at the end of the package() function? They prevent the .git directories from being installed, and the size of the plugin reduces from 30 MB to less than 8. # clean .git files for DOTGIT in $(find ${pkgdir} -name .git) do rm -r $DOTGIT done

Hspak commented on 2014-01-23 20:24 (UTC)

How does this package get around the python2/python problem? I tried using vundle and replacing python with python2 and it spits errors. I'm looking at all the files and it doesn't seem to be doing anything, but it works...

rpodgorny commented on 2014-01-09 22:37 (UTC)

well, if there is no other way, no problem... ...but at least a gentle warning (in the pkgbuild) would be nice. btw, is there any aur package for such vim (with python support)?

vodik commented on 2014-01-08 20:46 (UTC)

You need gvim or vim compiled with python support. The stock vim package doesn't ship with python. I'm not sure if its best to switch it to depend on gvim since some people do in fact (me included) do make custom vim packages. They would provided/replace vim, not gvim. Or maybe the stock vim package should start compiling in python support.

rpodgorny commented on 2014-01-08 12:10 (UTC)

...same thing as lordaro: YouCompleteMe unavailable: requires Vim compiled with Python 2.x support

Svenstaro commented on 2013-12-26 14:15 (UTC)

Really, you need to remove that.

Svenstaro commented on 2013-12-12 00:29 (UTC)

You need to remove the -DUSE_SYSTEM_LIBCLANG line in order for the fix to work.

vodik commented on 2013-12-10 22:24 (UTC)


Svenstaro commented on 2013-11-22 11:17 (UTC)

There is currently a problem if you have multiple in your system in standard paths. This is the case, for instance, if you have android-sdk installed. Please use this: cmake -DEXTERNAL_LIBCLANG_PATH=/usr/lib/

LordAro commented on 2013-11-19 21:02 (UTC)

Wait, it's because standard 'vim' on arch is indeed without python support Perhaps you could somehow check this in the PKGBUILD ?

LordAro commented on 2013-11-19 01:19 (UTC)

Not sure if this is the package or something else, but upon installation i get: "YouCompleteMe unavailable: requires Vim compiled with Python 2.x support" when starting vim Is there something else I need to do?

vodik commented on 2013-10-31 01:02 (UTC)

Hey so thestinger has turned over this package to me. I rebuild this PKGBUILD almost daily so I should be able to stay ontop of changes quicker. I'm explicitly listing all the git sub-modules in the source array because I rebuild the package on _any_ change. If this breaks I will revert to `git submodule update --init`

ksmets commented on 2013-10-25 13:44 (UTC)

I edited the PKGBUILD to checkout all submodules (see comment by hack.augusto), and to make ycm_client_support (as indicated in when building. Moreover, when packaging also the third_party folder needs to be bundled. diff --git a/PKGBUILD b/PKGBUILD index c0b0a9c..bed6703 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -2,7 +2,7 @@ _gitname=YouCompleteMe pkgname=vim-youcompleteme-git -pkgver=564.7cef111 +pgkver=941.77b8adf pkgrel=1 epoch=1 pkgdesc='A code-completion engine for Vim' @@ -24,14 +24,16 @@ pkgver() { } build() { - cd $_gitname/cpp + cd $_gitname + git submodule update --init --recursive + cd cpp cmake -G "Unix Makefiles" -DUSE_SYSTEM_LIBCLANG=ON - make ycm_core + make ycm_support_libs } package() { cd $_gitname mkdir -p "$pkgdir/usr/share/vim/vimfiles" - cp -a autoload doc plugin python "$pkgdir/usr/share/vim/vimfiles" + cp -a autoload doc plugin python third_party "$pkgdir/usr/share/vim/vimfiles" ln -sf /usr/lib/llvm/ "$pkgdir/usr/share/vim/vimfiles/python/" }

commented on 2013-09-15 11:34 (UTC)

I'm having problems making this package, the script seems to hang at cloning YouCompleteMe from github. [~/Downloads/vim-youcompleteme-git] > makepkg ==> Making package: vim-youcompleteme-git 1:564.7cef111-1 (Sun Sep 15 12:34:09 BST 2013) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... -> Cloning YouCompleteMe git repo... Cloning into bare repository '/home/chutsu/Downloads/vim-youcompleteme-git/YouCompleteMe'... ^C ==> ERROR: Aborted by user! Exiting...

hack.augusto commented on 2013-09-14 23:36 (UTC)

Changing build to checkouts all the submodules: build() { cd $_gitname git submodule update --init --recursive cd cpp cmake -G "Unix Makefiles" -DUSE_SYSTEM_LIBCLANG=ON make ycm_core }

mmlb commented on 2013-08-29 14:19 (UTC)

Uh, sorry ignore the ``` github style markdown stuff.

mmlb commented on 2013-08-29 14:18 (UTC)

I have built upon @KaiSforza's addition to work with all of the submodules, all that is needed is the git:// path be part of the `source` array. ```bash --- PKGBUILD.orig 2013-08-29 10:16:15.020172245 -0400 +++ PKGBUILD 2013-08-29 10:13:48.906837314 -0400 @@ -2,7 +2,7 @@ _gitname=YouCompleteMe pkgname=vim-youcompleteme-git -pkgver=564.7cef111 +pkgver=774.7cc399a pkgrel=1 epoch=1 pkgdesc='A code-completion engine for Vim' @@ -15,14 +15,28 @@ provides=(vim-youcompleteme) conflicts=(vim-youcompleteme) install=vimdoc.install -source=('git://') -md5sums=(SKIP) +source=(git:// +git:// +git:// +md5sums=(SKIP SKIP SKIP) pkgver() { cd $_gitname echo $(git rev-list --count master).$(git rev-parse --short master) } +prepare() { + cd "$srcdir/$_gitname" + for s in ${source[@]:1} + do + repo=${s##*/} + repo=${repo/.git} + echo "s=$s, repo=$repo" + sed -i -e "/${repo}.git/ s|*|$srcdir/$repo|" .gitmodules + done + git submodule update --init +} + build() { cd $_gitname/cpp cmake -G "Unix Makefiles" -DUSE_SYSTEM_LIBCLANG=ON @@ -35,3 +49,5 @@ cp -a autoload doc plugin python "$pkgdir/usr/share/vim/vimfiles" ln -sf /usr/lib/llvm/ "$pkgdir/usr/share/vim/vimfiles/python/" } + +# vim:set ts=2 sw=2 et: ```

KaiSforza commented on 2013-05-15 20:09 (UTC)

Please add in the jedi submodule. Add git:// to the source array, then add this prepare function. (using this relative path will almost guarantee that the user will get a fast local checkout instead of using the $SRCDEST path, as $SRCDEST and $BUILDDIR could be on separate partitions.) prepare() { cd "$srcdir/$_pkgname" sed -i -e "s||../jedi|g" .gitmodules git submodule init git submodule update }

vendion commented on 2013-04-23 15:09 (UTC)

Seems to be missing the python headers needed for building: CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:97 (message): Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS) (Required is at least version "2.5") Call Stack (most recent call first): /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:291 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-2.8/Modules/FindPythonLibs.cmake:186 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) BoostParts/CMakeLists.txt:29 (find_package) Please add this as at least build dependencies to the package

mmlb commented on 2013-04-09 18:12 (UTC)

I edited the PKGBUILD to take advantage of makepkg-4.1's VCS abilities. I also changed the version # to be a bit like `git describe` output when tagged correctly. # Maintainer: Daniel Micay <> _gitname=YouCompleteMe pkgname=vim-youcompleteme-git pkgver=503_g085df7e pkgrel=1 pkgdesc='A code-completion engine for Vim' arch=(i686 x86_64) url='' license=(GPL3) groups=(vim-plugins) depends=(vim clang) makedepends=(git cmake) provides=(vim-youcompleteme) conflicts=(vim-youcompleteme) install=vimdoc.install source=(git:// md5sums=(SKIP) pkgver() { cd YouCompleteMe echo $(git rev-list HEAD | wc -l)_g$(git rev-list --max-count=1 --abbrev-commit HEAD) } build() { cd $srcdir/YouCompleteMe/cpp cmake -G "Unix Makefiles" -DUSE_SYSTEM_LIBCLANG=ON make ycm_core } package() { cd $srcdir/YouCompleteMe mkdir -p "$pkgdir/usr/share/vim/vimfiles" cp -a autoload doc plugin python "$pkgdir/usr/share/vim/vimfiles" ln -sf /usr/lib/llvm/ "$pkgdir/usr/share/vim/vimfiles/python/" } # vim:set ts=2 sw=2 et:

l0gic commented on 2013-03-11 17:09 (UTC)

Plase change the vim dependency to gvim, as the vim packages seems to lack python bindings and gvim provides vim, too.

thestinger commented on 2013-02-22 10:42 (UTC)

@bagnose: thanks, updated

commented on 2013-02-21 23:43 (UTC)

The dependency on 'cmake' is missing.

commented on 2013-02-13 18:35 (UTC)

@nagisa (I suppose you were also on the github discussion), depending on vim might be quite hard. Someone might use a custom vim package, which provides "vim" but does not provide "gvim". Thus depending on gvim would break this thing. Maybe the best solution (but still not quite perfect) would be to depend on vim but recommend gvim.

nagisa commented on 2013-02-13 17:34 (UTC)

You want to depend on gvim instead of vim. vim is not compiled with python support by default while gvim is.

thestinger commented on 2013-02-11 21:40 (UTC)

@sanderd17: fixed

asdil12 commented on 2013-02-06 09:51 (UTC)

use this PKGBUILD to get it working with python2