После обновления на Debian 13 и обновления плагинов для neovim столкнулся с неприятной ошибкой в популярном плагине для автокомплита nvim-cmp. Ошибка происходила при вводе любых данных в режиме вставки. Трассировка выдавала что-то на подобии:Обнаружена ошибка при обработке TextChangedI Автокоманды для "*":
Error executing lua callback: /usr/local/share/nvim/runtime/lua/vim/lspclient.lua:643: bufnr: expected number, got function
stack traceback:
[C]: in function 'error'
vim/shared.lua: in function 'validate'
/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:643: in function 'resolve_bufnr'
...++ Решение
В Debian 13 находится neovim версии 0.10.4. Дополнение nvim-cmp по какой-то причине требует для работы более новую версию neovim. В частности, проблема исчезла с версией 0.11.3.
++ Установка более свежей версии neovim
Существует много способов установки более свежих пакетов в Debian, включая подключение репозитория backports и использование самодостаточных пакетов типа appimage или flatpack. Ниже будет описан более сложный, но универсальный и контролируемый способ - сборка необходимого deb пакета вручную. Руководство по сборке и установки рассчитано на пользователей которые никогда раньше этим не занимались.
1. Клонирование нужной версии из официального репозитория:
git clone --depth=1 --recurse-submodules --branch=v0.11.3 https://github.com/neovim/neovim.git
--depth=1 позволяет не скачивать всю историю изменений ветки
--recurse-submodules заставляет скачать все необходимые для сборки модули из других репозиториев github
--branch=v0.11.3 указывает необходимую для скачивания ветку, в частности используем ветку помеченую через tag v0.11.32. Компиляция программы
Переходим в директорию neovim и начинаем сборку:cd neovim
make CMAKE_INSTALL_PREFIX=/usr/local/ -j14prefix позволяет задать директорию для дальнейшей установки пакета отличной от директории по умолчанию. Пакеты собранные вручную лучше располfгать по пути /usr/local/
Флаг -j14 определяет количество потоков, которые будут использоваться для параллельной сборки. Рекомендуется использовать не более чем количество логических ядер процессора + 1.3. Установка программы в локальную директорию
После окончания сборки создадим временную директорию nvim-v0.11.3 и установим в неё скомпилированный neovim:
mkdir nvim-v0.11.3
make DESTDIR=$(pwd)/nvim-v0.11.3 installDESTDIR указывает директорию, которая будет использована вместо корня файловой системы. $(pwd) дописывает абсолютный путь к текущей директории. После этого шага директория nvim-v0.11.3 должна содержать папку usr содержимым, которое пакетный менеджер должен добавить в текущую систему.
На данном этапе программа уже может работать и не вызывать ошибок. Проверить это выполнив команду:
nvim-v0.11.3/usr/local/bin/nvim
4. Подготовка информации для превращения созданной директории в deb пакет
Для формирования пакета в директории nvim-v0.11.3 необходимо создать еще одну папку DEBIAN и добавить в ней два файла.
Файл с описанием пакета nvim-v0.11.3/DEBIAN/control со следующим содержимым:Package: neovim
Version: 0.11.3
Architecture: amd64
Section: editors, devel
Priority: standard
Maintainer: Ваше Имя {your@mail.ru>
Description: Code editorМожно изменить сведения в поле Maintainer и отредактировать поле Architecture в соответствии с архитектурой вашего процессора (актуально для всяких SBC на ARM и RISC-V)
Устанавливаемые программы могут использовать разделяемые библиотеки (shared object). Данные библиотеки содержат общий для разных программ код в виде скомпилированных функций. Для того, чтобы эти библиотеки были доступны из места их установки часто необходимо указать системе о необходимости обновить соответствующую информацию. Сделать это можно в специальном скрипте, выполняемом после установки. Содержимое файла nvim-v0.11.3/DEBIAN/postinst должно выглядеть так:
#!/usr/bin/env bash
ldconfig && echo "Кэш разделяемых библиотек обновлен"Данный скрипт необходимо сделать исполняемым. Сделать это можно консольной командой:
chmod +x nvim-v0.11.3/DEBIAN/postinst
5. Сборка deb пакета
Теперь полученную директорию можно превратить в deb пакет. Для этого необходимо выполнить команду:
dpkg-deb --build --root-owner-group nvim-v0.11.3
После успешного выполнения команды в текущей директории должен появиться файл nvim-v0.11.3.deb. Пакет можно скопировать на флешку либо распростронять любым другим способом, чтобы не собирать его снова на других компьютерах.
6. Установка deb пакета
Установить пакет можно с помощью менеджера apt:
sudo apt install ./nvim-v0.11.3.deb
При помощи apt пакет можно будет удалить. При необходимости установить более свежую версию nvim apt автоматически удалит предыдущую.
После установки nvim должен запускаться и нормально работать с указанным плагином.
URL:
Обсуждается: http://www.opennet.dev/tips/info/3278.shtml
> чтобы не собирать его сноваТогда-уж, опишите как сделать свой репо и не возиться с флешками
И как настроить отдельный сервер под репо. И как сделать его отказоустойчивым, чтобы не возиться с восстановлением диска. Да, мой хороший?
Зачем? Для этого можно запустить виртуальную машину.
А так, автор собрал пакет, так почему-бы и репо не запустить? И это про удобство.
>виртуальную машинуГосподи боже. И бекапить её Стейт как сумасшедший.
> Тогда-уж, опишите как сделать свой репо и не возиться с флешками
apt-get install aptly
aptly repo create -distribution=stable -component=main myrepo
aptly repo add myrepo mypackage.deb
aptly publish repo -skip-signing myrepo
aptly serve -listen=:8080 &
PS: вместо последней команды можете просто настроить nginx на директорию publiс у aptly -- получите то же самое
оооо, деб-пакеты из 96го года, ручной сборки.
кому чего не нра, всегда могут "./configure ; make ; make install"
в /usr/local или даже в ~/.local, как это делаю я например.
И если локалхостов хотя бы два...(да и вспомнить потом через пару лет что откуда взялось и как теперь это переносить на новую систему тоже интересное приключение)
> вспомнить потом через пару летДля этого все эти "configure && make && make install" надо делать не руками, а положить в скрипт /usr/local/src/neovim.sh и запускать его.
> И если локалхостов хотя бы два...
Ну лаааадно... вместо "make install" делайте "make DESTDIR=/tmp/neovim install", запаковывайте /tmp/neovim в архив и распаковывайте где надо... ну это если оба ваших локалхоста на одной версии одного дистрибутива...
Я так с 2005 по 2018 на lfs сидел, раз в год (в новогодние каникулы) пересобирая всю систему. Правда, благодаря внедрению всяких растов, постоянным миграциям между сборочными системами и прочему бардаку это стало бессмысленно, а постоянные правки скриптов начали занимать слишком много времени. Так что вернулся на слаку. А теперь, вероятно, перейду на диван, так как идеальный для меня интервал релизов - раз в пару лет, а у слаки есть только два варианта - стабильный (раз в 8 лет) и карент (раз в пару дней).
> Для этого все эти "configure && make && make install" надо делать не руками,ты феноменальный...
Эта операция делается в таких вот случаях - ОДИН раз. Причем - вполне возможно - итеративно, с первой попытки ты ошибешься с аргументами configure - забудешь нужную фичу или включишь ненужную, мэйк сфейлится потому что ты забыл про какую-то из зависимостей, конфиг уедет в local а нужен в /etc. И это СОВЕРШЕННО незачем автоматизировать.
И при выходе следующей версии придется переделывать потому что появилась новая зависимость и у сonfigure новый аргумент.
Поэтому - именно руками, пока не получится что-то съедобное.> Ну лаааадно... вместо "make install" делайте "make DESTDIR=/tmp/neovim install",
> запаковывайте /tmp/neovim в архив и распаковывайте где надо...А как теперь - удалить, не оставив мусора и не зацепив ничего чужого? Как выяснить через два года, какая у тебя версия?
А вот dpkg за тебя все это помнит и автоматизирует. Эту операцию - автоматизировать - стоит. Тем более что, как видим, это один файлик на пять строчек.> Я так с 2005 по 2018 на lfs сидел
ну что с подобных взять...
необучаемые же ж. Наглядное доказательство не то что бесполезности, а явного вреда lfs.
Вы учитесь выполнять чужие скрипты без понимания откуда они взялись и зачем вообще нужны.
> И это СОВЕРШЕННО незачем автоматизировать.И при выходе следующей версии придется переделывать потому что появилась новая зависимость и у сonfigure новый аргумент.
Те, кому "СОВЕРШЕННО незачем автоматизировать", через два года будут заново вспоминать все опции и хаки после установки, необходимые для того, чтобы установленный пакет заработал. Те, кто это "автоматизирует", просто запустят скрипт, посмотрят где упало, добавят нужную опцию, и запустят заново.
> вот dpkg за тебя все это помнит и автоматизирует
Поэтому в конце статьи и создаётся деб-пакет.
> доказательство не то что бесполезности, а явного вреда lfs
Можете уточнить, что именно является этим доказательством?
> Вы учитесь выполнять чужие скрипты без понимания
Вы это поняли из того, что я написал вам, что создавал СВОИ скрипты и ОБЪЯСНИЛ зачем? И для "удалить, не оставив мусора и не зацепив ничего чужого[...] выяснить через два года, какая у тебя версия" у меня тоже была пара скриптов в сумме строк на 50. Конкретно для этих целей у меня не было нужды использовать монстров типа dpkg/rpm.
> Те, кому "СОВЕРШЕННО незачем автоматизировать", через два года будут заново вспоминать
> все опции и хаки после установкия тебе открою страшную тайну, они лежат в config.status .
Правда, скорее всего, вспоминать их будет незачем, потому что все равно ты забыл зачем они были нужны - и следующую версию соберешь с другими, показавшимися тебе оптимальными в этот раз. Тем более что один из старых стал неактуальным но появились два новых. Или тебе вообще стал больше не интересен неовим и его приблуды.> Вы это поняли из того, что я написал вам, что создавал СВОИ скрипты и ОБЪЯСНИЛ зачем?
нет, ты не объяснил зачем. Ты просто продолжаешь повторять заученную безумную мантру.
Нет никакого смысла сохранять в виде скрипта то что ты сделал (_уже_cделал_) руками и не собираешься повторять регулярно. Есть смысл сохранять где-то документацию, но до этого ты не дорастешь никогда.> Конкретно для этих целей у меня не было нужды использовать монстров типа dpkg/rpm.
вон там шесть строчек конфига для dpkg. Для конкретно этих целей. Из них нужная - одна, с именем пакета.
Монстр, ога.Монстр начинается когда ты таки захочешь сохранять в нем еще и скрипты. (делают это обычно те и в тех случаях, когда таки собираются регулярно ЭТО автоматически пересобирать, например потому что новая версия не отличающаяся от старой но с закрытой уязвимостью раз в три дня выходит). В этом плане rpm будет сильно попроще и поудобнее, поскольку конфиг останется тем же, просто добавляются новые секции, да и те существенно проще и понятнее.
> я тебе открою страшную тайну, они лежат в config.status .Я вам открою страшную тайну. Вменяемые сборщики пакетов не хранят для каждого пакета два года config.status и весь сконфигурированный гигабайтный каталог вместе с ним, а удаляют начисто сборочную директорию самое позднее как только пакет зарелизился. Чтобы сборка всегда шла начисто и была хоть какая-то гарантия, что пакет соберётся где-то кроме машины мейнтейнера.
> ты забыл зачем они были нужны - и следующую версию соберешь с другими
Ещё раз. Я с 2005 по 2018 собирал лфс. Кому-нибудь другому расскажите, соберу ли я следующую версию с теми же флагами, или при каждой сборке буду подыскивать другие с нуля. Наверное, серьёзные мейнтейнеры мейнтейнят максимум 10 пакетов и у них куча свободного времени каждый раз ковыряться в этих опциях заново. Вы из них, раз заявляете такое? Без подколок спрашиваю, чтобы читающим этот тред потом был понятен бэкграунд тех, кто высказывает совё мнение, а свой бэкграунд я описал.
> Нет никакого смысла сохранять в виде скрипта то что ты сделал (_уже_cделал_) руками и не собираешься повторять регулярно.
Я - собираюсь. Поправлю номерок версии и попробую собрать тем же скриптом. Если получится собрать и всё будет работать, тратить день на изучение ченджлога в поисках новых опций для configure я не буду. Если сломается сборка или работа, тогда и погляжу на все изменения и, может быть, добавлю опций.
> Есть смысл сохранять где-то документацию, но до этого ты не дорастешь никогда.
Не дорасту, да. У меня есть скрипт, в котором УЖЕ написано, что именно и как именно я собирал в предыдущей версии. В истории репозитория есть варианты сприпта для всех версий, которые я собирал. Я никогда не дорасту до того, чтобы дублировать этот скрипт на человеческом языке в отдельное место, где его никто не будет читать (потому что есть рабочий скрипт) и где мне надо будет поддерживать его актуальность параллельно с правками скрипта.
> Монстр, ога.
Предлагаю вам начать читать, на что отвечаете. Монстром я назвал сам dpkg, а не пятистрочник для него.
> новая версия не отличающаяся от старой но с закрытой уязвимостью раз в три дня выходит
И это тоже, да. Как я выше и написал.
> В этом плане rpm будет сильно попроще и поудобнее
Не очень понимаю вас. Соглашусь, что собрать rpm-пакет проще, чем deb-пакет. Но вы к чему клоните? Предлагаете человеку с 13 дебиана перейти на что-нибудь на базе rpm только для того, чтобы упростить сборку своих пакетов?
>> я тебе открою страшную тайну, они лежат в config.status .
> Я вам открою страшную тайну. Вменяемые сборщики пакетов не хранят для каждогоэто - невменяемые.
> пакета два года config.status и весь сконфигурированный гигабайтный каталог вместе с
> ним, а удаляют начисто сборочную директорию самое позднее как только пакет
> зарелизился. Чтобы сборка всегда шла начисто и была хоть какая-то гарантия,
> что пакет соберётся где-то кроме машины мейнтейнера.ну вот опять повторение мантр вместо включения мозга. Чего тут вменяемого-то?
Человек собрал _себе_ пакет. Ему совершенно ненужно ни удалять его исходники (нет там никаких гигабайт, а если б были то и тем более ненужно - завтра захочется собрать чуть по другому или выйдет патч на одну строчку, и будешь ты часами ждать сборки с нуля, вместо одного файлика исходника), особенно если там и правда было что-то посложнее configure без аргументов, ни "гарантий".
А ты снова выполняешь религиозный ритуал, не понимая его смысла.
>> ты забыл зачем они были нужны - и следующую версию соберешь с другими
> Ещё раз. Я с 2005 по 2018 собирал лфс. Кому-нибудь другому расскажите,да, я вижу неизгладимый след оставленный этим ненужным ненужно в твоей голове.
Помимо "сириозных майнтейнеров", внезапно, существуют люди, поддерживающие свои системы.
Иногда сильно не одну.И им совершенно незачем бездумно вполнять ритуалы, не имеющие для них ни малейшего смысла.
>> Нет никакого смысла сохранять в виде скрипта то что ты сделал (_уже_cделал_) руками
>> и не собираешься повторять регулярно.
> Я - собираюсь. Поправлю номерок версии и попробую собрать тем же скриптом.ну то есть ритуал ради ритуала.
>> Есть смысл сохранять где-то документацию, но до этого ты не дорастешь никогда.
> Не дорасту, да. У меня есть скрипт, в котором УЖЕ написано, что
> именно и как именно я собирал в предыдущей версии. В историиА надо было - зачем, и почему именно так. Потому что когда ты к нему вернешься, может оказаться что ситуация изменилась. Софт поменялся, или у тебя другие запросы. А ты уже и забыл, что тут и для чего.
>> Монстр, ога.
> Предлагаю вам начать читать, на что отвечаете. Монстром я назвал сам dpkg,намеков ты не понимаешь. Чушь ты написал, только и всего.
>> В этом плане rpm будет сильно попроще и поудобнее
> Не очень понимаю вас. Соглашусь, что собрать rpm-пакет проще, чем deb-пакет. НоТоже нет. Собрать по приведенной инструкции deb проще чем минимальный rpm, в том не очень хорошо именно с таким применением, когда софт уже собран, и все что мы хотим от пакетного менеджера - упростить себе на будущее апгрейд/деинсталл/контроль что тут понаустановлено.
Не то чтоб намного, но чуть больше возни, пятью строчками не отделаешься, и со сборкой в модных современных есть фокусы.
Вот если нужно уже в автоматизированную сборку (как раз как ты любишь, цифирку неглядя поменял и оно как-то там само соберется) - там с rpm обычно проще и быстрее. Но такое нужно крайне редко, если ты не работаешь за деньги собирателем пакетов.> вы к чему клоните? Предлагаете человеку с 13 дебиана перейти на
> что-нибудь на базе rpm только для того, чтобы упростить сборку своих
> пакетов?вообще-то "как-то поставить один раз - любой из нас может даже самый уродливый и кривой дистрибутив"(с).
Поэтому да, если тебе надо поддерживать сложные системы и частью этой поддержки является эпизодическая сборка чего-то, чего там нет или не так собрано - вполне разумно выбирать дистрибутив где именно это делается удобно, а не страдать.
> И если локалхостов хотя бы два...преждевременная оптимизация, все дела.
> (да и вспомнить потом через пару лет что откуда взялось
через пару лет меня там не будет.
а после меня хоть потоп.
у автора заметки несколько другие цели, а тебе незачем и deb собирать - пусть после тебя кто-то другой гадает, чего опять nvim поломалося.
> оооо, деб-пакеты из 96го года, ручной сборки.Автоматической сборки примеры в студию!
>> оооо, деб-пакеты из 96го года, ручной сборки.
> Автоматической сборки примеры в студию!автоматическая - это dpkg-build c rules/debian, чего в ней интересного-то.
А тут кто-то еще помнит как руками собирают, то и удивительно.
Зачем эти страдания, если последняя версия есть в ветке experimental или на гитхабе от разработчиков: https://github.com/neovim/neovim-releases/releases
> Зачем эти страдания, если последняя версия есть <...> на гитхабе от разработчиков: https://github.com/neovim/neovim-releases/releasesЧеловек учится.