Created attachment 8011 [details]
GPG-ключ

Created attachment 8012 [details]
SSH-ключ

Ментор согласен.

T/J/S -> 2.0.

Кандидат готов перейти к этапу 2.

Кандидат по-прежнему готов перейти к следующему этапу.

Адрес для пересылки создан,
ssh ключ на gitery.alt и gyle.alt зарегистрирован.

T/J/S -> 3.0.

Дмитрий, спасибо!

Подопечный готов собирать пакеты.

Пакет alt-gpgkeys обновлён.

T/J/S -> 4.0.

Долго и упорно тренировался на:
- https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-February/560019.html
- https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-June/572708.html
- https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-November/593576.html
- https://lists.altlinux.org/pipermail/sisyphus-incominger/2020-November/593572.html

Считаю, что падаван готов отправлять пакеты в Сизиф.

У меня вопрос по vim-plugin-coc.git, там в .gear/rules написано:
copy: .gear/node_modules.tar.gz

Скажите, пожалуйста, была ли какая-нибудь причина так делать?

В файле .gear/rules из репозитория node-bash-language-server.git аналогичная конструкция:
copy: .gear/node_modules.tar.gz

Мне кажется, что это следствие какого-то недопонимания gear.

Согласен, .gear не предназначен для хранения исходников. Будет исправлено.

Исправленная версия:
http://git.altlinux.org/tasks/262707/

(In reply to Nikita Obukhov from comment #15)
> Исправленная версия:
> http://git.altlinux.org/tasks/262707/

А почему вы решили хранить их в нераспакованной форме node_modules.tar.gz?

Это было сделано для удобства ведения репозитория, а так же опираясь на репозитории других ментейнеров.
http://git.altlinux.org/gears/c/cockpit.git

(In reply to Nikita Obukhov from comment #17)
> Это было сделано для удобства ведения репозитория, а так же опираясь на
> репозитории других ментейнеров.
> http://git.altlinux.org/gears/c/cockpit.git

За очень редкими редкими исключениями, исходный код хранится в репозитории исходного кода в распакованном виде.  Для того, чтобы имело смысл хранить исходный код в форме бинарного блоба, нужны веские причины.

Ещё один вопрос, в чём причина использования

Source: %name-%version.tar.gz
tar.gz: v@version@:.

вместо

tar: v@version@:.
Source: %name-%version.tar

?

И ещё один вопрос, в одном из спеков вы осуществляете закат солнца вручную с помощью tar -xzf %SOURCE1 -C "./server", в чём причина такого неординарного выбора?

(Ответ для Dmitry V. Levin на комментарий #19)
> Ещё один вопрос, в чём причина использования
> 
> Source: %name-%version.tar.gz
> tar.gz: v@version@:.
> 
> вместо
> 
> tar: v@version@:.
> Source: %name-%version.tar
> 
> ?

Да вы правы, в данном случае использование tar.gz является бессмысленным, так как исходников не много.

>И ещё один вопрос, в одном из спеков вы осуществляете закат солнца вручную с помощью tar -xzf %SOURCE1 -C "./server", в чём причина такого неординарного выбора?

В данном случае стоило воспользоваться возможностями макроса %setup.

Спасибо за ваши замечания, обязательно их учту при сборке следующих пакетов.

(In reply to Nikita Obukhov from comment #21)
> Да вы правы, в данном случае использование tar.gz является бессмысленным,
> так как исходников не много.

Использовать сжатые исходники в спекфайлах обычно не просто бесполезно, но ещё и немного вредно: это приводит к тому, что транспортные файлы с исходниками (gear-файлы, из которых ведётся сборка, и srpm-пакеты, которые получаются на выходе), в которых тоже есть сжатие, собираются дольше и получаются большего размера из-за двойного сжатия.

http://git.altlinux.org/tasks/262707/
Исправил замечания по пакетам.

Дмитрий, требуется ли еще что-то здесь поправить?

Скажите, пожалуйста, каково происхождение node_modules в node-bash-language-server и vim-plugin-coc?  Те упоминания, которые я нашёл ("Add node_modules for language-server" в одном пакете и "Add node_modules for build coc plugins" в другом), не очень помогают это понять.  Обычно происхождение исходного кода либо написано в нём самом, либо в коммите, который его добавляет, либо в спек-файле.

Пакет vim-plugin-coc содержит исходный код как минимум трёх самостоятельных проектов:
https://github.com/neoclide/coc.nvim
https://github.com/weirongxu/coc-calc
https://github.com/josa42/coc-sh
(происхождение последних двух пришлось искать, потому что в пакете этого не написано).

Такой подход гораздо сложнее обычного и на практике встречается редко.  Скажите, пожалуйста, зачем понадобилось объединять три проекта с разными апстримами в один исходный пакет?

(Ответ для Dmitry V. Levin на комментарий #25)
> Скажите, пожалуйста, каково происхождение node_modules в
> node-bash-language-server и vim-plugin-coc?  Те упоминания, которые я нашёл
> ("Add node_modules for language-server" в одном пакете и "Add node_modules
> for build coc plugins" в другом), не очень помогают это понять.  Обычно
> происхождение исходного кода либо написано в нём самом, либо в коммите,
> который его добавляет, либо в спек-файле.

Файлы node_modules были добавлены с помощью "npm install" исходя из зависимостей в файлах package.json. Согласен с вами, в коммите необходимо было указать как они были получены.

> Пакет vim-plugin-coc содержит исходный код как минимум трёх самостоятельных
> проектов:
> https://github.com/neoclide/coc.nvim
> https://github.com/weirongxu/coc-calc
> https://github.com/josa42/coc-sh
> (происхождение последних двух пришлось искать, потому что в пакете этого не
> написано).

Ссылки на исходники coc-calc и coc-sh указаны комментариями в spec-файле.

> Такой подход гораздо сложнее обычного и на практике встречается редко. 
> Скажите, пожалуйста, зачем понадобилось объединять три проекта с разными
> апстримами в один исходный пакет?

Совместно с ментором было решено использовать данный способ для того чтобы данным пакетом можно было пользоваться при отсутствии интернета. То есть чтобы установив пакет из локального репозитория, сразу была возможность пользоваться функционалом некоторых добавленных модулей. В дальнейшем планируется увеличить данный список.

>Скажите, пожалуйста, зачем понадобилось объединять три проекта с разными апстримами в один исходный пакет?
Не правильно, прочитал ваш вопрос. Я рассматривал vim-plugin-coc как один пакет, который содержит все необходимое. Поэтому, для своего удобства, я объединил их в один пакет.

(In reply to Nikita Obukhov from comment #27)
> >Скажите, пожалуйста, зачем понадобилось объединять три проекта с разными апстримами в один исходный пакет?
> Не правильно, прочитал ваш вопрос. Я рассматривал vim-plugin-coc как один
> пакет, который содержит все необходимое. Поэтому, для своего удобства, я
> объединил их в один пакет.

Получается, что для обновления одного из проектов в составе исходного пакета придётся обновлять весь исходный пакет.  Обычно мы такие забандливания избегаем и пакуем каждый исходный пакет отдельно.  Объясните мне, пожалуйста, почему именно в случае с vim-plugin-coc вам это паказалось удобным?

Мне так сказал сделать ментор, для того чтобы научиться использовать submodules.

Насчет обновления вы правы, обновлять отдельные пакеты будет намного удобнее.

(In reply to Nikita Obukhov from comment #29)
> Мне так сказал сделать ментор, для того чтобы научиться использовать
> submodules.

Да, ваш ментор вас не пожалел. :)

> Насчет обновления вы правы, обновлять отдельные пакеты будет намного удобнее.

Может быть, тогда разделите исходный пакет на составляющие?

Да, конечно. В ближайшее время все переделаю.

Речь, конечно же, не о submodules.

На этапе проектирования пакетирования этого пакета мной было сделано предположение, что если плагины и будут, то их будет немного(1-2) и отдельных бинарных пакетов под каждый плагин не будет. Но все-таки впоследствии мной было решено разбить бинарный vim-plugin-coc на core и плагины, а менять схему пакетирования не стал(позабыл?). Оба варианта возможны и допустимы, но красивее, удобнее и проще в данном случае будет 1 к 1.

Спасибо за замечание.

Разделил пакет vim-plugin-coc. Теперь плагины собираются из собственных src.
Так же исправлены недочеты.
http://git.altlinux.org/tasks/263573/

(In reply to Nikita Obukhov from comment #33)
> Разделил пакет vim-plugin-coc. Теперь плагины собираются из собственных src.
> Так же исправлены недочеты.
> http://git.altlinux.org/tasks/263573/

Рекомендация на будущее:
коммиты "Add gear rules" и "Add spec file" имеет смысл объединять в один, поскольку одно без другого неполноценно настолько, что даже "gear-store-tags -acv" не работает, в результате чего добавление .gear/tags попадает у вас в отдельный третий коммит.

Спасибо за рекомендацию. В дальнейшем буду использовать предложенный вами способ.

Дмитрий, добрый день. 
Скажите, пожалуйста, будут ли еще какие-либо замечания?

(Ответ для Dmitry V. Levin на комментарий #13)
> В файле .gear/rules из репозитория node-bash-language-server.git аналогичная
> конструкция:
> copy: .gear/node_modules.tar.gz
> 
> Мне кажется, что это следствие какого-то недопонимания gear.

Мне тут прислали пакет с той же грабелькой на отсмотр -- возможно, какая-то страница на вики такое недопонимание провоцирует.  Никита, Николай, расскажите по возможности -- какой именно текст привёл к мысли засунуть тарбол в gear?

(Ответ для Michael Shigorin на комментарий #37)
> 
> Мне тут прислали пакет с той же грабелькой на отсмотр -- возможно, какая-то
> страница на вики такое недопонимание провоцирует.  Никита, Николай,
> расскажите по возможности -- какой именно текст привёл к мысли засунуть
> тарбол в gear?

Нет, на вики ничего вводящего в заблуждение нет.
Я увидел подобное в пакетах других ментейнеров, оттуда и возникло недопонимание.

У кандидата пока совсем немного репозиториев, и они необычные.
Я сомневаюсь, что на этом объёме он мог приобрести достаточно опыта, но мы рассчитываем, что ментор не бросит своего подопечного на произвол судьбы, а будет помогать ему и в будущем.
Поэтому я полагаю, что можно двигаться дальше.

С удовольствием помогу, так как необычные задачи прокачивают и ментора.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!