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.
