Package Details: neovim-git 0.7.0.r67.g5c53e29ca9-1

Git Clone URL: (read-only, click to copy)
Package Base: neovim-git
Description: Fork of Vim aiming to improve user experience, plugins, and GUIs.
Upstream URL:
Keywords: editor vim
Licenses: custom:neovim
Conflicts: neovim
Provides: neovim, vim-plugin-runtime
Submitter: fhahn
Maintainer: fwalch
Last Packager: fwalch
Votes: 234
Popularity: 2.61
First Submitted: 2014-02-21 19:50 (UTC)
Last Updated: 2022-04-23 19:28 (UTC)

Dependencies (19)

Required by (366)

Sources (1)

Pinned Comments

fwalch commented on 2016-07-04 19:52 (UTC) (edited on 2016-07-04 19:54 (UTC) by fwalch)

Please don't flag this package out-of-date just because the version number displayed on AUR seems old. This is normal for VCS packages. As long as building the package works without problems, it isn't necessary to update the PKGBUILD here. makepkg will automatically retrieve the latest version when you build the package locally.

Latest Comments

luukvbaal commented on 2022-06-29 21:15 (UTC)

Might I suggest the following diff as the breaking changes channel moved to the issue tracker:

--- neovim-git.install  2022-06-29 23:13:15.026592320 +0200
+++ neovim-git.install-1        2022-06-29 23:14:02.226289376 +0200
@@ -12,5 +12,5 @@
 post_upgrade() {
   echo ":: Check the following page to see whether this upgrade"
   echo "   includes any breaking changes:"
-  echo ""
+  echo ""

sixelannif commented on 2022-06-29 11:38 (UTC) (edited on 2022-06-29 12:05 (UTC) by sixelannif)

Hello. I am using Manjaro and it fails because of libvterm: error: target not found: libvterm-0.1 And sure enough that version is no longer available in the repositories

pacman -Ss libvterm  
community/libvterm 0.2-1
    Abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator
community/libvterm01 0.1.4-2 [installed]
    Abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator

So I tried to replace libvterm-0.1 by libvterm01 in PKGBUILD, but no good:

CMake Error at cmake/LibFindMacros.cmake:263 (message):

  We could not find development headers for LIBVTERM.  Do you have the
  necessary dev package installed? This package is REQUIRED and you need to
  install it or adjust CMake configuration in order to continue building

  Relevant CMake configuration variables:

    LIBVTERM_INCLUDE_DIR=<not found>
    LIBVTERM_LIBRARY=<not found>

  You may use CMake GUI, cmake -D or ccmake to modify the values.  Delete
  CMakeCache.txt to discard all values and force full re-detection if

Call Stack (most recent call first):
  cmake/FindLIBVTERM.cmake:10 (libfind_process)
  CMakeLists.txt:504 (find_package)

If I clone the neovim repo and run make CMAKE_BUILD_TYPE=RelWithDebInfo it works.

p00f commented on 2022-05-14 08:20 (UTC)

gperf is no longer required:

arsham commented on 2022-05-04 15:22 (UTC)

Based on the conversation here: the final result of the build "might" not use the luajit specified in the Neovim build scripts.

This is the part of the PKGBUILD file I came up with, that matches the Neovim's build instructions:

build() {
  cd "${srcdir}/${pkgname}"

check() {
  cd "${srcdir}/${pkgname}/build"
  ./bin/nvim --version
  ./bin/nvim --headless -u NONE -i NONE -c ':quit'

package() {
  cd "${srcdir}/${pkgname}/build"
  DESTDIR="${pkgdir}" cmake --build . --target install

  cd "${srcdir}/${pkgname}"
  install -Dm644 LICENSE.txt "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE.txt"
  install -Dm644 runtime/nvim.desktop "${pkgdir}/usr/share/applications/nvim.desktop"
  install -Dm644 runtime/nvim.png "${pkgdir}/usr/share/pixmaps/nvim.png"

  # Make Arch vim packages work
  mkdir -p "${pkgdir}"/etc/xdg/nvim
  echo "\" This line makes pacman-installed global Arch Linux vim packages work." > "${pkgdir}"/etc/xdg/nvim/sysinit.vim
  echo "source /usr/share/nvim/archlinux.vim" >> "${pkgdir}"/etc/xdg/nvim/sysinit.vim

  mkdir -p "${pkgdir}"/usr/share/vim
  echo "set runtimepath+=/usr/share/vim/vimfiles" > "${pkgdir}"/usr/share/nvim/archlinux.vim

fwalch commented on 2022-04-23 19:28 (UTC)

I'd just stay on libvterm-0.1 for now to avoid adding these hacks. Removed dependency on libutf8proc, thanks for pointing that out.

xiretza commented on 2022-04-21 06:49 (UTC)

See the corresponding commit on community/neovim for all the required hacks:

Derson5 commented on 2022-04-17 14:42 (UTC) (edited on 2022-04-17 16:48 (UTC) by Derson5)

@fwalch There is libvterm01 now in community repo. Could you update PKGBUILD?

zappolowski commented on 2022-04-03 18:31 (UTC)

It's also possible to use the bundled version of libvterm 0.1.4:

build() {
  # build the bundled version of libvterm as neovim is not (yet) compatible with 0.2
  cmake -S"${pkgname}/third-party" \
        -Bdeps \
  cmake --build deps

  cmake -S"${pkgname}" \
        -Bbuild \
        -DCMAKE_BUILD_TYPE=RelWithDebInfo \
        -DCMAKE_PREFIX_PATH=deps/usr \
  cmake --build build

And libutf8proc is not required anymore.

fwalch commented on 2022-03-18 21:24 (UTC)

Thanks everyone, especially xiretza for creating the libvterm-0.1 package. Updated the deps to use it.

7thSon commented on 2022-03-17 09:09 (UTC)

@fwalch will you update the package according to the suggestion by @xiretza? The package fails to build for me as well now due to some vterm error.

xiretza commented on 2022-03-13 11:36 (UTC)

libvterm in the repos was updated to the 0.2 upstream release, while neovim is still on 0.1.4 - I pushed libvterm-0.1 as a separate AUR package, the depends should be changed to that.

Derson5 commented on 2022-03-13 11:33 (UTC)

If anyone want to build Neovim from git, using this package, need to don't update libvterm package. Today was update to libvterm 0.2 version, and Neovim does not support it. For this moment, support for libvterm 0.2 version is planned for 0.8 version, so many many months from this day.

fwalch commented on 2022-03-12 20:21 (UTC)

Fixed, thanks!

Derson5 commented on 2022-03-12 19:08 (UTC) (edited on 2022-03-12 19:21 (UTC) by Derson5)

@fwalch, @7thSon is right. In PKGBUILD, at the end there is 4, that shouldn't be (30 not 304).

7thSon commented on 2022-03-12 17:30 (UTC)

I think there might be a typo somewhere since yay show this package update information: aur/neovim-git 0.6.0.r1235.gab456bc30-1 -> 0.6.0.r1235.gab456bc304-1

justinesmithies commented on 2022-03-12 15:17 (UTC) (edited on 2022-03-12 15:19 (UTC) by justinesmithies)

Since the last PKGBUILD update neovim-git constantly keeps saying there is an update and stays on the same version.

Aur (1) neovim-git-0.6.0.r1235.gab456bc304-1

:: Proceed with installation? [Y/n]: 

:: Downloading PKGBUILDs...
 PKGBUILDs up to date
fetching devel info...
==> Making package: neovim-git 0.6.0.r1235.gab456bc304-1 (Sat 12 Mar 2022 02:45:51 PM GMT)
==> Retrieving sources...
  -> Updating neovim-git git repo...
Fetching origin
==> Validating source files with sha256sums...
    neovim-git ... Skipped
==> Making package: neovim-git 0.6.0.r1235.gab456bc304-1 (Sat 12 Mar 2022 02:45:55 PM GMT)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Updating neovim-git git repo...
Fetching origin
==> Validating source files with sha256sums...
    neovim-git ... Skipped
==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of neovim-git git repo...
Cloning into 'neovim-git'...
==> Starting pkgver()...
==> Updated version: neovim-git 0.6.0.r1235.gab456bc30-1
==> Sources are ready.
neovim-git-0.6.0.r1235.gab456bc304-1: parsing pkg list...
:: neovim-git-0.6.0.r1235.gab456bc304-1 is up to date -- skipping build
loading packages...
warning: neovim-git-0.6.0.r1235.gab456bc30-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) neovim-git-0.6.0.r1235.gab456bc30-1

Total Installed Size:  32.17 MiB
Net Upgrade Size:       0.00 MiB

fwalch commented on 2022-03-12 13:33 (UTC)

@xiretza: fixed, thanks!

xiretza commented on 2022-03-11 16:43 (UTC)

The command in vercmp() should be replaced with git describe --long --tags --exclude=nightly, since tags after v0.5.0 have been unannotated.

fwalch commented on 2022-02-24 21:07 (UTC)

@Derson5 fixed, thanks!

Derson5 commented on 2022-02-24 13:44 (UTC) (edited on 2022-03-12 19:01 (UTC) by Derson5)

@fwalch you need to change LICENSE to LICENSE.txt. Without it, build will fail - see this.

dedguy21 commented on 2021-10-19 15:36 (UTC)

I've narrowed down the package that causes the #checkhealth error "E684: list index out of range: 0" to the neovim-lspconfig-git package.

I'm wondering if you have the same experience, and what you did to get past the checkhealth error.


dedguy21 commented on 2021-10-07 02:21 (UTC)

getting the follwing error when ":checkhealth:

health#check E684: list index out of range: 0

only happens with neovim-git, but not the neovim repo package.

Any clue what might be causing it, I'd like to continue using the git version.

groctel commented on 2021-07-03 08:05 (UTC)

Since 0.5.0 has be released and has added tree-sitter as a dependency I think it would be nice to add the new dependency and bump the pkgver :)

lmartinez-mirror commented on 2021-06-28 15:48 (UTC) (edited on 2021-06-28 16:18 (UTC) by lmartinez-mirror)

Due to changes from both Neovim and Treesitter upstream, this package will not compile with tree-sitter alone. Not sure if anyone using tree-sitter-git can weigh in on this.

EDIT: Package builds with tree-sitter-git.

therisen06 commented on 2021-05-03 13:38 (UTC)

Could you please add -DCMAKE_INSTALL_LIBDIR=lib to the cmake arguments? There is a lib64 vs lib conflict on Arch Linux derivatives (see

lmartinez-mirror commented on 2021-04-11 05:54 (UTC) (edited on 2021-04-25 00:20 (UTC) by lmartinez-mirror)

I noticed this package and neovim don't have any similar vimdoc.hook files for regenerating helptags. Are there any plans to add something like this to the packages, one that covers both /usr/share/vim/vimfiles/doc/ and /usr/share/nvim/runtime/doc/ maybe?

The last trace of discussion regarding this was a comment I dug up.

EDIT: I also think this package should provide neovim=0.5.0 seeing how that's what's actually reported by nvim --version.

fwalch commented on 2021-03-06 10:42 (UTC)

@lmartinez-mirror: Added, thanks!

lmartinez-mirror commented on 2021-02-17 21:59 (UTC)

Since neovim provides vim-plugin-runtime, wouldn't this package, as well? I see that the PKGBUILD also uses vim's plugin directory, so it would make sense to add it.

joshauc commented on 2021-02-12 07:53 (UTC)

This is great. Thanks for your work. Mine wasn't even a fix sorry for the spam.

fwalch commented on 2021-02-11 17:20 (UTC)

@joshauc: I took another look at this, and I think it can/should be fixed upstream. See #13844 and #13920.

joshauc commented on 2021-02-11 07:36 (UTC) (edited on 2021-02-11 07:40 (UTC) by joshauc)

@fwalch Sorry for asking again, but would -DCMAKE_C_FLAGS="-U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1"be added to the PKGFILE?

joshauc commented on 2021-01-17 08:27 (UTC) (edited on 2021-01-17 08:28 (UTC) by joshauc)

Sorry, I had to look more into this XD so I deleted my previews comment. There was an Issue with _FORTIFY_SOURCE=2 for neovim for Arch since it is the default in the makepkg. From what I understand this is usually good so it should be kept the same for the makepkg, but it is not compatible with neovim so it is disabled in the Cmake file. I think the best way is to pass it as an argument flag to Cmake to silence the warning.

My first comment was wrong since it would force the _FORTIFY_SOURCE=2 so I edit it :), also thanks for maintaining this package.


fwalch commented on 2021-01-09 10:12 (UTC)

@joshauc: Do you perhaps have -D_FORTIFY_SOURCE in your makepkg.conf? You can add the -U_FORTIFY_SOURCE there as well.

joshauc commented on 2021-01-03 14:48 (UTC) (edited on 2021-01-17 08:28 (UTC) by joshauc)

When I build the package with gcc a lot of warning are produced about

<command-line>:0:0: warning: "_FORTIFY_SOURCE" redefined
<command-line>:0:0: note: this is the location of the previous definition

To silence them I have to edit the PKGBUILD and add the following line to the CMAKE configuration:

  cmake -S"${pkgname}" -Bbuild \
        -DCMAKE_BUILD_TYPE=RelWithDebInfo \

Could this be add to the PKGFILE?

The solution was provided in this issue neovim/issues/2557.

coxackie commented on 2020-12-29 10:01 (UTC)

Out of curiosity, does anyone know/have a user repo containing pre-built binaries of this? (Built in Arch, of course.)

fwalch commented on 2020-11-03 17:56 (UTC)

just1602: Added the dependency, thanks.

just1602 commented on 2020-11-03 13:54 (UTC)

The package is failing to build since tree-sitter dependency looks missing :

In file included from /home/goldman/.cache/paru/clone/neovim-git/src/neovim-git/src/nvim/lua/executor.c:40:
/home/goldman/.cache/paru/clone/neovim-git/src/neovim-git/src/nvim/lua/treesitter.h:8:10: fatal error: tree_sitter/api.h: No such file or directory
    8 | #include "tree_sitter/api.h"
      |          ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [src/nvim/CMakeFiles/nvim.dir/build.make:622: src/nvim/auto/lua/executor.c.generated.h] Error 1
make[1]: *** [CMakeFiles/Makefile2:2666: src/nvim/CMakeFiles/nvim.dir/all] Error 2
make: *** [Makefile:171: all] Error 2
==> ERROR: A failure occurred in build().
error: failed to build 'neovim-git-0.4.0.r1426.g4ab7bbf3ea-1':

fwalch commented on 2020-10-22 15:32 (UTC) (edited on 2020-10-22 15:33 (UTC) by fwalch)

@jck: As Scimmia said, can you try setting e.g. MAKEFLAGS="-j<number of CPU cores>" in your makepkg.conf? On a recent system, using Make or Ninja should not really make a difference when compiling Neovim - it should only take a few seconds either way. On an older system of mine, Make actually runs faster than Ninja, so I would keep it unless there is really a significant advantage of using Ninja over Make for compiling Neovim on some systems.

Scimmia commented on 2020-10-21 15:32 (UTC)

@jck, probably because you didn't set the number of jobs in makepkg.conf

jck commented on 2020-10-21 15:18 (UTC)

Could you update the PKGBUILD to use ninja(similar to

This leads to a considerably faster build.

Shatur commented on 2020-07-06 08:28 (UTC)

@fwalch, thank you!

fwalch commented on 2020-07-06 08:08 (UTC)

Shatur: Updated the PKGBUILD, sorry it took so long.

Shatur commented on 2020-06-27 18:15 (UTC)

In my previous comment I meant to enable support for Arch vim packages. This is needed for fzf, for example.

drfunjohn commented on 2020-04-03 17:30 (UTC)

YES! It has installed latest version:

NVIM v0.5.0-424-g6ca7ebb34

Shatur commented on 2020-02-21 23:28 (UTC) (edited on 2020-02-21 23:52 (UTC) by Shatur)

Could update the package according to the official? This is needed to make Arch vim packages work.

Here is the updated PKGBUILD.

fwalch commented on 2020-02-10 20:57 (UTC)

The upstream issue has been fixed, building the package should work again.

KokaKiwi commented on 2020-02-09 00:22 (UTC)

The failing build stuff got an issue on upstream repository:

vollekannehoschi commented on 2020-02-08 17:21 (UTC)

I get an error when trying to update:

-- Installing: /home/hoschi/.cache/yay/neovim-git/pkg/neovim-git/usr/bin/nvim
CMake Error at src/nvim/cmake_install.cmake:93 (file):
  file INSTALL cannot find
  "/home/hoschi/.cache/yay/neovim-git/src/neovim-git/build/lib/nvim": No such
  file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:82 (include)

make: *** [Makefile:86: install] Fehler 1

fwalch commented on 2019-10-26 16:52 (UTC)

jkhsjdhjs: Added, thanks.

jkhsjdhjs commented on 2019-10-25 13:51 (UTC)

Building this package also works on aarch64 without issues.

fwalch commented on 2019-09-30 09:09 (UTC)

eggze: Fixed, thanks.

eggze commented on 2019-09-28 20:21 (UTC)

It looks like merge of broke the build:

CMake Error at /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:137 (message):
  Could NOT find Utf8proc (missing: UTF8PROC_LIBRARY UTF8PROC_INCLUDE_DIR)
Call Stack (most recent call first):
  /usr/share/cmake-3.15/Modules/FindPackageHandleStandardArgs.cmake:378 (_FPHSA_FAILURE_MESSAGE)
  cmake/FindUtf8proc.cmake:51 (find_package_handle_standard_args)
  CMakeLists.txt:378 (find_package)

According to the PR description libutf8proc should be added to the deps.

fwalch commented on 2019-09-24 18:09 (UTC)

E5ten: Done, thanks.

E5ten commented on 2019-09-20 03:09 (UTC)

The dependency on jemalloc should be removed

fwalch commented on 2019-09-19 20:17 (UTC)

Changed the dependency back to "libvterm" as the Community package was updated a few days ago.

fwalch commented on 2019-09-13 20:50 (UTC)

Changed dependency to libvterm-bzr, thanks for the reports!

mystal commented on 2019-09-12 18:57 (UTC)

I'm also running into the same build problems that @dsifford is. Might need to depend on a libvterm-git package?

dsifford commented on 2019-09-11 21:25 (UTC)

Having some trouble building this now after commit 7bb858c39cac9b9af321fc90470c91d2e31ed96e

Looks to be related to libvterm changing the interface of the VTermColor struct.


/home/dsifford/.cache/yay/neovim-git/src/neovim-git/src/nvim/terminal.c:572:52: error: ‘VTermColor’ {aka ‘struct <anonymous>’} has no member named ‘rgb’
  572 |   return RGB_(,,;
      |                                                    ^
/home/dsifford/.cache/yay/neovim-git/src/neovim-git/src/nvim/terminal.c:601:31: error: ‘VTermColor’ {aka ‘struct <anonymous>’} has no member named ‘indexed’
  601 |                      ? cell.fg.indexed.idx + 1 : 0);
      |                               ^
/home/dsifford/.cache/yay/neovim-git/src/neovim-git/src/nvim/terminal.c:603:31: error: ‘VTermColor’ {aka ‘struct <anonymous>’} has no member named ‘indexed’
  603 |                      ? + 1 : 0);
      |                               ^

Anyone else having these problems as well?

fwalch commented on 2019-06-11 21:16 (UTC)

@dsifford @jbradaric Added a dependency on libluv, thanks!

dsifford commented on 2019-06-11 13:18 (UTC)

@jbradaric Awesome. That fixed it for me as well.

jbradaric commented on 2019-06-11 08:53 (UTC)

dsifford: I get the same error, it seems that neovim now depends on libluv. I've added an AUR package for it, after installing the package the build passes and neovim works.

dsifford commented on 2019-06-10 21:16 (UTC) (edited on 2019-06-10 21:16 (UTC) by dsifford)

Is anyone else getting CMAKE build errors today (2019/06/10)?

This package no longer compiles for me.

   used as include directory in directory [....] (repeated dozens of times)

    linked by target "libnvim" in directory [...]
    linked by target "nvim-test" in directory [...]
    linked by target "nvim" in directory [...]

Svenstaro commented on 2019-05-01 04:53 (UTC)

Just a heads-up: I've made some changes in the official neovim package which you might want to follow. It will cut some complexity from the package. You might also want to use Ninja as the build system.

fwalch commented on 2018-11-25 10:36 (UTC)

zhou13: Sure, updated!

zhou13 commented on 2018-11-25 09:22 (UTC)

I can successfully compile this package on my raspberry pi. Could you add 'armv7h' and 'armv6h' to the arch variable? Thanks!

swiftgeek commented on 2018-02-26 03:29 (UTC)

I had leftover libtermkey-bzr and libvterm-bzr leftover packages, sorry.

warp commented on 2018-02-23 10:08 (UTC)

@fwalch Thanks it worked.

fwalch commented on 2018-02-23 07:16 (UTC)

The mpack error is due to, which has been fixed with lua51-mpack 1.0.7-2. @warp: If you update your packages (and maybe use makepkg -C to build neovim-git), everything should work.

warp commented on 2018-02-23 03:57 (UTC)

@Fandekasp I installed lua-lpeg and libmpack, still getting the error when I try run vim. Tried to rebuild it I get mpack error. Is there a step missing?

Fandekasp commented on 2018-02-23 02:32 (UTC) (edited on 2018-02-23 02:43 (UTC) by Fandekasp)

@fwalch, I also got the unibilium error, and when trying to rebuild neovim, it first failed asking me to install lua-lpeg, then failed again asking for lua-mpack. Except it is looking for lua53 mpack, which isn't available on aur (only lua51-mpack?). If trying to symlink /usr/lib/lua/5.1/ → /usr/lib/lua/5.3 , it fails again, this time looking for a lua 5.2 mpack O_o

EDIT: Oh, it looked for lua 5.2 and lua 5.3 only because the lua/5.1/ file was broken (missing related Reinstalling lua51-mpack didn't help.

SOLVED:I just needed to install libmpack, then reinstalling neovim-git worked the unibilium error disappeared.

SUMMARY: To fix the unibilium error, run pacman -S lua-lpeg libmpack neovim-git

fwalch commented on 2018-02-22 20:09 (UTC)

swiftgeek: I just rebuilt against unibilium 2.0.0 without problems. If you're still having problems, can you open an issue upstream?

swiftgeek commented on 2018-02-21 23:40 (UTC)

I had to downgrade unibilium to make it work :(

chetgurevitch commented on 2017-08-07 02:11 (UTC)

Duplicate tag issues arise regularly [1] causing builds to fail until the user does a clean build. This can be fixed by running "rm -rf runtime/docs" directly before the cmake generator [2]. For now I've uploaded neovim-git-ninja with that fix and full incremental build support [3]. [1] (most recent commit causing rebuilds to fail) [2] (commit documenting fix) [3]

chetgurevitch commented on 2017-07-24 02:50 (UTC)

Thanks for the hints, I fixed arch and modified the PKGBUILD to use ninja without relying on the top-level makefile for any step.

fwalch commented on 2017-06-25 16:56 (UTC)

chetgurevitch: Thanks for the hint about LuaJIT, I had missed moving that from makedepends to depends. As for your other changes, it looks like you switched the code to use the top-level Makefile. This Makefile is only intended for developers and should not be used for packaging. Also, see [1] for hints about when to use "arch=(any)". [1]

chetgurevitch commented on 2017-06-25 04:48 (UTC) (edited on 2017-06-25 05:12 (UTC) by chetgurevitch)

Hi, I've been testing some changes to the package. I updated the dependency list to contain luajit [1], switched the build system to ninja for significantly faster (incremental) builds and cut out some bundled deps along with other minor cleanup work. I'd be happy to co-maintain the package if that's alright with you, otherwise I've linked the changes below for you to look over [2]. I've also got an updated version of the official neovim package and lua51-mpack but I'm holding off on contacting Sven for now. The latter required major changes (including splitting the package [3] [4]) which rely on a fix only available on git currently and I'd like to land any changes to the repo packages together. Everything's in that github repo though. [1] [2] [3] [4]

fwalch commented on 2017-05-03 20:37 (UTC)

machfour: Thanks! I updated the PKGBUILD according to your suggestions.

machfour commented on 2017-05-03 04:44 (UTC)

Hi, the latest version of neovim now has a .desktop file and icon file to go with it. To install these files appropriately, I used the following package() function: package() { cd "${pkgname}/build" make DESTDIR="${pkgdir}" install cd .. install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" install -Dm644 runtime/nvim.desktop "${pkgdir}/usr/share/applications/nvim.desktop" install -Dm644 runtime/nvim.png "${pkgdir}/usr/share/pixmaps/nvim.png" }

fwalch commented on 2017-02-21 19:32 (UTC)

rthyberg: The build should use LuaJIT, which has bitop built in. Did you see [1]? [1]

rthyberg commented on 2017-02-21 01:29 (UTC) (edited on 2017-02-22 22:26 (UTC) by rthyberg)

Missing dependency lua51-bitop Also the cmake looks for the lua interpreter at /usr/bin/lua when it should be /usr/bin/lua5.1

htfy96 commented on 2017-02-01 06:20 (UTC)

Now it comes with a builtin .desktop file( Is there anything to change in this repo?

fwalch commented on 2016-12-18 20:25 (UTC)

nishantvarma: Sorry, I don't understand your question. gperf is already a build-time dependency.

nishantvarma commented on 2016-12-18 17:32 (UTC) (edited on 2016-12-18 17:33 (UTC) by nishantvarma)

gperf needs to be installed and it can be obtained from package server. How can this be updated?

fwalch commented on 2016-11-03 12:28 (UTC)

rumpelsepp: This was intentional, and in line with how e.g. the Homebrew formula builds from VCS [1]. However, after discussing upstream, the formula will be changed to use RelWithDebInfo, and I did the same for this package. [1]

rumpelsepp commented on 2016-11-02 11:32 (UTC)

This package generates a Development build. From :CheckHealth : ## Performance - INFO: Build type: Dev - WARNING: Non-optimized build-type. Nvim will be slower. - SUGGESTIONS: - Install a different Nvim package, or rebuild with `CMAKE_BUILD_TYPE=RelWithDebInfo`. - See

Scimmia commented on 2016-08-15 16:40 (UTC)

It's a -git package built from the latest development HEAD. Both common sense and a quick look at the PKGBUILD tell you it's not a release build.

warp commented on 2016-08-15 16:37 (UTC)

Is it set to release build? Why am I getting .nvimlog in $HOME directory?

fwalch commented on 2016-08-07 22:30 (UTC) (edited on 2016-08-07 22:59 (UTC) by fwalch)

ludat: The version number follows the guidelines at [1]. *Edit:* Ah, I guess you mean change just the pkgver variable in the PKGBUILD to "latest", since it will be updated by makepkg? While theoretically possible, no other Arch package seems to do it (?), and it's technically an invalid version, so I'd rather just stick with the current Arch practices. [1]

ludat commented on 2016-08-07 04:30 (UTC)

should the version be something like `latest`? since the version number doesn't really mean anything now.

linduxed commented on 2016-07-28 07:48 (UTC)

Commenting out the LUA_CPATH and LUA_PATH environment variable setting in my Zsh configuration did indeed help. Thank you!

fwalch commented on 2016-07-28 06:34 (UTC)

linduxed: Something is definitely broken here. LuaJIT should never try to load from /usr/lib/lua/5.3, it can only use Lua 5.1 modules. Try unsetting the LUA_CPATH environment variable (or setting it to /usr/lib/lua/5.1). In any case, I don't think your problem is related to this package or to Neovim.

linduxed commented on 2016-07-27 23:59 (UTC)

This is the output I get from that command (even after doing a `pacman -S lua51-lpeg`): $ luajit -e "require('lpeg')" luajit: error loading module 'lpeg' from file '/usr/lib/lua/5.3/': /usr/lib/lua/5.3/ undefined symbol: luaL_setfuncs stack traceback: [C]: at 0x00452850 [C]: in function 'require' (command line):1: in main chunk [C]: at 0x00404750

fwalch commented on 2016-07-27 21:20 (UTC)

linduxed: Hm, works for me.. do you get any error if you execute `luajit -e "require('lpeg')"`? If yes, there seems to be a problem with your Lua installation (maybe try reinstalling lua51-lpeg). If not, could you post your problem upstream at You can ping me with @fwalch.

linduxed commented on 2016-07-27 15:34 (UTC)

I'm currently getting this error when I build with `makepkg -C`: -- Checking Lua interpreter /usr/bin/luajit -- [/usr/bin/luajit] The 'lpeg' lua package is required for building Neovim -- Checking Lua interpreter /usr/bin/lua5.1 -- [/usr/bin/lua5.1] The 'lpeg' lua package is required for building Neovim -- Checking Lua interpreter /usr/bin/lua5.2 -- [/usr/bin/lua5.2] The 'lpeg' lua package is required for building Neovim -- Checking Lua interpreter /usr/bin/lua -- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim CMake Error at CMakeLists.txt:392 (message): A suitable Lua interpreter was not found. `pacman -Qs lua` yields the following:

fwalch commented on 2016-07-04 19:52 (UTC) (edited on 2016-07-04 19:54 (UTC) by fwalch)

Please don't flag this package out-of-date just because the version number displayed on AUR seems old. This is normal for VCS packages. As long as building the package works without problems, it isn't necessary to update the PKGBUILD here. makepkg will automatically retrieve the latest version when you build the package locally.

fwalch commented on 2016-06-27 09:17 (UTC)

anaveragehuman: It was added to keep debug symbols to get backtraces on crashes/assertion failures.

commented on 2016-06-24 20:02 (UTC)

Is there a specific reason as to why `options=(!strip)` is in the PKGBUILD? It seems to make the package 7 MB larger compared to neovim in the community repository.

nishantvarma commented on 2016-06-16 16:39 (UTC) (edited on 2016-06-16 16:39 (UTC) by nishantvarma)

I installed lua51-mpack and it worked. However I didn't see a standard error that usually shows up when a package is not there. Also shouldn't lua51-mpack be installed as it in arch repository? PS: I tried makepkg -C so that might be needed.

fwalch commented on 2016-05-30 19:52 (UTC)

blueyed: I can't reproduce; did you try makepkg -C? If the problem persists, can you open an issue on Github? I think that should be fixed upstream.

blueyed commented on 2016-05-30 00:19 (UTC)

Fails to build for me: ==> Starting pkgver()... ==> Removing existing $pkgdir/ directory... ==> Starting build()... -- Replacing -O3 in CMAKE_C_FLAGS_RELEASE with -O2. -- Removing --sort-common from linker flags. -- Found Iconv -- Checking Lua interpreter /usr/bin/lua -- [/usr/bin/lua] The 'lpeg' lua package is required for building Neovim CMake Error at CMakeLists.txt:395 (message): A suitable Lua interpreter was not found. The problem is that it uses /usr/bin/lua and not luajit from makedepends. This fixes it: @@ -33,6 +33,7 @@ build() { -DCMAKE_BUILD_TYPE=Dev \ -DCMAKE_INSTALL_PREFIX=/usr \ -DENABLE_JEMALLOC=ON \ + -DLUA_PRG=/usr/bin/luajit \ .. make }

fwalch commented on 2016-04-23 17:43 (UTC) (edited on 2016-04-23 18:02 (UTC) by fwalch)

euclio: Did you try makepkg -C? If the problem persists, can you open an issue at

euclio commented on 2016-04-23 17:23 (UTC)

I'm still having the problem indicated by cirk2. His patch fixed it.

shulhan commented on 2016-04-19 04:48 (UTC)

Thanks fwalch.

fwalch commented on 2016-04-18 19:59 (UTC)

libmpack still does not have a new release with a nice Makefile for systemwide installation, but I packaged it with Luarocks for now. Thanks to sulhan, zoqaeski, bradst, cirk2 for reporting the broken build.

cirk2 commented on 2016-04-18 13:58 (UTC)

Yeah got confused by the cmake output which only reported the missing packages for /usr/bin/lua also works without that.

fwalch commented on 2016-04-17 06:46 (UTC) (edited on 2016-04-17 06:51 (UTC) by fwalch)

cirk2: LuaJIT can use installed Lua 5.1 packages, so no need to change anything. libmpack is currently not easily packagable, that's what I'm waiting for to update the PKGBUILD:

cirk2 commented on 2016-04-16 10:28 (UTC) (edited on 2016-04-16 11:32 (UTC) by cirk2)

The build now depends on the mpack lua rock (currently has no AUR package): also it depends on lua51-bitop. Also the build cmake test 'luajit' and 'lua' the latter on arch points to lua 5.3 not 5.1. I fixed it locally with a symlink, but it looks like it can be overriden by setting LUA_PRG for cmake. Besides the missing mpack this fixes the pkgbuild for me: diff --git a/PKGBUILD b/PKGBUILD index 5076fa1..f1ffe67 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -9,7 +9,7 @@ arch=('i686' 'x86_64') url='' license=('custom:neovim') depends=('jemalloc' 'libtermkey' 'libuv' 'libvterm' 'msgpack-c' 'unibilium') -makedepends=('cmake' 'git' 'luajit' 'lua51-messagepack' 'lua51-lpeg') +makedepends=('cmake' 'git' 'luajit' 'lua51-messagepack' 'lua51-lpeg' 'lua51-bitop') optdepends=('python2-neovim: for Python 2 plugin support (see :help nvim-python)' 'python-neovim: for Python 3 plugin support (see :help nvim-python)' 'xclip: for clipboard support (or xsel) (see :help nvim-clipboard)' @@ -33,6 +33,7 @@ build() { -DCMAKE_BUILD_TYPE=Dev \ -DCMAKE_INSTALL_PREFIX=/usr \ -DENABLE_JEMALLOC=ON \ + -DLUA_PRG=/usr/bin/lua5.1 \ .. make }

bradst commented on 2016-04-16 02:23 (UTC)

Seems like the build is currently broken due to some recent changes upstream: ----- -- Checking Lua interpreter /usr/bin/luajit -- [/usr/bin/luajit] The 'mpack' lua package is required for building Neovim -- Checking Lua interpreter /usr/bin/lua -- [/usr/bin/lua] The 'mpack' lua package is required for building Neovim CMake Error at CMakeLists.txt:390 (message): A suitable Lua interpreter was not found. ... ==> ERROR: A failure occurred in build(). ----- Relevant changes: They are now using 'libmpack' ( instead of lua51-messagepack. They are also now using a libuv Lua binding called 'luv' ( Looks like the following may be a quick fix for the 'luv' dependency, but I wasn't able to try it since the build doesn't get that far:

fwalch commented on 2016-03-14 20:41 (UTC)

timofonic: Probably not. I found some discussion in

timofonic commented on 2016-03-14 01:17 (UTC)

@fwalch Can that be automated?

fwalch commented on 2016-01-23 00:24 (UTC)

Heads up: When upgrading to msgpack-c 1.4.0 (currently in [community-testing]), this package will have to be recompiled (I had to use makepkg -C, to clean the CMake cache) to link the new

fwalch commented on 2016-01-19 18:58 (UTC)

agauniyal: Just setting the flag in /etc/makepkg.conf and running makepkg should work; are you experiencing problems?

agauniyal commented on 2016-01-19 13:16 (UTC)

How should I build this with -march=native flag?

mrkline commented on 2016-01-18 19:54 (UTC)

My apologies - I hadn't swapped out libvterm-bzr for libvterm when it was added to the Arch repos in November.

fwalch commented on 2016-01-06 17:49 (UTC)

mrkline: The package currently depends on "libvterm" and "libtermkey", which are both in the Arch repos. Bazaar is not required to build.

mrkline commented on 2016-01-05 18:47 (UTC)

Is there any chance this package could use neovim's Github mirrors of libvterm and libtermkey ( and, respectively)? This eliminates bazaar as a build dependency, and cloning from Github seems to go *much* faster than from

fwalch commented on 2015-11-03 07:15 (UTC)

On second thought, I agree with Scimmia. If you want a clean build, you can use 'makepkg -C'.

Scimmia commented on 2015-11-02 15:26 (UTC)

FWIW, I disagree with eolianoe. If you want a clean build, delete the src dir before building. In the vast majority of cases, incremental builds should be fine.

fwalch commented on 2015-11-02 09:08 (UTC)

eolianoe: Thanks! Will incorporate that later. flannelhead: It's still required, I just linked it statically in the "neovim" package. Probably will do the same here, as the libvterm API will likely get breaking changes soon (and thus Neovim would not build with the latest -bzr version anymore).

flannelhead commented on 2015-11-02 09:05 (UTC)

Is libvterm-bzr required as a dependency any longer? The non-git neovim package seems to have dropped it.

eolianoe commented on 2015-11-02 08:21 (UTC)

Could you clean the build directory before the build [1], in order to have a clean build each time ? [1]

fwalch commented on 2015-10-27 07:41 (UTC)

FYI, from [1]: Neovim now supports XDG configuration. The default config paths changed, so ~/.nvimrc and ~/.nvim/ will *not* be found by default. See :help nvim-from-vim for quick migration steps. [1]

fwalch commented on 2015-10-24 05:43 (UTC)

This package has been flagged out-of-date with a note "please update to the latest version", but AFAIK manually updating the version should not be necessary for a VCS package. I therefore unflagged the package without any PKGBUILD changes. If I'm missing something, please let me know.

fwalch commented on 2015-10-06 22:03 (UTC)

eworm: Ha, timing.. just after you write this (and months after the last commit to libtermkey), it looks like libtermkey 0.18 will released soon, because of bugfixes for Neovim [1]. When that's up, I'll change the dependency. [1]

fwalch commented on 2015-10-06 21:01 (UTC)

eworm: upstream uses a non-released version [1] (from a Git mirror, otherwise identical to the original bzr repo), therefore I'd rather not change that. Some commits to libtermkey after its last release (therefore only in -bzr package) were contributed by Neovim when it switched the terminal UI to libtermkey, so changing the dependency would probably introduce bugs. [1]

eworm commented on 2015-10-06 08:09 (UTC)

Looks like this works just fine with libtermkey (the non-bzr package). Can we change the dependency, please? This will not break existing setups as libtermkey-zr provides libtermkey.

fwalch commented on 2015-09-26 21:59 (UTC)

willemw: 1) Yes: $ vercmp 1.0 1.0.r1 -1 3) Well, that's a legacy that can't be changed, because: $ vercmp 0.r1 r1 1 Also, according to the wiki a leading zero is allowed: "If there are no public releases and no repository tags then zero could be used as a release number". Anyway, this will be moot as soon as the first release is out (which is soon). Then the version will be in format 1.0.r1.

willemw commented on 2015-09-26 17:09 (UTC)

1) Dependency check against Neovim's release version ("neovim>=1.0"): OK. Dependency check against an AUR VCS-package version ("neovim>=$pkgver") ==> ("neovim>=1.0.r10"): does not seem OK to me. Didn't know that "pkgver=1.0.r10" would satisfy "neovim>=1.0". Sure? 2) To be honest, in one of my packages I also have a 'depends' refer to a VCS-package. 3) pkgver() function should return a string starting with a version number or with an 'r', not with a dummy '0'.

fwalch commented on 2015-09-26 16:31 (UTC)

willemw: Thanks for your comments! - Conflicts should be detected because of conflicts=(). The pkgver in provides=() is just to eventually be able to handle versioned dependencies. Say after Neovim's 1.0 release, there would be a "neovim" package with pgkver=1.0 and this neovim-git package with pkgver=1.0.r10 (assuming 10 upstream commits after 1.0 release for this example). If something depends on "neovim>=1.0", both "neovim" and "neovim-git" will be able to satisfy that. - Generally, I agree. However the problem is that there are no non-VCS packages for these dependencies, because there are no (or only outdated) upstream releases. If I just use depends=('libvterm'), when installing this package AUR helpers will complain that there is no libvterm package and abort. So this would be very inconvenient for users. - Do you mean that pkgver (the variable) is not up-to-date? That's inherent with VCS packages (and the reason for the pkgver() function), as otherwise for each upstream commit I'd need to push an update to the PKGBUILD.

willemw commented on 2015-09-26 16:14 (UTC)

Some useful general remarks, I hope: - pkgver in provides=("neovim=${pkgver}"), is that correct? Doesn't this mean that conflicts will not be detected when another version is already installed? - depends/optdepends/makedepends should normally not refer to devel (bzr, git, etc.) names. For example, libtermkey-bzr should define provides=("libtermkey"). Then 'depends' here can refer to libtermkey. - pkgver() is not up-to-date.

fwalch commented on 2015-09-22 21:21 (UTC)

@rtwo: I can reproduce, but it's not related to the dependencies. Let's continue the discussion in your upstream issue ( @fauno: Neovim depends on unibilium and libtermkey since 2014, so naturally lots of things have changed in the meantime. Please report problems upstream.

fauno commented on 2015-09-22 19:35 (UTC)

hi, i've been trying to upgrade my neovim-git build but since it depends on unibilium, libvterm and libtermkey there's a noticeable lag while exiting insert mode. it's really annoying because when i hit escape while in insert mode and start typing commands at normal speed, the escape gets "cancelled" and it continues in insert mode. does this happen to anyone else? my old build didn't depend on these packages and was even faster than vim, but it broke with the ncurses upgrade :(

rtwo commented on 2015-09-22 18:32 (UTC)

I am having a really wired bug that only appears when I build neovim via aur. nvim -u NONE -c 'set autochdir' Then type :b<TAB> which results in :bNext (but expected behavior would be :b - with a list of possible completions). Can someone please confirm? I am also happy for any suggestions on what might be causing this (wrong deps?) and how I might be able to track this down.

fwalch commented on 2015-09-16 15:10 (UTC)

@lilydjwg: Hmm, I see.. that's a bit tricky. I don't want to introduce a dependency on Python in this package. I will check upstream if this file could possible be moved into the python-neovim package.

lilydjwg commented on 2015-09-16 14:30 (UTC)

Hi, would you compile the Python script /usr/share/nvim/runtime/autoload/provider/ so that after running as root, there won't be a /usr/share/nvim/runtime/autoload/provider/__pycache__/script_host.cpython-34.pyc file pacman doesn't have an record. Use python -m compileall ${pkgdir}/usr/share/nvim/runtime/autoload/provider should work.

fwalch commented on 2015-09-10 16:21 (UTC)

FYI: if you get "nvim: error while loading shared libraries: cannot open shared object file: No such file or directory", this is because you updated jemalloc, and you have to rebuild Neovim to link against the updated version.

fwalch commented on 2015-08-26 10:31 (UTC)

Turns out it was actually the nvim invocation in the PKGBUILD's "check()" function that started causing problems. Updated the PKGBUILD; the flickering should now be gone and pacaur should again be able to install this package.

fwalch commented on 2015-08-24 09:58 (UTC)

@Spyhawk: Well, to be fair, you *can* install this package with plain makepkg -U, yaourt, aura, and packer (didn't test other helpers). So you could also argue that pacaur does something that "nobody" else is doing. But I'll see what I can do.

fwalch commented on 2015-08-18 15:37 (UTC)

@z33ky, NoniusSenior: Neovim is invoked during the installation to generate helptags for :help. Due to upstream changes, this now shows as a brief flickering of the terminal screen. FYI, installing this package currently doesn't work with the latest released version of pacaur. The problem is fixed in pacaur-git.

NoniusSenior commented on 2015-08-18 08:12 (UTC)

I had the same problem as @z33ky, gnome terminal went blank. I did not modify anything.

z33ky commented on 2015-08-13 15:28 (UTC)

My terminal went completely blank for a fraction of a second but returned to normal. It was also near the completion of the build. I have modified the PKGBUILD to use Ninja instead of GNU Make though.

cgirard commented on 2015-08-13 14:56 (UTC)

@slester: yes I have seen that too. Killing the process usually help but I have not been able to understand what was the reason.

fwalch commented on 2015-07-21 10:55 (UTC)

@anatolik: Sorry, forgot to add: It should be possible to switch the dependencies from "luajit lua51-lpeg lua51-messagepack" to "luajit lua52 lua52-lpeg lua52-messagepack lua52-bitop" or "luajit lua lua-lpeg lua-messagepack lua-bitop" (bitop is "built in" in LuaJIT). Since LuaJIT is required anyway, I didn't want to maintain an explicit dependency on an additional Lua.

fwalch commented on 2015-07-21 10:52 (UTC)

@anatolik: Neovim requires LuaJIT, which can be used as a replacement for Lua 5.1. Because of this, the Lua dependencies are "lua51-*" packages. The "lua51" package is not required, but still pulled in since "luajit" does not "provides=(lua51)".

anatolik commented on 2015-07-20 20:09 (UTC)

BTW do you know the reason neovim uses lua51 instead of up-to-date lua53?

fwalch commented on 2015-07-04 10:38 (UTC)

@tb01110100: Probably not. This package only provides the "nvim" executable, not "vim" and others (e.g. "vimdiff"). Also, plugin packages depending on vim (e.g. "vim-nerdtree") won't work with Neovim since the runtime path is different ("/usr/share/nvim" vs "/usr/share/vim").

oats commented on 2015-07-02 16:57 (UTC)

Could vim be added to the provides array?

fwalch commented on 2015-06-23 15:08 (UTC)

Uploaded to AUR4. Took this opportunity to change the libvterm dependency to "libvterm-bzr".

fwalch commented on 2015-06-06 11:36 (UTC)

pacaur should now again be able to install this package.

fwalch commented on 2015-06-04 09:18 (UTC)

@swiftgeek: Apologies, I did not notice it sets the default PATH in a /etc/profile.d file. Anyway, fixed upstream:

swiftgeek commented on 2015-06-04 08:40 (UTC)

1. hardening wrapper is a build requirement for lots of packages similar to neovim (fork from old stagnated community) eg. mpv, so not exactly an own personal choice having wrapper and stock makepkg.conf reproduces the issue 2. PATH="${PATH/\/usr\/lib\/hardening-wrapper\/bin\:/}"

fwalch commented on 2015-06-04 08:24 (UTC)

The last question was just for my curiosity. In any case, I'm not sure why Neovim doesn't do the right thing, since it checks if FORTIFY_SOURCE is set too high: This should trigger even in case of the wrapper script.

fwalch commented on 2015-06-04 08:20 (UTC)

@swiftgeek: That's because I have the following in /etc/makepkg.conf: CFLAGS="-march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2" Neovim doesn't work with FORTIFY_SOURCE=2, so it adds -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1. Only if I remove the FORTIFY_SOURCE stuff from my /etc/makepkg.conf, I can reproduce your error. In the other case, hardened-wrapper will automatically use FORTIFY_SOURCE=1 and not break the build. So, if you want hardened executables *all the time* (since hardened-wrapper is apparently in your default PATH), why don't you just set the appropriate CFLAGS in /etc/makepkg.conf?

swiftgeek commented on 2015-06-04 08:06 (UTC)

Just as explained in issue - setting any vim variable (triggers buffer overflow detection) While i have -D_FORTIFY_SOURCE=2 in makepkg.conf it is dropped in resulting cc (`pgrep -a cc` during compilation for actual compilation line) hardening-wrapper obviously bypasses all logic in cmake and pushes own flags Also your line is very curious anyway: -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1

fwalch commented on 2015-06-04 07:53 (UTC)

@swiftgeek: Just compiled and ran nvim with hardening-wrapper without problems. To confirm that it was used, some output from 'nvim --version': Compilation: /usr/lib/hardening-wrapper/bin/cc -march=native -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Wconversion -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -DINCLUDE_GENERATED_DECLARATIONS -DHAVE_CONFIG_H What exactly does not work in your case? (maybe create a new issue at so we can discuss it without flooding the comments here).

swiftgeek commented on 2015-06-03 17:41 (UTC)

Build stage conficts with hardening-wrapper, please drop it from PATH in build() till #223 is resolved (/usr/lib/hardening-wrapper/bin)

fwalch commented on 2015-06-01 06:56 (UTC)

@Emil: Can you try again with `makepkg -C`? If that doesn't help, can you open an issue at [1]? [1]

Emil commented on 2015-05-31 23:30 (UTC)

I get this erros while trying to build: ... -- Found LibUV: /usr/lib64/ CMake Error at /usr/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find Msgpack (missing: MSGPACK_LIBRARY MSGPACK_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) cmake/FindMsgpack.cmake:46 (find_package_handle_standard_args) CMakeLists.txt:178 (find_package) -- Configuring incomplete, errors occurred! See also "/home/emil/Downloads/neovim-git/src/neovim-git/build/CMakeFiles/CMakeOutput.log". See also "/home/emil/Downloads/neovim-git/src/neovim-git/build/CMakeFiles/CMakeError.log". log files:, Any idea what's going wrong here?

donnut commented on 2015-05-29 12:55 (UTC)

Solved the issue with MessagePack by making the package in a clean directory.

donnut commented on 2015-05-29 10:51 (UTC)

I've installed neovim successfully up to version neovim-git-0.r3370.df3abf4 Attempting to upgrade to 0.r3530.fa0f122 gives a problem with the MessagePack: > -- [/usr/bin/lua] The 'MessagePack' lua package is required for building Neovim > CMake Error at CMakeLists.txt:247 (message): > A suitable Lua interpreter was not found lua51-messagepack from AUR is installed Reading a comment of @ingvij I tryed to specify lua5.1 instead of the system lua (5.3) in CMakeCache.txt. This gives the error: > -- Checking Lua interpreter /usr/bin/lua5.1 > -- [/usr/bin/lua5.1] The 'bit' lua package is required for building Neovim > CMake Error at CMakeLists.txt:247 (message): > A suitable Lua interpreter was not found Any idea what I'm doing wrong?

ingvij commented on 2015-05-27 18:13 (UTC)

@fwalch: Yep, it's resolved. Thanks

fwalch commented on 2015-05-27 14:55 (UTC)

The issue with `makepkg -i` should be resolved now. There's still a problem when installing with pacaur [1]. [1]

fwalch commented on 2015-05-22 18:01 (UTC)

@ingvij: There's a problem with the `-i` part of `makepkg -si`, but it's due to an upstream bug (see also An upstream fix is in the works. The lua problem sounds like a different matter.. can you report it at and post the full build output?

ingvij commented on 2015-05-22 17:46 (UTC)

Due to recent updates, I'm unable to build this package simply by `makepkg -si`. I had to manually update `CMakeCache.txt` to point to `/usr/bin/lua5.1` in order to make it work.

fwalch commented on 2015-05-14 10:13 (UTC) Installing the manpages will be handled upstream, see [1]. It shouldn't require any changes in the PKGBUILD. [1]

johncf commented on 2015-05-14 10:00 (UTC)

Manpages for nvim and nvimtutor have been added... Please include it too...

cgirard commented on 2015-05-05 09:54 (UTC)

Thanks for pointing me in the right direction. I had not cleaned the src folder. It was thus picking the wrong Lua binary and not finding messagepack. Everything is working now.

fwalch commented on 2015-05-05 09:48 (UTC)

@cgirard: LuaJIT should pick up all Lua 5.1 (not 5.2!) libs, as far as I know. To test, for example when lua51-messagepack is installed: luajit -e "require('MessagePack')" Is there something not working for you?

cgirard commented on 2015-05-05 09:32 (UTC)

Is there something to do to make lua libs available to LuaJIT?

fwalch commented on 2015-05-01 19:14 (UTC)

Thanks PakettiAle, I changed the URL. The jemalloc problem has been fixed upstream, so I added it as a new dependency. Also changed the lua dependencies for LuaJIT (which is a replacement for Lua 5.1 and required for Neovim either way), so "lua" (Lua 5.2) is not a dependency anymore.

wixtb0t commented on 2015-04-29 09:54 (UTC)

Package's upstream URL has been changed to

fwalch commented on 2015-04-20 16:21 (UTC)

@nlehmann: See the pacaur bug report [1] (the root cause is an upstream issue, however). At the moment, looks like the best solution is to use another AUR helper or makepkg with pacman -U. [1]

nlehmann commented on 2015-04-20 14:33 (UTC)

The package is able to compile but the installation get stuck in this point ...... -- Installing: /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/autoload/ada.vim -- Installing: /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/autoload/README.txt -- Up-to-date: /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/doc/maketags.awk -- Up-to-date: /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/doc/makehtml.awk -- Up-to-date: /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/macros/ -- Generating helptags in /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/doc. -- /tmp/pacaurtmp-nlehmann/neovim-git/pkg/neovim-git/usr/share/nvim/runtime/doc already exists

fwalch commented on 2015-04-14 18:40 (UTC)

@herrecito: Yes, it needs to be fixed upstream.. disabled jemalloc in the PKGBUILD for now.

herrecito commented on 2015-04-14 18:32 (UTC)

So neovim now uses by default jemalloc, but the build fails even if jemalloc is installed: /tmp/yaourt-tmp-ruben/aur-neovim-git/src/neovim-git/src/nvim/memory.c:60: undefined reference to `je_malloc' [...]

akuntsch commented on 2015-04-07 18:00 (UTC)

@fwalch: There's another issue with makepkg -sfi not working. Might be a problem with the PKGBUILD. See

akuntsch commented on 2015-04-07 17:19 (UTC)

I opened an issue on the pacaur github ( Seems to be a pacaur bug.

fwalch commented on 2015-04-07 15:09 (UTC)

@akuntsch: Not sure.. pacaur seems to do something in a different way than packer, triggering this bug. Still, it might be a problem of Neovim. There are some problems (segfaults) with generating helptags on other distros [1]. [1]

akuntsch commented on 2015-04-07 15:00 (UTC)

@fwalch: I can, but isn't it more of a pacaur issue if it works with packer and manually?

fwalch commented on 2015-04-06 16:08 (UTC)

@akuntsch: It works fine with packer, but I'll try to track it down.. Can you open an issue on

akuntsch commented on 2015-04-06 14:00 (UTC)

Just tried again with pacaur. It pulls the latest version but still gets stuck at generating helptags. Would be good to know if it works with other AUR helpers.

akuntsch commented on 2015-04-06 13:27 (UTC)

I think pacaur doesn't pull the latest version from github, but no idea why. There was an issue on github ( concerning helptags which is fixed by now, so maybe pacaur pulls a version where it wasn't fixed yet.

olantwin commented on 2015-04-05 15:22 (UTC)

Is anyone experiencing the helptags problem with other AUR helpers? @akuntsch: Any idea what difference building with pacaur could make?

akuntsch commented on 2015-04-04 19:41 (UTC)

@olantwin: Yep. That's what I did and it worked manually. I also use pacaur but didn't think that this would be the problem at first.

olantwin commented on 2015-04-03 13:49 (UTC)

@akuntsch: Does the build succeed when you use makepkg directly? I've had the same problem, but it seems to be because of a helper (pacaur in my case). Have not been able to figure out what could be causing it.

fmoralesc commented on 2015-03-28 16:22 (UTC)

Disregard my last question, it turned out that I had a local version of unibilium at /usr/local/lib/. :/

fwalch commented on 2015-03-27 16:52 (UTC)

@Softwayer: Packages depending on vim (including plugin packages such as vim-nerdtree) won't work with Neovim even if it provides('vim'), since the runtime path and the executable name are different. If you're looking for a plugin manager, I'd recommend

Softwayer commented on 2015-03-27 16:45 (UTC)

That’s right — provide doesn’t mean replace, does it? Anyway, there are lots of plugins depending on vim, so it’s required to have it installed just to use these plugins with neovim, which is a bit ridiculous.

moyamo commented on 2015-03-27 14:05 (UTC)

@Softwayer This package doesn't replace vim (in a packaging sense). It installs itself along side the vim distribution. It is quite possible to have both vim and neovim installed.

Softwayer commented on 2015-03-27 10:00 (UTC)

Why doesn’t it provide 'vim'?

fmoralesc commented on 2015-03-27 02:31 (UTC)

The build is failing for me with these errors: Any ideas?

fwalch commented on 2015-03-20 12:58 (UTC)

Updated the dependencies to new packages ("msgpack-c" is now in "community", changed "libtermkey-git-neovim" to "libtermkey-bzr"). I think first uninstalling "neovim-git" and "msgpack-git-neovim", then re-installing "neovim-git" will avoid conflicts.

dequis commented on 2015-03-19 06:23 (UTC)

FWIW i upgraded this package and got msgpack errors (error: ‘msgpack_object_union’ has no member named ‘f64’) Had to manually upgrade msgpack-git-neovim, since i had an older version of that package which didn't have those symbols

hunterwerlla commented on 2015-03-10 19:58 (UTC)

If you are having an issue with no colors in neovim: . TL;DR - set your TERM environment variable to "xterm-256color" or run "TERM=xterm-256color nvim" I hope this helps anyone else having similar problems.

Timothee commented on 2015-03-10 08:12 (UTC)

Hello fwalch, thanks for your works. Can you add https protocol for clone repository in your PKGBUILD ? It's for pass through in bad proxy and firewall... Like this : source=("$pkgname::git://") ---> source=("$pkgname::git+") Thanks !

fwalch commented on 2015-02-28 17:28 (UTC)

Neovim currently uses a custom version of libvterm, which is packaged as libvterm-git-neovim. Adopted the package and added as dependency. Building the PKGBUILD should work now. FYI, libvterm has been added as a dependency to Neovim as a preparation for builtin terminal emulation [1]. I think I'll replace the *-git-neovim dependencies with "proper" VCS dependencies (msgpack-c-git, libtermkey-bzr, libvterm-bzr) soon. [1]

jeffutter commented on 2015-02-28 14:33 (UTC)

I have been rebuilding this almost daily. Today I am getting the following error: CMake Error at /usr/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:138 (message): Could NOT find LibVterm (missing: LIBVTERM_LIBRARY LIBVTERM_INCLUDE_DIR) Call Stack (most recent call first): /usr/share/cmake-3.1/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) cmake/FindLibVterm.cmake:45 (find_package_handle_standard_args) CMakeLists.txt:199 (find_package) I have tried installing the libvterm package from the aur. Any other ideas?

fkoehler commented on 2015-02-20 16:06 (UTC)

The normal libtermkey version from the aur works fine for me.

fwalch commented on 2015-02-17 09:37 (UTC)

It's libtermkey, not unibilium, that Neovim currently requires a special version of. If you install "libtermkey-git-neovim" (depends on "unibilium" AUR package) from AUR, you can continue to use this PKGBUILD. @fhahn: new depends: "unibilium" (as Neovim uses unibilium directly [1] as well, not only through libtermkey), "libtermkey-git-neovim" (hopefully a new libtermkey release will obsolete this package soon). "ncurses" is not a dependency anymore. The dependency on Perl can probably be removed as well, I think (only required for some scripts in /usr/share/nvim/runtime/tools, but not for Neovim itself). [1]

fmoralesc commented on 2015-02-17 03:26 (UTC)

If anyone needs to install nvim, here's a working PKGBUILD (it won't use system installed libraries):

fmoralesc commented on 2015-02-17 03:05 (UTC)

This now requires unibilium and libtermkey, but it won't build with the unibilium package from the AUR:

fwalch commented on 2015-01-06 16:47 (UTC)

@fhahn: You could add some optdepends: python2-neovim: "for Python support, see :help nvim-python" xclip: "for clipboard support (or xsel), see :help nvim-clipboard" xsel: "for clipboard support (or xclip), see :help nvim-clipboard" Only one of xclip/xsel is required; I borrowed the wording from netctl DHCP clients.

fhahn commented on 2014-12-25 19:25 (UTC)

Thanks, I have removed vim-runtime and changed the build type to RelWithDebInfo. Sorry for the delay!

fmoralesc commented on 2014-12-14 19:19 (UTC)

Since the runtime files have been readded to the repo, vim-runtime is no longer necessary, even optionaly.

fwalch commented on 2014-11-09 19:26 (UTC)

@fhahn: Would you mind changing the CMake build type to 'RelWithDebInfo' instead of 'Release'? This will enable assertions, which might be helpful for debugging while Neovim is still in alpha. It is also used in neovim's homebrew formula:

fwalch commented on 2014-10-31 20:00 (UTC)

The latest commit changes the Python support setup; instead of plugin/python_setup.vim, you'd need to use just python_setup.vim: if has('nvim') runtime! python_setup.vim endif See :help nvim-python for full instructions on Python support, btw.

fwalch commented on 2014-10-20 13:14 (UTC)

@flu: You're right.. see

fmoralesc commented on 2014-09-18 15:21 (UTC)

@fwaich: yes, it was a problem in my config in the end.

fwalch commented on 2014-09-18 08:41 (UTC)

@fmoralesc: For me, `:echo $VIMRUNTIME` shows `/usr/share/nvim/runtime` without setting anything manually.

fmoralesc commented on 2014-09-18 04:09 (UTC)

neovim has reincorporated the runtime files, so vim-runtime is not needed anymore. Also, I'm having an issue where $VIMRUNTIME doesn't point to the neovim runtime, but to `/usr/share/vim/vim74`, which is wrong (should be `/usr/share/nvim/`). I don't know if you know how to fix that in the package (I can set the variable in my .nvimrc, but that should be necessary).

fhahn commented on 2014-09-17 21:44 (UTC)

@fwalch: thanks for the hint, I've added a new lua-messagepack PKGBUILD and updated neovim's one.

fwalch commented on 2014-09-17 16:41 (UTC)

@fhahn: Neovim now uses lua-messagepack [1] instead of lua-cmsgpack (see [2]). [1] [2]

fhahn commented on 2014-09-13 21:54 (UTC)

Thanks @fwalch! The PKGBUILD now uses the msgpack-git-neovim AUR package for msgpack.

fwalch commented on 2014-09-13 11:50 (UTC)

Created msgpack-git-neovim AUR package (provides msgpack) that follows the Neovim msgpack version (see

moyamo commented on 2014-09-13 08:24 (UTC)

It seems like they are using a non-master branch of msgpack (i.e. poc/0.6). Neovim builds if you checkout poc/0.6 before building msgpack-git. msgpack-git does not build, since it clones from when it should clone from This patch should fix it, but it is only a temporary solution.

fwalch commented on 2014-09-12 22:29 (UTC)

@moyamo: I think this is because there has been a recent update to depend on an unreleased version of msgpack.. if the msgpack-git AUR package would build, using that might work.

moyamo commented on 2014-09-12 21:54 (UTC)

I am having problems building this package. It fails at src/nvim/CMakeFiles/nvim.dir/auto/msgpack_dispatch.c.o with ‘MSGPACK_OBJECT_BIN’ undeclared (first use in this function). The full error message is in the link.

Siosm commented on 2014-08-24 13:01 (UTC)

@fwalch: This looks good now. Thanks for the fix

fwalch commented on 2014-08-23 22:41 (UTC)

@timerot: Should be fixed now. @Siosm: I created this PR, but I don't have much experience with CMake installation stuff. Improvements are always welcome! :-)

timerot commented on 2014-08-23 15:23 (UTC)

A recent commit to autogenerate helptags causes an error in the install process. I worked around it by changing the PKGBUILD to sudo make install. The error wasn't particularly enlightening: -- Generating helptags. CMake Error at cmake/GenerateHelptags.cmake:14 (message): Generating helptags failed: Call Stack (most recent call first): cmake_install.cmake:40 (include)

fhahn commented on 2014-08-22 20:02 (UTC)

Thanks @mmlb, I've added `lua-bitop` as make-dependency.

mmlb commented on 2014-08-22 18:56 (UTC)

build is currently breaking due to missing `lua-bitop`.

fwalch commented on 2014-08-19 10:35 (UTC)

@sekret: Created an upstream issue for that:

fwalch commented on 2014-08-19 09:49 (UTC)

@flu: It's an upstream issue, see @sekret: PKGBUILD highlighting for vim is set in /usr/share/vim/vim74/filetype.vim. This is done by the following in vim's PKGBUILD: # patch filetype.vim for better handling of pacman related files sed -i "s/rpmsave/pacsave/;s/rpmnew/pacnew/;s/,\*\.ebuild/\0,PKGBUILD*,*.install/" \ "${pkgdir}"/usr/share/vim/${_versiondir}/filetype.vim sed -i "/find the end/,+3{s/changelog_date_entry_search/changelog_date_end_entry_search/}" \ "${pkgdir}"/usr/share/vim/${_versiondir}/ftplugin/changelog.vim

beatgammit commented on 2014-08-11 18:35 (UTC)

@sekred - fix for PKGBUILDs; apparently the default filetype for PKGBUILD is conf, but it's really a shell script. au BufNewFile,BufRead PKGBUILD set filetype=sh

sekret commented on 2014-08-09 19:13 (UTC)

I don't get syntax highlighting for PKGBUILD files! :(

fhahn commented on 2014-08-09 18:57 (UTC)

Thanks, I've updated the PKGBUILD.

commented on 2014-08-09 02:25 (UTC)

Hi, I saw a few issues in the PKGBUILD, so I made a patch. I'm never sure whether AUR users actually use the email address on their profile, so It's probably quicker to just post it here: The commit message should give a good explanation for everything, but if clarification is needed just ask. edit: reposted with as url, should be easier to read

commented on 2014-08-09 02:12 (UTC)

Hi, I saw a few issues in the PKGBUILD, so I made a patch. I'm never sure whether AUR users actually use the email address on their profile, so It's probably quicker to just post it here: The commit message should give a good explanation for everything, but if clarification is needed just ask.

commented on 2014-08-09 02:09 (UTC)

Hi, I saw a few issues in the PKGBUILD so did some work on it. Everything should have an explanation in the commit message, but if any clarification is needed feel free to ask: From 9ba2e98a12183637c737a263e0a86e2a6f3e3337 Mon Sep 17 00:00:00 2001 From: Michael Reed <> Date: Fri, 8 Aug 2014 22:03:02 -0400 Subject: [PATCH] Various PKGBUILD simplifications/cleanups: - Get rid of $_gitname in place of cloning the repo to $pkgname - Get rid of unneeded $srcdir usage; all package functions start out in $srcdir anyways - Removed manual build dir creation; cmake does this automatically & the NVim build instructions no longer recommend this. - Bracketed two variables for consistency - Removed unneeded quotes - Removed empty conflicts() - Removed gawk & sh from depends(); gawk is part of base-devel and is assumed, regardless of what namcap says (it's frequently wrong), and sh is already pulled in by multiple packages in base-devel so is not needed - Removed -DUSE_BUNDLED=Off; during building cmake complains that it is an unused flag, and diff -ur confirms no difference in pkg.tar.xz contents with and without it (besides the sha256sum of /usr/bin/nvim, which is only because the binary is built non-deterministically). - Source is now cloned directly using git as opposed to HTTPS for speed, See the following --- PKGBUILD | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) diff --git a/PKGBUILD b/PKGBUILD index 8a9f009..ef806d8 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -1,18 +1,16 @@ # Maintainer: Florian Hahn <> pkgname=neovim-git -_gitname=neovim pkgdesc="Vim's rebirth for the 21st century" license=('custom:neovim') -pkgver=0.r1385.5f42ba6 +pkgver=0.r1426.19f44fd pkgrel=1 -depends=('libuv' 'ncurses' 'msgpack' 'perl' 'gawk' 'sh') +depends=('libuv' 'ncurses' 'msgpack' 'perl') makedepends=('cmake' 'git' 'unzip' 'lua-lpeg' 'luajit' 'lua' 'lua-cmsgpack') -conflicts=('') provides=('neovim') arch=('i686' 'x86_64') url=('') -source=('git+') +source=("$pkgname::git://") md5sums=('SKIP') install=neovim-git.install optdepends=( @@ -20,22 +18,21 @@ optdepends=( ) pkgver() { - cd "${srcdir}/${_gitname}" + cd "${pkgname}" printf "0.r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)" } build() { - cd "${srcdir}/${_gitname}" - mkdir build && cd build - cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DUSE_BUNDLED=Off \ - -DCMAKE_INSTALL_PREFIX="/usr" .. + cd "${pkgname}" + cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release \ + -DCMAKE_INSTALL_PREFIX=/usr make } package() { - cd "${srcdir}/${_gitname}/build" + cd "${pkgname}" DESTDIR="${pkgdir}" make install - install -Dm644 "${srcdir}/${_gitname}/LICENSE" "$pkgdir/usr/share/licenses/$pkgname/LICENSE" + install -Dm644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE" } # vim:set sw=2 sts=2 et: -- 2.0.4

Runiq commented on 2014-08-07 14:14 (UTC)

Hey, I've uploaded a package for the Neovim Python client [1] for those of you who'd like to try out the Python plugin support. Don't forget to add the config snippet [2] to your (n)vimrc file (and use "python2" instead of "python", obviously). [1] [2],-clipboard-integration-and-other-service-providers-through-msgpack-RPC-channels

fhahn commented on 2014-08-05 21:17 (UTC)

The PKGBUILD should be fixed now. Now CMAKE_INSTALL_PREFIX=/usr and DESTDIR="${pkgdir}" are used.

Anthony25 commented on 2014-08-05 08:26 (UTC)

Hello, I have the same error as sekret, with the line "syntax on" in my .nvimrc.

sekret commented on 2014-08-04 16:20 (UTC)

Forgot to say, with previous builds this didn't show up and neovim worked fine, including syntax highlighting.

sekret commented on 2014-08-04 16:18 (UTC)

Damnit, now there's something else: $ nvim Error detected while processing /home/sekret/.nvimrc: line 1: E484: Can't open file /tmp/neovim-git/pkg/neovim-git/usr/share/nvim/syntax/syntax.vim line 5: E484: Can't open file /tmp/neovim-git/pkg/neovim-git/usr/share/nvim/syntax/syntax.vim (/tmp/neovim-git is where I stored the PKGBUILD, so /tmp/neovim-git/pkg is $pkgdir) Something like this never happend to me, I don't know what causes this.

fhahn commented on 2014-08-04 14:47 (UTC)

Thanks, I've replaced lpeg with lua-lpeg.

sekret commented on 2014-08-04 13:13 (UTC)

fwalch is totally right, I just built it with lua-lpeg. This AUR package should be removed! I already filed a request and updated the other package which depends on lpeg.

fwalch commented on 2014-08-04 08:14 (UTC)

Shouldn't it be possible to use lua-lpeg (from extra) instead of lpeg (from AUR)?

fhahn commented on 2014-08-04 08:01 (UTC)

@sekret: Thanks, I've updated the install path and added msgpack, perl and gwak to the dependencies. As @nNa mentioned, the package now contains the complete vim runtime. I'll probably look into moving the runtime files in a neovim-runtime package.

KarboniteKream commented on 2014-08-04 07:56 (UTC)

@sekret: Neovim now contains the whole vim runtime (help files).

sekret commented on 2014-08-04 07:28 (UTC)

Ok, msgpack is definitely a dependency, nvim won't launch without it. Additionally, in the build function, you need to change the install prefix to -DCMAKE_INSTALL_PREFIX="${pkgdir}/usr" otherwise stuff will get installed into /share/... which is obviously wrong. After that, namcap shows this output neovim-git W: Referenced library 'csh' is an uninstalled dependency neovim-git W: Referenced library 'nawk' is an uninstalled dependency neovim-git W: Dependency perl detected but optional (programs ['perl'] needed in scripts ['usr/share/nvim/runtime/tools/', 'usr/share/nvim/runtime/tools/', 'usr/share/nvim/runtime/tools/', 'usr/share/nvim/runtime/tools/', 'usr/share/nvim/runtime/doc/']) neovim-git W: Dependency bash detected but optional (programs ['sh'] needed in scripts ['usr/share/nvim/runtime/tools/vimm', 'usr/share/nvim/runtime/tools/', 'usr/share/nvim/runtime/tools/ref', 'usr/share/nvim/runtime/macros/']) which is ok I think, although I'm not sure why the first 2 lines appear, possibly additional optional dependencies, which aren't in the repos? Thanks man, now it builds a lot faster. Strange though that the package is a lot bigger now.

fhahn commented on 2014-08-03 23:34 (UTC)

I've updated to PKGBUILD to use USE_BUNDLED=Off, set the build type to release and use `make install` for installing all files, thanks for your hints. All lua dependencies seem to be build-dependencies. I've created a new PKGBUILD for lua-cmsgpack. The PKGBUILD contains both luajit and lua at the moment, because the cmake script checks if luajit is installed but I'm not sure how to build lua-cmsgpack for luajit. I would appreciate any feedback to these changes!

sekret commented on 2014-08-01 10:40 (UTC)

That would be nice, thanks!

fwalch commented on 2014-07-31 17:11 (UTC)

@fhahn: Tried to build it with USE_BUNDLED_DEPS=OFF, and at least for lua-cmsgpack there's currently no Arch package. Also noticed that the vim-runtime files are now included in the neovim repo and will be installed to $CMAKE_INSTALL_PREFIX/share/nvim/runtime when running `make install`. So maybe you can use -DCMAKE_INSTALL_PREFIX=${pkgdir}?

fhahn commented on 2014-07-31 08:36 (UTC)

It seems like an USE_BUNDLED option was introduced to use system dependencies. I'll look into using Arch Linux packages for neovim's dependencies over the weekend.

sekret commented on 2014-07-29 16:39 (UTC)

Isn't it possible to use those external tools like luajit, luarocks etc, which are being downloaded and built during the build process, by including them as a dependency?

KenjiTakahashi commented on 2014-07-28 19:33 (UTC)

neovim takes completely different route on providing plugins interface, look up on,-clipboard-integration-and-other-service-providers-through-msgpack-RPC-channels for some insight. I don't know about lua, it might be special, because AFAIK they plan to use it as vimscript replacement at some point.

Hspak commented on 2014-07-07 05:38 (UTC)

What is the neovim replacement for things like --enable-pythoninterp and --enable-luainterp?

fhahn commented on 2014-07-03 19:27 (UTC)

Thanks, I've update THE PKGBUILD. I've changed the license, but not to Apache though. The neovim code base still contains a lot of code under the old vim license, only the new additions are licensed under Apache, so setting the license to Apache does not seem quite right to me, although I'm no expert on licensing issues.

commented on 2014-06-27 09:44 (UTC)

1. vim-license.txt has been moved to LICENSE 2. License has changed from custom:vim to Apache

z33ky commented on 2014-06-24 08:57 (UTC)

I managed to build it without bundled dependencies by using this patch: You also need to set the environment variable USE_BUNDLED_DEPS=OFF. The bug is reported upstream, but it seems to be a low priority: A lua-cmsgpack package is currently missing from the Arch repos though.

fhahn commented on 2014-05-18 16:17 (UTC)

The wiki page about PKGBUILDs [1] seems very clear about this: "Members of "base-devel" should not be included in makedepends arrays." [1]

aignas commented on 2014-05-17 22:14 (UTC)

libtool is needed for building, but it is absent for makedepends. I remember that in wiki it is written to install base-devel group before building AUR packages, but I think that if this needs libtool for building, it should be there in makedepends.

fhahn commented on 2014-04-30 11:03 (UTC)

@lilydjwg: I don't think this is possible with the current neovim build system. The current build script does not support using system dependencies, but fetches and builds them separately ( I guess this approach is easier at the moment, because they rely on fairly recent version which is a problem for some distributions. That said, I guess a patch for upstream should be doable for anybody with good CMAKE knowledge.

lilydjwg commented on 2014-04-30 03:20 (UTC)

I see it tries to download libuv and luajit sources when building. Is it possible to depend on the packages already installed instead of duplicating them?

petelewis commented on 2014-04-27 19:04 (UTC)

Excellent - working for me now. Thanks!

fhahn commented on 2014-04-27 18:13 (UTC)

Thanks @nNa, I've added unzip to the makedeps and removed luajit and luarocks.

KarboniteKream commented on 2014-04-27 15:55 (UTC)

Could you install 'unzip' and then try again? The solution can be found here.

fhahn commented on 2014-04-27 15:37 (UTC)

I have the same problem without luarocks, but I'm not why, it does not seem to be related to luarocks.

petelewis commented on 2014-04-27 15:34 (UTC)

Okay, just tried on another machine. Without luarocks, I get this: <snip> Scanning dependencies of target moonscript make[4]: Leaving directory '/build/neovim-git/src/neovim/.deps/build/third-party' make[4]: Entering directory '/build/neovim-git/src/neovim/.deps/build/third-party' [ 91%] Generating /build/neovim-git/src/neovim/.deps/usr/bin/moon, /build/neovim-git/src/neovim/.deps/usr/bin/moonc Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Warning: Failed searching manifest: Failed loading manifest: Failed extracting manifest file Error: No results matching query were found. CMakeFiles/moonscript.dir/build.make:55: recipe for target '/build/neovim-git/src/neovim/.deps/usr/bin/moon' failed make[4]: *** [/build/neovim-git/src/neovim/.deps/usr/bin/moon] Error 1 make[4]: Leaving directory '/build/neovim-git/src/neovim/.deps/build/third-party' CMakeFiles/Makefile2:261: recipe for target 'CMakeFiles/moonscript.dir/all' failed make[3]: *** [CMakeFiles/moonscript.dir/all] Error 2 make[3]: Leaving directory '/build/neovim-git/src/neovim/.deps/build/third-party' Makefile:75: recipe for target 'all' failed make[2]: *** [all] Error 2 make[2]: Leaving directory '/build/neovim-git/src/neovim/.deps/build/third-party' Makefile:54: recipe for target 'deps' failed make[1]: *** [deps] Error 2 make[1]: Leaving directory '/build/neovim-git/src/neovim' Makefile:45: recipe for target 'cmake' failed make: *** [cmake] Error 2 But with luarocks as a makedepend, it works. It does seem to get a bundled luarocks as part of the build process in any case, but doesn't seem to be working. I'm afraid I know nothing about luarocks though. Can provide a full log if helpful. All building done in clean chroots.

petelewis commented on 2014-04-27 15:20 (UTC)

@nNa weird. I'll try to reproduce the error I got.

KarboniteKream commented on 2014-04-27 12:00 (UTC)

@petelewis: I was able to build neovim without luarocks. And as far as I know, with the recent change in PKGBUILD, luarocks is downloaded and compiled automatically, so there should be no need for a separate makedepend.

petelewis commented on 2014-04-27 09:35 (UTC)

Great, thanks!

fhahn commented on 2014-04-27 09:23 (UTC)

I've updated the PKBUILD, thanks for your feedback dtzWill & petelewis

petelewis commented on 2014-04-27 09:03 (UTC)

It also seems that once installed, it expects to find things in /usr/local rather than /usr. E.g. "syntax on" in .nvimrc gives me this: E484: Can't open file /usr/local/share/vim/syntax/syntax.vim Is there a build-time flag which should be set to make nvim look in /usr instead?

petelewis commented on 2014-04-27 09:00 (UTC)

I had to add luarocks as a dep (possibly just a makedep?) to build this. Thanks.

dtzWill commented on 2014-04-22 17:14 (UTC)

This package fails to build when 'ninja' is installed on the system. 'make cmake' generates ninja build files if possible, which causes the later attempt to 'cd build' and 'make' to fail since no Makefiles were generated. Easiest solution is to simply remove 'cd build' from the PKGBUILD entirely, as 'make' in the root directory defaults to invoking the proper build tool on the build directory. Alternatively you could choose to specify the build tool if desired, but that seems more fragile.

philpirj commented on 2014-04-21 12:50 (UTC)

Any idea what's wrong with yanking to/pasting from X clipboard? I have autocutsel installed, and this works perfectly fine with mainline vim: set clipboard=unnamedplus But not for neovim. From :help clipboard-unnamedplus {only in GUI versions or when the +xterm_clipboard Cannot find xterm_clipboard anywhere in neovim's source.

KarboniteKream commented on 2014-04-15 21:54 (UTC)

I successfully built neovim with system libraries, but it's probably better to fetch them at build, since lua-cmsgpack isn't available on AUR without installing luarocks.

KarboniteKream commented on 2014-04-15 21:52 (UTC)

I got the same issue, but I wasn't able to reproduce it later. I've submitted a pull request on GitHub to fix this.

fhahn commented on 2014-04-15 21:26 (UTC)

I looked into the build issues. Neovim needs msgpack, lua51-lpeg and cmsgpack to build, but it seems like the build script does not take system libraries into account. I've updated the PKGBUILD to use `make cmake` which fetches and builds the dependencies (using luarocks for the lua stuff). But there seems to be a build error : pkgbuilds/neovim/src/neovim/src/term.c:3452:48: error: ‘row_char’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (j == 1 && tp[i] == 'R' && row_char == '2' && col >= 2) { ^

fkoehler commented on 2014-04-15 20:14 (UTC)

msgpack lua51-lpeg and cmsgpack ( not in the AUR yet) are required

commented on 2014-04-15 10:17 (UTC)

It seems msgpack is another dependency needed to build neovim:

cryptix commented on 2014-04-13 09:47 (UTC)

deleted my last comments as they were wrong (the pkgs i listed should be build build by the neovims cmake itself)

commented on 2014-04-09 21:16 (UTC)

@EvertVP I also got the same error the other day. Pretty sure it's because the official libuv package is now at 0.11.23, and neovim's dependency is still tied to 0.11.22 (can see here As @wget said, the issue is upstream, just have to wait until they update the dependency.

wget commented on 2014-04-09 14:23 (UTC)

@EverVP, please report the error upstream. Btw, if you check the build status at you see that the code doesn't even compile.

commented on 2014-04-09 14:16 (UTC)

I'm getting this error during compilation:

fhahn commented on 2014-03-22 15:39 (UTC)

Yes, thanks for the hint. I've added luajit as build dependency for now.

mvdnes commented on 2014-03-22 14:28 (UTC)

This package now seems to have a (build?)dependency of luajit

bhedrich commented on 2014-03-03 11:00 (UTC)

@venvd: this issue:

ivenvd commented on 2014-03-03 09:57 (UTC)

@eyenx, @Gregoire, @fhahn Solved. Remove "-D_FORTIFY_SOURCE=2" from CFLAGS and CXXFLAGS in /etc/makepkg.conf.

eyenx commented on 2014-03-02 17:49 (UTC)

@ivendvd, @Gregoire, @fhahn I get the same segfault. Building neovim from the git source as described under works for me. The PKGBUILD seems fine. I don't get where the problem might be.

fhahn commented on 2014-02-27 22:04 (UTC)

@ivendvd, @Gregoire I don't think your problem has something to do with the PKGBUILD. It looks like an segmentation fault, which could be an upstream problem.

ivenvd commented on 2014-02-26 08:05 (UTC)

I have the same error as @Gregoire do.

Gregoire commented on 2014-02-25 17:35 (UTC)

I had the same error with previous AUR and as it seems you don't have the problem maybe someone could help me : Thank you very much !

fhahn commented on 2014-02-25 17:19 (UTC)

I've added a message stating that the executable was renamed to `nvim` (I think I'm going to remove this message in the future again) and added vim-runtime as optional dependency.

mytbk commented on 2014-02-25 13:46 (UTC)

The vim-runtime package has a lot of .vim files that neovim can use, and I think it can be an optional dependency.

colinkeenan commented on 2014-02-25 03:29 (UTC)

I just heard about this when I decided to browse github and then figured it would probably already be in AUR. It took me a moment to figure out the executable was named nvim though. It seems like a good idea to let people know that using a post install message the way google-chrome does.

Barthalion commented on 2014-02-25 00:21 (UTC)

thiderman: both are in the base-devel group, which you should have installed before playing with AUR.

fhahn commented on 2014-02-24 23:05 (UTC)

thiderman, could you post the error messages without libtool and automake installed? I tried it without and it worked for me. There was another error with this PKGBUILd though. Upstream, the executable got renamed once again. I've updated the PKGBUILD to use nvim as name for the installed executable instead of neovim, to be closer to upstream.

thiderman commented on 2014-02-24 22:47 (UTC)

libtool and automake are also required as dependencies.

devm33 commented on 2014-02-24 18:07 (UTC)

The build error below occurres on my system when performing makepkg -s install: cannot stat ‘/home/devm33/pkgbuild/neovim-git/src/neovim/build/src/vim’: No such file or directory The following patch will fix it: --- PKGBUILD.backup 2014-02-25 03:03:04.715858763 +0900 +++ PKGBUILD 2014-02-25 03:03:12.535858948 +0900 @@ -28,7 +28,7 @@ } package() { - install -Dm755 "${srcdir}/${_gitname}/build/src/vim" "${pkgdir}/usr/bin/neovim" + install -Dm755 "${srcdir}/${_gitname}/build/bin/vim" "${pkgdir}/usr/bin/neovim" install -Dm644 "${srcdir}/${_gitname}/vim-license.txt" "$pkgdir/usr/share/licenses/$pkgname/LICENSE" }

Barthalion commented on 2014-02-24 17:04 (UTC)

As I said… It should hit your mirrors soon, so neovim-git can be switched back to stable libuv.

Barthalion commented on 2014-02-24 17:01 (UTC)

Probably mtorromeo forgot to run db-update.

Barthalion commented on 2014-02-24 17:01 (UTC)

Libuv has been theoretically moved to [community], no idea why it is not in the repository yet.

fhahn commented on 2014-02-24 16:50 (UTC)

Thanks for the heads up, there were a couple of different libuv PKGBUILDs floating around and I think they got consolidated now.

diegoviola commented on 2014-02-24 10:29 (UTC)

it should be "21st century".

fhahn commented on 2014-02-22 16:09 (UTC)

I've added the LICENSE file.

commented on 2014-02-22 12:26 (UTC)

According to the packaging guidelines a non-standard license should be included with the package. Adding the following in install() should suffice: install -Dm644 "$srcdir/$pkgname/vim-license.txt" "$pkgdir/usr/share/licenses/$pkgname/LICENSE"

fhahn commented on 2014-02-21 23:24 (UTC)

I've updated the PKGBUILD, "cmake -DCMAKE_INSTALL_PREFIX=/usr .." is now used, thanks.

RunningDroid commented on 2014-02-21 21:40 (UTC)

Could you change "cmake .." to "cmake -DCMAKE_INSTALL_PREFIX=/usr .." so it looks in /usr/share/vim for vimfiles instead of /usr/local/share/vim

Jonhoo commented on 2014-02-21 21:35 (UTC)

`cmake ..` should be replaced with `cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..` to make neovim fall back to files in /usr/share/vim instead of /usr/local/share/vim.