Created attachment 14679 [details]
ssh и gpg ключи

Created attachment 14680 [details]
публичный gpg ключ

Created attachment 14681 [details]
публичный ssh ключ

Ник: aibure
Цель: Научиться собирать пакеты
Адрес пересылки: aibure@basealt.ru
Ментор: ancieg 
Подписка: ancieg@altlinux.org

Ник: aibure
Цель: Научиться собирать пакеты
Адрес пересылки: krasovskiyai@basealt.ru
Ментор: ancieg 
Подписка: ancieg@altlinux.org

(In reply to krasovskiyai from comment #5)
> Ник: aibure
> Цель: Научиться собирать пакеты
> Адрес пересылки: krasovskiyai@basealt.ru
> Ментор: ancieg 
> Подписка: ancieg@altlinux.org
Ok

Ментор есть, ключи в порядке.
T/J/S -> 1.3.

Прошу выдать доступ к gitery.

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

T/J/S -> 2.3.

Прошу выдать доступ к gyle.

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.
Адрес подписан на devel@.

T/J/S -> 3.6.

Думаю, пора передавать рецензенту.

Призван рецензент (arseny@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

(In reply to Gleb F-Malinovskiy from comment #13)
> Призван рецензент (arseny@) для независимой оценки готовности кандидата.
> 
> T/J/S -> 4.2.

ACK.

Артём, напишите, плжст, какие сборочные задания или исходные пакеты мне смотреть.

Добрый день!
Список пакетов для проверки:
duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
gleam (Rust) https://git.altlinux.org/gears/g/gleam.git
git-lfs (Golang) https://git.altlinux.org/gears/g/git-lfs.git
teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
date (C++) https://git.altlinux.org/gears/d/date.git

Дочитал я голанговщину и растишку; можно начинать.

(In reply to krasovskiyai from comment #15)
> duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
Замечание: у вас в спеке идут обращения к %ninja_install -C "%_cmake__builddir". В нашем случае, где всеми фазами сборки управляет CMake, это лишний шаг. Для цели `install` там просто написано "исполнить сгенерированный во время configure скрипт, который всё, что надо, поставит", и от способностей ninja/make толку нет; ни трекер mtime у исходников и артефактов, ни очередь задач не используются.
А цель install для ninja вообще генерируют, если честно, просто для паритета со сложившейся практикой вокруг make(1), чтобы с руки два слова писать. 

Достаточно %cmake_install, а макросы rpm-build-ninja не требуются.

  % rpmbuild --eval '%ninja_install -C "%_cmake__builddir"'
  DESTDIR=/tmp/.private/ar/%{name}-buildroot /usr/bin/ninja -j8 install -C "x86_64-alt-linux"
  % rpmbuild --eval '%cmake_install'               
  DESTDIR="/tmp/.private/ar/%{name}-buildroot" cmake --install "x86_64-alt-linux" --verbose

Первая раскрытая команда тупо сведётся к последней.

(In reply to krasovskiyai from comment #15)
> duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
Пара вопросов:

* Обоснуйте, чем "ExclusiveArch: пачка" лучше, чем "ExcludeArch: %ix86". (Bonus points, если обоснуете, чем ExclusiveArch в альтовой практике _хуже_.)

* Что, по-вашему, означает "%autopatch0"?

(In reply to krasovskiyai from comment #15)
> date (C++) https://git.altlinux.org/gears/d/date.git
Nit: зря у этого исх. пакета название прямо date, это серьёзная заявка на конфликт с чем-нибудь, особенно для пакета с исходниками. :)
  Debian 12 bookworm/main 	howardhinnant-date 	3.0.1 	misc 	andrea@pappacoda.it
  Debian 13 trixie/main 	howardhinnant-date 	3.0.3 	misc 	tachi@debian.org
  nixpkgs stable 25.11 	howard-hinnant-date 	3.0.3 	- 	rtburns@protonmail.com
  nixpkgs unstable 	howard-hinnant-date 	3.0.3 	- 	rtburns@protonmail.com
  Arch Linux extra 	chrono-date 	3.0.4 	- 	-

Ещё мелочь: а почему у вас в секции %build при without check вызов %cmake заканчивается на %nil, а при with check не заканчивается? Хочу увидеть ход мысли.

Более важный вопрос.
Вот у вас в начале спека определено "%soversion 3". Допустим, выходит новая версия, где несовместимым образом меняется ABI и становится 4. (Мейнтейнеру нужно будет этот макрос соотв. образом бампнуть.) Как вы это определите? Помогут ли вам в этом инструменты упаковки?

(In reply to krasovskiyai from comment #15)
> gleam (Rust) https://git.altlinux.org/gears/g/gleam.git
Подготовка завендоренного барахла у нас не автоматизирована, она отдана на совесть мейнтейнера, так что лучше, дабы приблизиться к воспроизводимости, указывать команды, при помощи которых получился vendor-каталог. Как вариант — прямо в commit message.

Больше серьёзных недочётов и ошибок я не заметил.

Вопрос к кандидату: Вот вы благим намерением добавили в gear-репу `.cargo/config.toml`. Как этот файл попадёт в сборочную среду? возымеет ли он желаемый эффект?

(In reply to krasovskiyai from comment #15)
> git-lfs (Golang) https://git.altlinux.org/gears/g/git-lfs.git
Добрый совет: берите в "" все подстановки переменных на шелле; лучше перебдеть,
чем огрести потом инъекцию кода или нежелательное раскрытие глоба. К примеру,
  43   manpage="$(echo "$page" | sed 's/.adoc/.1/')"
  44   asciidoctor -a reproducible -b manpage -o "$manpage" "$page"

То же самое про вендоринг, что и отн. gleam.
То же касается webassets в пакете teleport и вообще всех неявных заавендориваний.

(In reply to krasovskiyai from comment #15)
> teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
Открыл я directory with ALT settings. Автор, как следует из коммита, тоже вы :) так что и вопросы вам.

   9 EnvironmentFile=-/etc/default/teleport
Обоснуйте выбор каталога для этого файла.

  12 ExecReload=/bin/sh -c "exec pkill -HUP -L -F /run/teleport.pid"
Интересно, почему бы здесь и в соседних юнитах сразу не вызвать программу pkill?

  13 PIDFile=/run/teleport.pid
Нужен ли в принципе PIDFile= для службы типа simple?

Ещё: ряд компонентов из состава проекта teleport написаны на rust+cargo, которые вызываются из глубин make-портянки (oh, the irony!). Приходят ли им наши оптфлаги?

(In reply to krasovskiyai from comment #15)
> teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
А, вот ещё нехороший момент, касается служебных uid и gid для teleport.

"Teleport user" — отсюда ясно, что записи связаны с этим пакетом, но не ясно, что под ними работает; там же субкомпоненты есть. Прошу при обновлении сделать этому усеру gecos яснее.

Кроме того, у нас служебные (aka системные) имена усеров и групп по соглашению начинаются с `_`. Теперь, конечно, когда пакет уже в сизифе, исправить это в общем случае нелегко; сложность зависит от того, хранит ли оно в системе файлы и каков их жизненный цикл.

Жду пока ответов на вопросы. Часть из них намекают на лучший вариант, чем сейчас, а иные заданы для того, чтобы было понятнее, как вы рассуждаете при принятии того или иного решения в роли мейнтейнера. :)

В остальном: вижу, что мы научились консистентно обновлять пакеты, умеем пользоваться git, пишем changelog-записи приемлемо, собираем пакеты разной природы. Пока я не увидел ни одного ноарчового пакета; прошу собрать что-нибудь noarch с учётом уже обсуждавшихся недочётов и замечаний.

(Ответ для Arseny Maslennikov на комментарий #16)
> Дочитал я голанговщину и растишку; можно начинать.
> 
> (In reply to krasovskiyai from comment #15)
> > duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
> Замечание: у вас в спеке идут обращения к %ninja_install -C
> "%_cmake__builddir". В нашем случае, где всеми фазами сборки управляет
> CMake, это лишний шаг. Для цели `install` там просто написано "исполнить
> сгенерированный во время configure скрипт, который всё, что надо, поставит",
> и от способностей ninja/make толку нет; ни трекер mtime у исходников и
> артефактов, ни очередь задач не используются.
> А цель install для ninja вообще генерируют, если честно, просто для паритета
> со сложившейся практикой вокруг make(1), чтобы с руки два слова писать. 
> 
> Достаточно %cmake_install, а макросы rpm-build-ninja не требуются.
> 
>   % rpmbuild --eval '%ninja_install -C "%_cmake__builddir"'
>   DESTDIR=/tmp/.private/ar/%{name}-buildroot /usr/bin/ninja -j8 install -C
> "x86_64-alt-linux"
>   % rpmbuild --eval '%cmake_install'               
>   DESTDIR="/tmp/.private/ar/%{name}-buildroot" cmake --install
> "x86_64-alt-linux" --verbose
> 
> Первая раскрытая команда тупо сведётся к последней.

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

(Ответ для Arseny Maslennikov на комментарий #17)
> (In reply to krasovskiyai from comment #15)
> > duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
> Пара вопросов:
> 
> * Обоснуйте, чем "ExclusiveArch: пачка" лучше, чем "ExcludeArch: %ix86".
> (Bonus points, если обоснуете, чем ExclusiveArch в альтовой практике _хуже_.)
> 
> * Что, по-вашему, означает "%autopatch0"?

Я считаю что такая пачка лучше из-за явности, сразу видно какие архитектуры поддерживаются. Именно для ALT такая явность в итоге становиться ограничением для сборки на догоняющих сборочницах, например с risc-v и для включения архитектуры мейнтейнерам приходится редактировать спек.

Насчет %autopatch0. В документации (https://rpm.org/docs/4.19.x/manual/autosetup.html) нашел возможность явно указывать какие патчи применять, решил попробовать воспользоваться в такой форме, что бы и autopatch оставить и показать, что пока я собираюсь применять только патч с номером 0, по логам показалось, что все работает нормально, сейчас перепроверил и понял, что указание 0 ничего не меняет) %autopatch0 так же применяет все патчи. Исправлю на просто %autopatch при обновлении пакета.

(Ответ для Arseny Maslennikov на комментарий #18)
> (In reply to krasovskiyai from comment #15)
> > date (C++) https://git.altlinux.org/gears/d/date.git
> Nit: зря у этого исх. пакета название прямо date, это серьёзная заявка на
> конфликт с чем-нибудь, особенно для пакета с исходниками. :)
>   Debian 12 bookworm/main 	howardhinnant-date 	3.0.1 	misc 
> andrea@pappacoda.it
>   Debian 13 trixie/main 	howardhinnant-date 	3.0.3 	misc 	tachi@debian.org
>   nixpkgs stable 25.11 	howard-hinnant-date 	3.0.3 	- 	rtburns@protonmail.com
>   nixpkgs unstable 	howard-hinnant-date 	3.0.3 	- 	rtburns@protonmail.com
>   Arch Linux extra 	chrono-date 	3.0.4 	- 	-
> 
> Ещё мелочь: а почему у вас в секции %build при without check вызов %cmake
> заканчивается на %nil, а при with check не заканчивается? Хочу увидеть ход
> мысли.
> 
> Более важный вопрос.
> Вот у вас в начале спека определено "%soversion 3". Допустим, выходит новая
> версия, где несовместимым образом меняется ABI и становится 4. (Мейнтейнеру
> нужно будет этот макрос соотв. образом бампнуть.) Как вы это определите?
> Помогут ли вам в этом инструменты упаковки?

Согласен, что недальновидно было назвать пакет просто date, на тот момент я руководствовался следующим: название не занято - значит будет занято. Сейчас я понимаю, что название конфликтное и точность в названии не помешала бы.

Про %nil. Когда только начал собирать пакет, команда сборки была выстроена каким-то образом, что не все опции cmake применялись, точно уже не помню или вообще сборка падала, тогда %nil помог, в итоге я его оставил, сейчас проверил сборку без него - сборка проходит исправно.

Какими либо инструментами для определения ABI версии еще не пользовался. Сейчас нагуглил abi-compliance-checker и abi-dumper, пока думаю что Вы имели в виду их. А так я смотрел бы grep'ом по objbump `objdump -p /usr/lib64/libexample.so | grep SONAME`, и то это если сборка уже не упала из-за несоответствия soname.

(Ответ для Arseny Maslennikov на комментарий #19)
> (In reply to krasovskiyai from comment #15)
> > gleam (Rust) https://git.altlinux.org/gears/g/gleam.git
> Подготовка завендоренного барахла у нас не автоматизирована, она отдана на
> совесть мейнтейнера, так что лучше, дабы приблизиться к воспроизводимости,
> указывать команды, при помощи которых получился vendor-каталог. Как вариант
> — прямо в commit message.
> 
> Больше серьёзных недочётов и ошибок я не заметил.
> 
> Вопрос к кандидату: Вот вы благим намерением добавили в gear-репу
> `.cargo/config.toml`. Как этот файл попадёт в сборочную среду? возымеет ли
> он желаемый эффект?

Про указание команд для вендоринга услышал, буду использовать.
.cargo/config.toml попадет в окружение через кумулятивный патч 
Patch: %name-%version-alt.patch
diff: v@version@:. . name=@name@-@version@-alt.patch exclude=vendor/ exclude=.gear/
Полагаю эффект возымеет, как минимум по логам точно применяются rustflags = ["-Copt-level=3", "-Cdebuginfo=1"]


(Ответ для Arseny Maslennikov на комментарий #20)
> (In reply to krasovskiyai from comment #15)
> > git-lfs (Golang) https://git.altlinux.org/gears/g/git-lfs.git
> Добрый совет: берите в "" все подстановки переменных на шелле; лучше
> перебдеть,
> чем огрести потом инъекцию кода или нежелательное раскрытие глоба. К примеру,
>   43   manpage="$(echo "$page" | sed 's/.adoc/.1/')"
>   44   asciidoctor -a reproducible -b manpage -o "$manpage" "$page"
> 
> То же самое про вендоринг, что и отн. gleam.
> То же касается webassets в пакете teleport и вообще всех неявных
> заавендориваний.

Так же спасибо за замечание, приму к сведению.

(Ответ для Arseny Maslennikov на комментарий #21)
> (In reply to krasovskiyai from comment #15)
> > teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
> Открыл я directory with ALT settings. Автор, как следует из коммита, тоже вы
> :) так что и вопросы вам.
> 
>    9 EnvironmentFile=-/etc/default/teleport
> Обоснуйте выбор каталога для этого файла.
> 
>   12 ExecReload=/bin/sh -c "exec pkill -HUP -L -F /run/teleport.pid"
> Интересно, почему бы здесь и в соседних юнитах сразу не вызвать программу
> pkill?
> 
>   13 PIDFile=/run/teleport.pid
> Нужен ли в принципе PIDFile= для службы типа simple?
> 
> Ещё: ряд компонентов из состава проекта teleport написаны на rust+cargo,
> которые вызываются из глубин make-портянки (oh, the irony!). Приходят ли им
> наши оптфлаги?

Unit файл я получил командой: teleport install systemd. Подозрительным он мне не показался.

Rust утилита fdpass-teleport видно собирается с rustflags = ["-Copt-level=3", "-Cdebuginfo=1"], но игнорирует strip = false из tool/fdpass-teleport/.cargo/config.toml. Пока не нашел причину почему так.



(Ответ для Arseny Maslennikov на комментарий #22)
> (In reply to krasovskiyai from comment #15)
> > teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
> А, вот ещё нехороший момент, касается служебных uid и gid для teleport.
> 
> "Teleport user" — отсюда ясно, что записи связаны с этим пакетом, но не
> ясно, что под ними работает; там же субкомпоненты есть. Прошу при обновлении
> сделать этому усеру gecos яснее.
> 
> Кроме того, у нас служебные (aka системные) имена усеров и групп по
> соглашению начинаются с `_`. Теперь, конечно, когда пакет уже в сизифе,
> исправить это в общем случае нелегко; сложность зависит от того, хранит ли
> оно в системе файлы и каков их жизненный цикл.

Про gecos услышал, сделаю подробнее.
Про соглашение наименования системных имен не знал, впредь буду учитывать.

Чуть позже всё прокомментирую.

Пока вот абстрактно.

В поле License: в пакете мы последние годы стараемся поддерживать порядок.
Если у лицензии есть общепринятый SPDX-License-Identifier, мы указываем его.
Если у лицензии его нет, то придумываем сами с префиксом "ALT-"; например, ALT-Reticulum, ALT-Zsh. Тогда либо в пакет common-licenses, либо в наш пакет нужно поместить под соотв. именем в каталог /usr/share/license* текст лицензии.

(In reply to krasovskiyai from comment #24)
> (Ответ для Arseny Maslennikov на комментарий #16)
> > (In reply to krasovskiyai from comment #15)
> > > duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
> > Замечание: у вас в спеке идут обращения к %ninja_install -C
> > "%_cmake__builddir". В нашем случае, где всеми фазами сборки управляет
> > CMake, это лишний шаг. Для цели `install` там просто написано "исполнить
> > сгенерированный во время configure скрипт, который всё, что надо, поставит",
> > и от способностей ninja/make толку нет; ни трекер mtime у исходников и
> > артефактов, ни очередь задач не используются.
> > А цель install для ninja вообще генерируют, если честно, просто для паритета
> > со сложившейся практикой вокруг make(1), чтобы с руки два слова писать. 
> > 
> > Достаточно %cmake_install, а макросы rpm-build-ninja не требуются.
> > 
> >   % rpmbuild --eval '%ninja_install -C "%_cmake__builddir"'
> >   DESTDIR=/tmp/.private/ar/%{name}-buildroot /usr/bin/ninja -j8 install -C
> > "x86_64-alt-linux"
> >   % rpmbuild --eval '%cmake_install'               
> >   DESTDIR="/tmp/.private/ar/%{name}-buildroot" cmake --install
> > "x86_64-alt-linux" --verbose
> > 
> > Первая раскрытая команда тупо сведётся к последней.
> 
> Спасибо за замечание, внесу исправления при следующем обновлении пакета.
OK

(In reply to krasovskiyai from comment #24)
> (Ответ для Arseny Maslennikov на комментарий #19)
> > (In reply to krasovskiyai from comment #15)
> > > gleam (Rust) https://git.altlinux.org/gears/g/gleam.git
> > Подготовка завендоренного барахла у нас не автоматизирована, она отдана на
> > совесть мейнтейнера, так что лучше, дабы приблизиться к воспроизводимости,
> > указывать команды, при помощи которых получился vendor-каталог. Как вариант
> > — прямо в commit message.
> 
> Про указание команд для вендоринга услышал, буду использовать.
OK

> > Больше серьёзных недочётов и ошибок я не заметил.
> > 
> > Вопрос к кандидату: Вот вы благим намерением добавили в gear-репу
> > `.cargo/config.toml`. Как этот файл попадёт в сборочную среду? возымеет ли
> > он желаемый эффект?
> .cargo/config.toml попадет в окружение через кумулятивный патч 
> Patch: %name-%version-alt.patch
> diff: v@version@:. . name=@name@-@version@-alt.patch exclude=vendor/
> exclude=.gear/
> Полагаю эффект возымеет, как минимум по логам точно применяются rustflags =
> ["-Copt-level=3", "-Cdebuginfo=1"]
OK, объяснили правильно.

Логики совать эти флаги в патч мало (это же не свойство исходников), но
результат один и тот же, да. Не ругаю за такое, ибо это закономерная расплата
сообщества за взваливание подобной суеты на каждого мейнтейнера.

(In reply to krasovskiyai from comment #24)
> (Ответ для Arseny Maslennikov на комментарий #17)
> > (In reply to krasovskiyai from comment #15)
> > > duckdb (C++) https://git.altlinux.org/gears/d/duckdb.git
> > Пара вопросов:
> > 
> > * Обоснуйте, чем "ExclusiveArch: пачка" лучше, чем "ExcludeArch: %ix86".
> > (Bonus points, если обоснуете, чем ExclusiveArch в альтовой практике _хуже_.)
> > 
> > * Что, по-вашему, означает "%autopatch0"?
> 
> Я считаю что такая пачка лучше из-за явности, сразу видно какие архитектуры
> поддерживаются.
Поддерживаются кем? Апстримом? Пусть он сам за себя думает.
Мы-то обычно хотим, чтобы, если проект на данной архитектуре вообще удалось
собрать, какой-то пакет был. А вот если нельзя — тогда ExcludeArch.

Логику я понял, она валидна, но не убедительна.

> Именно для ALT такая явность в итоге становиться
> ограничением для сборки на догоняющих сборочницах, например с risc-v и для
> включения архитектуры мейнтейнерам приходится редактировать спек.
Ага, я именно это имел в виду. :)

В общем, в случае отсутствия явного ответа на вопрос "работает ли софт на
некоторой архитектуре" — (апстрим не знает, не пробовал) — неявный вывод можно
сделать в две стороны: либо "скорее не работает", либо "скорее работает". Мы в
альте (и не только альт) предпочитаем второе.

> Насчет %autopatch0. В документации
> (https://rpm.org/docs/4.19.x/manual/autosetup.html) нашел возможность явно
> указывать какие патчи применять, решил попробовать воспользоваться в такой
> форме, что бы и autopatch оставить и показать, что пока я собираюсь
> применять только патч с номером 0, по логам показалось, что все работает
> нормально, сейчас перепроверил и понял, что указание 0 ничего не меняет)
> %autopatch0 так же применяет все патчи. Исправлю на просто %autopatch при
> обновлении пакета.
Ага. Лучше на такие полусказанности не завязываться; раз autopatch, значит,
autopatch.

Теперь директивные замечания.

(In reply to krasovskiyai from comment #24)
> (Ответ для Arseny Maslennikov на комментарий #18)
> > (In reply to krasovskiyai from comment #15)
> > > date (C++) https://git.altlinux.org/gears/d/date.git
> > Ещё мелочь: а почему у вас в секции %build при without check вызов %cmake
> > заканчивается на %nil, а при with check не заканчивается? Хочу увидеть ход
> > мысли.
> > 
> > Более важный вопрос.
> > Вот у вас в начале спека определено "%soversion 3". Допустим, выходит новая
> > версия, где несовместимым образом меняется ABI и становится 4. (Мейнтейнеру
> > нужно будет этот макрос соотв. образом бампнуть.) Как вы это определите?
> > Помогут ли вам в этом инструменты упаковки?
> 
> Про %nil. Когда только начал собирать пакет, команда сборки была выстроена
> каким-то образом, что не все опции cmake применялись, точно уже не помню или
> вообще сборка падала, тогда %nil помог, в итоге я его оставил, сейчас
> проверил сборку без него - сборка проходит исправно.
Благодарю за ответ.

В общем, %nil ставится в конец такой многострочной, с переносами, команды не
просто так, а чтобы не было значащей пустой строки. У вас она в спеке есть.
Сделайте с этим что-нибудь, pls.

> Какими либо инструментами для определения ABI версии еще не пользовался.
> Сейчас нагуглил abi-compliance-checker и abi-dumper, пока думаю что Вы имели
> в виду их. А так я смотрел бы grep'ом по objbump `objdump -p
> /usr/lib64/libexample.so | grep SONAME`,
Можно и так, да.

> и то это если сборка уже не упала из-за несоответствия soname.
Но она не упадёт, потому что вы упаковываете %_libdir/libdate-tz.so.*. В новой
версии, например, появятся файлы libdate-tz.so.4*, они молча будут упакованы и всё.
Возникновение unmet requirements определит только сборочница.

Как здесь помогут инструменты упаковки, вы не сказали :)
У вас в спеке есть '_unpackaged_files_terminate_build 1'; если передать в
секции files выражения с упоминанием %soversion, то уже rpm-build вам подскажет.

(In reply to krasovskiyai from comment #24)
> (Ответ для Arseny Maslennikov на комментарий #21)
> > (In reply to krasovskiyai from comment #15)
> > > teleport (Golang) https://git.altlinux.org/gears/t/teleport.git
> > Открыл я directory with ALT settings. Автор, как следует из коммита, тоже вы
> > :) так что и вопросы вам.
> > 
> >    9 EnvironmentFile=-/etc/default/teleport
> > Обоснуйте выбор каталога для этого файла.
> > 
> >   12 ExecReload=/bin/sh -c "exec pkill -HUP -L -F /run/teleport.pid"
> > Интересно, почему бы здесь и в соседних юнитах сразу не вызвать программу
> > pkill?
> > 
> >   13 PIDFile=/run/teleport.pid
> > Нужен ли в принципе PIDFile= для службы типа simple?
> > 
> > Ещё: ряд компонентов из состава проекта teleport написаны на rust+cargo,
> > которые вызываются из глубин make-портянки (oh, the irony!). Приходят ли им
> > наши оптфлаги?
> 
> Unit файл я получил командой: teleport install systemd. Подозрительным он
> мне не показался.
Тогда об этом надо писать в commit message, мол, "это не я". :)
Да и исправить за апстримом; мейнтейнеры всё ещё пишут unit-файлы лучше
медианного апстрима, потому что им это важнее.

На мой непристальный взгляд:
- EnvironmentFile, если он вообще нужен, надо положить в sysconfigdir;
- в действии ExecReload интерпретация отдельным shell не нужна, можно просто
  указать слова из команды;
- pidfile не нужен, а в ExecReload надо сослаться на $MAINPID (одна из немногих
  подстановок, которую поддерживает systemd).

> Rust утилита fdpass-teleport видно собирается с rustflags =
> ["-Copt-level=3", "-Cdebuginfo=1"], но игнорирует strip = false из
> tool/fdpass-teleport/.cargo/config.toml. Пока не нашел причину почему так.
Хорошо, что обратили внимание.

В итоге:
- всё ещё жду чего-нибудь ноарчового;
- по итогам прежнего обсуждения жду чего-нибудь ещё бинарного;
- разберитесь с %nil в одном из пакетов;
- поправьте юнит-файл для teleport.

Артём, как у вас дела?

https://altlinux.org/Team/Join/Review_Team
Мы в качестве эксперимента учредили самоуправление в команде ревьюеров, в надежде, что это ускорит прохождение застрявших на 4.0 в тиму.
Теперь у нас рецензенты самоназначаются. Моё дело — пингануть всех кандидатов у меня на рецензии, чтобы понять, могу ли я брать ещё или нет. Вот я и спрашиваю. :)

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