(Ответ для 1lion23550 на комментарий #0)
> Псевдоним: Rx1513

Псевдоним rx1513

Created attachment 16440 [details]
gpg ключ

Created attachment 16441 [details]
ssh ключ

(Ответ для 1lion23550 на комментарий #0)
> Ментор: Александр Шашкин ( dutyrok@altlinux.org )
Согласен быть ментором.

За время ожидания кандидат освоил инструменты сборки и собрал несколько пакетов локально. Так что считаю, что кандидат готов собирать пакеты на сборочнице.

Если так можно, то чтобы не терять время, предлагаю сразу выполнить все шаги join до 3.6.

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

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

T/J/S -> 2.3.

> Если так можно, то чтобы не терять время, предлагаю сразу выполнить все шаги
> join до 3.6.

T/J/M -> 3.0.

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

T/J/S -> 3.6.

Меня попросили посмотреть https://packages.altlinux.org/en/tasks/381651/,
и вот что я увидел в логе сборки задания:

#300 lcov 1.15-alt1 -> 2.3.1-alt1
 Tue Jul 01 2025 Sergey Zhidkih <rx1513@altlinux> 2.3.1-alt1
 - Update version. (Closes #53435)
 - Start building from tag.
 - Refactor spec and repository.

Я бы хотел обратить внимание кандидата, что %changelog пакета предназначен для user-visible changes, т.е. таких изменений в пакете, о которых имеет смысл сообщать пользователям пакета, в то время как аннотирование изменений для разработчика обычно осуществляется git-коммитах.

Что касается изменений в спеке, большая их часть как минимум неочевидная, поэтому аргументированно прокомментируйте каждое изменение (помимо Version и %changelog) либо в спеке, либо в коммите "Update version, fix tests".  Про каждую зависимость, добавленную вручную, напишите, откуда именно она берется.

(Ответ для Dmitry V. Levin на комментарий #10)
> Меня попросили посмотреть https://packages.altlinux.org/en/tasks/381651/,
> и вот что я увидел в логе сборки задания:
> 
> #300 lcov 1.15-alt1 -> 2.3.1-alt1
>  Tue Jul 01 2025 Sergey Zhidkih <rx1513@altlinux> 2.3.1-alt1
>  - Update version. (Closes #53435)
>  - Start building from tag.
>  - Refactor spec and repository.
> 
> Я бы хотел обратить внимание кандидата, что %changelog пакета предназначен
> для user-visible changes, т.е. таких изменений в пакете, о которых имеет
> смысл сообщать пользователям пакета, в то время как аннотирование изменений
> для разработчика обычно осуществляется git-коммитах.
> [...]
Приму к сведению. Однако в таком случае нужно править следующий фрагмент вики:
> Косметические изменения спек-файла, не влияющие на получаемый пакет,
> указываются максимум одной строкой («spec cleanup»), либо не указываются
> вовсе. Это не относится к исправлениям тега License, изменениям
> параметров сборки и т. д.
Источник:
https://www.altlinux.org/Руководство_по_написанию_changelog#Содержимое

> [...]
> Что касается изменений в спеке, большая их часть как минимум неочевидная,
> поэтому аргументированно прокомментируйте каждое изменение (помимо Version и
> %changelog) либо в спеке, либо в коммите "Update version, fix tests".  Про
> каждую зависимость, добавленную вручную, напишите, откуда именно она берется.
Не совсем понимаю какая именно часть неочевидная. Добавление Vcs соответсвует новому формату спека: https://www.altlinux.org/Spec#Vcs. Добавление gcc-c++ - ошибка, исправлю.

Большая часть зависимостей была взята из списка указанного апcтримом в README для собираемой версии: https://github.com/linux-test-project/lcov/blob/v2.3.1/README. Остальная часть была выявлена в ходе запуска тестов. 

lcovutil и annotateutil являются внутренними зависимостями lcov и не предназначены для работы вне пакета. Что собственно и написано в rpm спеке опубликованном разработчиками:
> # lcov Perl modules are not intended for use by other packages
> %define __requires_exclude ^perl\\(lcovutil\\)$|^perl\\((criteria)\\)$|^perl\\((annotateutil)\\)$|^perl\\((gitblame)\\)$|^perl\\((gitversion)\\)$|^perl\\((select)\\)$|^perl\\((p4annotate)\\)
Источник: https://github.com/linux-test-project/lcov/blob/v2.3.1/rpm/lcov.spec

python3(localmodule) - зависимость из https://github.com/linux-test-project/lcov/tree/v2.3.1/tests/py2lcov, к работе программы отношения не имеет.
/bin/env - опечатка из https://github.com/linux-test-project/lcov/blob/v2.3.1/tests/gendiffcov/simple/annotate.sh.

Дальнейшие изменения в коммите 'Update version, fix tests' мне кажется достаточно раскрыты, чтобы не вызывать никаких вопросов.

Все последующие коммиты являются косметическими изменениями для приведения репозитория к более менее современному виду: разделение исходников и всего что касается сборки пакета в .gear, добавление gear/remotes https://www.altlinux.org/Gear/remotes и сборка из тега, чтобы уменьшить риск случайно собрать пакет не соответствующий релизу.

Пожалуйста, укажите конкретные моменты которые стоит подробно расписать, потому что всё что мне показалось недостаточно раскрытым или всё что не может быть получено из контекста я прокомментировал в спеке.

(In reply to Сергей Жидких from comment #11)
> Добавление Vcs соответсвует новому формату спека: https://www.altlinux.org/Spec#Vcs.

Добавление Vcs само по себе не вызвало бы вопросов, если бы в результате в спеке не образовалось бы следующее:

URL: https://github.com/linux-test-project/lcov/
Vcs: https://github.com/linux-test-project/lcov

С одной стороны, странно, что значения этих тэгов отличаются именно таким образом.

С другой стороны, если значения не отличаются, то налицо избыточное дублирование, которого желательно избегать.

(In reply to Сергей Жидких from comment #11)
> Большая часть зависимостей была взята из списка указанного апcтримом в
> README для собираемой версии:
> https://github.com/linux-test-project/lcov/blob/v2.3.1/README.

Это не очевидно, следовательно, об этом стоило написать в комментарии.

Кроме того, в добавленных строках наблюдается очевидная избыточность:
+BuildRequires: perl-DateTime perl-TimeDate
+BuildRequires: perl-Capture-Tiny perl-Devel-Cover
+BuildRequires: perl-JSON-XS perl-base
+BuildRequires: rpm-build-python3

> Остальная часть была выявлена в ходе запуска тестов.

Вы не пробовали прогонять buildreq по этому пакету?

> lcovutil и annotateutil являются внутренними зависимостями lcov и не
> предназначены для работы вне пакета. Что собственно и написано в rpm спеке
> опубликованном разработчиками:
> > # lcov Perl modules are not intended for use by other packages
> > %define __requires_exclude ^perl\\(lcovutil\\)$|^perl\\((criteria)\\)$|^perl\\((annotateutil)\\)$|^perl\\((gitblame)\\)$|^perl\\((gitversion)\\)$|^perl\\((select)\\)$|^perl\\((p4annotate)\\)
> Источник:
> https://github.com/linux-test-project/lcov/blob/v2.3.1/rpm/lcov.spec

Это не очевидно, следовательно, об этом стоило написать в комментарии.
Далее, в источнике, на который вы ссылаетесь, отфильтровывается больше, чем отфильтровываете вы, и причина этого расхождения тоже не очевидна.

> python3(localmodule) - зависимость из
> https://github.com/linux-test-project/lcov/tree/v2.3.1/tests/py2lcov, к
> работе программы отношения не имеет.

Если вы решили запаковать новый скрипт /usr/bin/py2lcov, то непонятно, почему вы отфильтровываете зависимости этого скрипта.

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

> /bin/env - опечатка из
> https://github.com/linux-test-project/lcov/blob/v2.3.1/tests/gendiffcov/
> simple/annotate.sh.

В таком случае нужно исправить опечатку, а не отфильтровывать зависимости с помощью
+%filter_from_requires /\/bin\/env/d

> Дальнейшие изменения в коммите 'Update version, fix tests' мне кажется
> достаточно раскрыты, чтобы не вызывать никаких вопросов.

Мне так не кажется.

> Все последующие коммиты являются косметическими изменениями для приведения
> репозитория к более менее современному виду: разделение исходников и всего
> что касается сборки пакета в .gear,

Это дело вкуса, практической пользы в этом, по-видимому, нет никакой.

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

> добавление gear/remotes
> https://www.altlinux.org/Gear/remotes и сборка из тега, чтобы уменьшить риск
> случайно собрать пакет не соответствующий релизу.

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

> Пожалуйста, укажите конкретные моменты которые стоит подробно расписать,
> потому что всё что мне показалось недостаточно раскрытым или всё что не
> может быть получено из контекста я прокомментировал в спеке.

Перемещение
%define _unpackaged_files_terminate_build 1
в первую строчку спека не делает его лучше.

> +# Replace with correct path to bash, so apt won't complain about inexestent dependency.

Предлагаю при написании текста на английском использовать spellchecker.
apt упоминать не обязательно.

> +find . -type f | xargs sed -i 's|/usr/bin/bash|/bin/bash|g'

Такие изменения обычно делают в секции %prep.

> +# Unset ocassionally stored variable
> +unset SOURCE_DATE_EPOCH
> +make clean

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

> +%_datadir/lcov/support-scripts
> +%_datadir/lcov/example
> +%exclude %_datadir/lcov/tests

Каталог %_datadir/lcov/ в результате оказался неупакованным.

> +%_libexecdir/lcov/lcovutil.pm

Каталог %_libexecdir/lcov/ в результате оказался неупакованным.

Отдельный вопрос в выборе каталога, предлагаю посмотреть, куда пакуют LIB_DIR этого пакета в других дистрибутивах.

(In reply to Dmitry V. Levin from comment #13)
> (In reply to Сергей Жидких from comment #11)
> > python3(localmodule) - зависимость из
> > https://github.com/linux-test-project/lcov/tree/v2.3.1/tests/py2lcov, к
> > работе программы отношения не имеет.
> 
> Если вы решили запаковать новый скрипт /usr/bin/py2lcov, то непонятно,
> почему вы отфильтровываете зависимости этого скрипта.

Замечу, что localmodule упоминается только в tests/py2lcov/test.py, который вы, как я полагаю, всё-таки не пакуете.

(Ответ для Dmitry V. Levin на комментарий #12)
> (In reply to Сергей Жидких from comment #11)
> > Добавление Vcs соответсвует новому формату спека: https://www.altlinux.org/Spec#Vcs.
> 
> Добавление Vcs само по себе не вызвало бы вопросов, если бы в результате в
> спеке не образовалось бы следующее:
> 
> URL: https://github.com/linux-test-project/lcov/
> Vcs: https://github.com/linux-test-project/lcov
> 
> С одной стороны, странно, что значения этих тэгов отличаются именно таким
> образом.
> [...]
Возможно стоит добавить .git к ссылки из Vcs, чтобы явно указать Vcs.

> [...]
> С другой стороны, если значения не отличаются, то налицо избыточное
> дублирование, которого желательно избегать.

По этому поводу есть следующий параграф на вики:
> В случае, если проект не имеет отдельной страницы с информацией о нём,
> а лишь git репозиторий, например, на github, то не стесняйтесь указывать
> ссылку на него и в Url, и в Vcs. С точки зрения пользователя это дублирование
> информации, но с точки зрения сервисов, которые используют эти теги,
> это совсем не так. Url и Vcs это разные объекты, даже совпадение которых даёт
> какую-то информацию о проекте.
Источник: https://www.altlinux.org/Spec#Совпадение_значений_тегов_Url_и_Vcs

(In reply to Сергей Жидких from comment #15)
> (Ответ для Dmitry V. Levin на комментарий #12)
> > С другой стороны, если значения не отличаются, то налицо избыточное
> > дублирование, которого желательно избегать.
> 
> По этому поводу есть следующий параграф на вики:
> > В случае, если проект не имеет отдельной страницы с информацией о нём,
> > а лишь git репозиторий, например, на github, то не стесняйтесь указывать
> > ссылку на него и в Url, и в Vcs. С точки зрения пользователя это дублирование
> > информации, но с точки зрения сервисов, которые используют эти теги,
> > это совсем не так. Url и Vcs это разные объекты, даже совпадение которых даёт
> > какую-то информацию о проекте.
> Источник: https://www.altlinux.org/Spec#Совпадение_значений_тегов_Url_и_Vcs

В таком случае следует исправить wiki. Например, можно предложить использовать %url в определении Vcs.

(In reply to Dmitry V. Levin from comment #13)
> (In reply to Сергей Жидких from comment #11)
> > /bin/env - опечатка из
> > https://github.com/linux-test-project/lcov/blob/v2.3.1/tests/gendiffcov/
> > simple/annotate.sh.
> 
> В таком случае нужно исправить опечатку, а не отфильтровывать зависимости с
> помощью
> +%filter_from_requires /\/bin\/env/d
> > +find . -type f | xargs sed -i 's|/usr/bin/bash|/bin/bash|g'

Кстати, обратите внимание на
https://salsa.debian.org/mckinstry/lcov/-/blob/debian/latest/debian/patches/interp-paths.patch

(Ответ для Dmitry V. Levin на комментарий #13)
> (In reply to Сергей Жидких from comment #11)
> > Большая часть зависимостей была взята из списка указанного апcтримом в
> > README для собираемой версии:
> > https://github.com/linux-test-project/lcov/blob/v2.3.1/README.
> 
> Это не очевидно, следовательно, об этом стоило написать в комментарии.
Учту.

> Кроме того, в добавленных строках наблюдается очевидная избыточность:
> +BuildRequires: perl-DateTime perl-TimeDate
> +BuildRequires: perl-Capture-Tiny perl-Devel-Cover
> +BuildRequires: perl-JSON-XS perl-base
> +BuildRequires: rpm-build-python3
> 
> > Остальная часть была выявлена в ходе запуска тестов.
> 
> Вы не пробовали прогонять buildreq по этому пакету?
> 
Из всех зависимостей он добавил лишь python3 который подгружается из других пакетов из списка. 

> > lcovutil и annotateutil являются внутренними зависимостями lcov и не
> > предназначены для работы вне пакета. Что собственно и написано в rpm спеке
> > опубликованном разработчиками:
> > > # lcov Perl modules are not intended for use by other packages
> > > %define __requires_exclude ^perl\\(lcovutil\\)$|^perl\\((criteria)\\)$|^perl\\((annotateutil)\\)$|^perl\\((gitblame)\\)$|^perl\\((gitversion)\\)$|^perl\\((select)\\)$|^perl\\((p4annotate)\\)
> > Источник:
> > https://github.com/linux-test-project/lcov/blob/v2.3.1/rpm/lcov.spec
> 
> Это не очевидно, следовательно, об этом стоило написать в комментарии.
> Далее, в источнике, на который вы ссылаетесь, отфильтровывается больше, чем
> отфильтровываете вы, и причина этого расхождения тоже не очевидна.
> 
Остальные зависимости из этого списка autoreq не видит. Более того, я только сейчас заметил, что autoreq ещё и не захватил большую часть обязательных зависимостей.
Примечания добавлю.

> > python3(localmodule) - зависимость из
> > https://github.com/linux-test-project/lcov/tree/v2.3.1/tests/py2lcov, к
> > работе программы отношения не имеет.
> 
> Если вы решили запаковать новый скрипт /usr/bin/py2lcov, то непонятно,
> почему вы отфильтровываете зависимости этого скрипта.
> 
Это внутренний игрушечный модуль для проверки снятия покрытия скриптом. В реальной работе утилиты он не используется. 

> Отдельный вопрос, имеет ли смысл паковать новые скрипты в основном пакете.
> Обычно вспомогательные скрипты, не требующиеся для основной части пакета, но
> привносящие дополнительные зависимости, упаковывают в подпакет.
> 
> > /bin/env - опечатка из
> > https://github.com/linux-test-project/lcov/blob/v2.3.1/tests/gendiffcov/
> > simple/annotate.sh.
> 
> В таком случае нужно исправить опечатку, а не отфильтровывать зависимости с
> помощью
> +%filter_from_requires /\/bin\/env/d
> 
Учту.

> > Дальнейшие изменения в коммите 'Update version, fix tests' мне кажется
> > достаточно раскрыты, чтобы не вызывать никаких вопросов.
> 
> Мне так не кажется.
> 
> > Все последующие коммиты являются косметическими изменениями для приведения
> > репозитория к более менее современному виду: разделение исходников и всего
> > что касается сборки пакета в .gear,
> 
> Это дело вкуса, практической пользы в этом, по-видимому, нет никакой.
> 
Логическое разделение сборки пакета и исходников. Но да, практической пользы тут нет.

> На мой взгляд, перемещение спек-файла в каталог .gear/ - это плохая идея,
> поскольку изначально этот каталог предназначался для хранения файлов,
> необходимых исключительно gear(1) для его работы.
> 
В wiki подобный подход никак не запрещается, я видел достаточно много пакетов которые его практикуют, к примеру:
Lua:
https://git.altlinux.org/gears/l/lua5.4-module-say.git?a=tree;hb=e21ebf31c01e31996b74f0020e7a696e6882564a
Rust:
https://git.altlinux.org/gears/o/otree.git?p=otree.git;a=summary
https://git.altlinux.org/gears/s/systemctl-tui.git?a=tree;hb=31d7c92abc0a7b1df807eb2185c342391f6a07d7
Python:
https://git.altlinux.org/gears/p/python3-module-django-bulk-signals.git?a=tree;hb=43f24e3dfe841dbe372d55b7ed662d90419990ea
C:
https://packages.altlinux.org/ru/sisyphus/srpms/yascreen/3227805507632080711
Meson:
https://packages.altlinux.org/ru/sisyphus/srpms/tuner/3227848429817629884
https://packages.altlinux.org/ru/sisyphus/srpms/pinit/3227568679405056171
Кроме того я наблюдал случай вендоринга в прямо .gear/. Если такое поведение является нежелательным, наверное стоит поднять обсуждение в рассылке, но лично я ничего плохого в этом не вижу. Не смотря на то что .gear предназначается для исключительно для gear, само существование этой директории говорит о том, что всё что внутри неё не относится к исходным текстам проекта. Таким образом, риск того что, что-то что будет лежать внутри .gear будет конфликтовать с репозиторием - минимален. Поэтому такой подход позволяет довольно просто и явно разделить исходники и сборку. 

> > добавление gear/remotes
> > https://www.altlinux.org/Gear/remotes и сборка из тега, чтобы уменьшить риск
> > случайно собрать пакет не соответствующий релизу.
> 
> Такая схема сборки тоже имеет право на существование, но надо иметь в виду,
> что в предлагаемом варианте несколько сложнее собирать пакет из снапшота
> либо с изменениями.
> 
На мой взгляд, лучше чтобы мейнтейнер явно указывал сборку из снапшота, нежели чем  каждый раз при работе с репозиторием имел риск собрать поломанный и потенциально небезопасный пакет.

> > Пожалуйста, укажите конкретные моменты которые стоит подробно расписать,
> > потому что всё что мне показалось недостаточно раскрытым или всё что не
> > может быть получено из контекста я прокомментировал в спеке.
> 
> Перемещение
> %define _unpackaged_files_terminate_build 1
> в первую строчку спека не делает его лучше.
> 
Я потратил десять минут пытаясь найти этот макрос в спеке. Многие чужие пакеты, которые я смотрел определяют глобальные макросы именно в первых строках, что в значительной степени упрощают восприятие параметров сборки пакета. На мой взгляд всё что относится к пакету в целом должно быть на самом видном месте, чтобы другим мейнтейнерам не приходилось тратить своё драгоценное время. К тому же причин по которой этот макрос располагается именно там нет.

> > +# Replace with correct path to bash, so apt won't complain about inexestent dependency.
> 
> Предлагаю при написании текста на английском использовать spellchecker.
> apt упоминать не обязательно.
> 
> > +find . -type f | xargs sed -i 's|/usr/bin/bash|/bin/bash|g'
> 
> Такие изменения обычно делают в секции %prep, сразу после установки версии пакета.
> 
Они находятся в секции %prep сразу после инициализации версии утилиты.

> > +# Unset ocassionally stored variable
> > +unset SOURCE_DATE_EPOCH
> > +make clean
> 
> Непонятно, какая задача решалась таким образом, но решение в любом случае
> выглядит неправильным.
> 
К сожалению, SOURCE_DATE_EPOCH конфликтует с переменной используемой утилитой. Написанные разработчиком тесты ожидают что данная переменная будет неинициализирована иначе, в противном случае один из тестов падает. По этому поводу я заводил issue в апстриме на что разработчик посоветовал мне добавить make clean перед запуском:

> You may want to run make clean as well - just in case there is some leftover shrapnel that is getting in the way. 
Источник: https://github.com/linux-test-project/lcov/issues/403
Другого способа решения проблемы я не вижу.

> > +%_datadir/lcov/support-scripts
> > +%_datadir/lcov/example
> > +%exclude %_datadir/lcov/tests
> 
> Каталог %_datadir/lcov/ в результате оказался неупакованным.
> 
> > +%_libexecdir/lcov/lcovutil.pm
> 
> Каталог %_libexecdir/lcov/ в результате оказался неупакованным.
> 
Учту.

> Отдельный вопрос в выборе каталога, предлагаю посмотреть, куда пакуют
> LIB_DIR этого пакета в других дистрибутивах.
Если исходить специфики упаковки perl пакетов в нашем дистрибутиве, то они должны паковаться либо в %perl_vendor_privlib либо в %perl_vendor_archlib.

(Ответ для Dmitry V. Levin на комментарий #16)
> (In reply to Сергей Жидких from comment #15)
> > (Ответ для Dmitry V. Levin на комментарий #12)
> > > С другой стороны, если значения не отличаются, то налицо избыточное
> > > дублирование, которого желательно избегать.
> > 
> > По этому поводу есть следующий параграф на вики:
> > > В случае, если проект не имеет отдельной страницы с информацией о нём,
> > > а лишь git репозиторий, например, на github, то не стесняйтесь указывать
> > > ссылку на него и в Url, и в Vcs. С точки зрения пользователя это дублирование
> > > информации, но с точки зрения сервисов, которые используют эти теги,
> > > это совсем не так. Url и Vcs это разные объекты, даже совпадение которых даёт
> > > какую-то информацию о проекте.
> > Источник: https://www.altlinux.org/Spec#Совпадение_значений_тегов_Url_и_Vcs
> 
> В таком случае следует исправить wiki. Например, можно предложить
> использовать %url в определении Vcs.

Это не в моей компетенции.

(Ответ для Dmitry V. Levin на комментарий #17)
> (In reply to Dmitry V. Levin from comment #13)
> > (In reply to Сергей Жидких from comment #11)
> > > /bin/env - опечатка из
> > > https://github.com/linux-test-project/lcov/blob/v2.3.1/tests/gendiffcov/
> > > simple/annotate.sh.
> > 
> > В таком случае нужно исправить опечатку, а не отфильтровывать зависимости с
> > помощью
> > +%filter_from_requires /\/bin\/env/d
> > > +find . -type f | xargs sed -i 's|/usr/bin/bash|/bin/bash|g'
> 
> Кстати, обратите внимание на
> https://salsa.debian.org/mckinstry/lcov/-/blob/debian/latest/debian/patches/
> interp-paths.patch

Спасибо.

Я внёс необходимые изменения: https://packages.altlinux.org/ru/tasks/381651/

За время своего вступления мною было собрано 22 пакета и исправлено 3, подпадающие под различные схемы сборки и политики. Были собраны пакеты на языках Lua, Rust, Perl, Python и C, а также пакеты не подпадающие ни под один из языков.

Чтобы не затягивать процесс вступления и не тратить время рецензента на просмотр всех пакетов, я выделил следующие группы пакетов, которые выделяются из общей схемы сборки:

Два фреймворка на lua с кольцевой зависимостью друг на друга:
https://packages.altlinux.org/ru/sisyphus/srpms/lua5.4-module-penlight/
https://packages.altlinux.org/ru/sisyphus/srpms/lua5.4-module-busted/

Пакеты подпадающие под shared libs policy на языках Rust и Lua:
https://packages.altlinux.org/ru/sisyphus/srpms/resvg/
https://packages.altlinux.org/ru/sisyphus/srpms/lua5.4-module-luasocket/

Пакеты с некоторыми особенностями:
https://packages.altlinux.org/ru/sisyphus/srpms/cmark-gfm
https://packages.altlinux.org/ru/sisyphus/srpms/minegrub-theme/

Думаю, пора искать рецензента.

T/J/M -> 4.0.

Привет! Прошло уже полгода. Очень хочется взять на себя сопровождение rust и полноценное менторство. Очень не нравится отвлекать коллег по тривиальным изменениям в сопровождаемых пакетах. Какие на данный момент существуют препятствия для поиска рецензента?

Здравствуйте, я ваш рецензент. Начинаю смотреть то, что вы указали в https://bugzilla.altlinux.org/show_bug.cgi?id=50906#c22 . Взаимодействовать со мной можно по почте manowar@.

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

P. S. Да, желательно, чтобы собранный по этому моему запросу пакет сопровождался и дальше. ;-)

(Ответ для manowar@altlinux.org на комментарий #26)
> Сергей, мне всё понравилось. Пакеты собраны чисто и аккуратно, видно, что вы
> собираете и упаковываете программы по отработанной схеме. Но именно потому,
> что пакеты однотипны, я хочу попросить вас собрать что-нибудь, что а) имеет
> предназначенный для системного администратора набор конфигурационных
> параметров (обыкновенно в виде конфигурационных файлов), б) выполняется от
> системного пользователя. Это может быть классический демон, если не все они
> ещё собраны в Сизиф. Важно, что такие программы встраиваются в систему,
> взаимодействуя с другими программами, и они должны делать это грамотно. С
> этим связаны некоторые особенности их упаковки.
>
> P. S. Да, желательно, чтобы собранный по этому моему запросу пакет
> сопровождался и дальше. ;-)
Здравствуйте! Попробую что-нибудь найти, но в голову пока ничего не приходит. Мне больше всего интересны утилиты связанные с исследованием и генерацией кода (компиляторы, дебаггеры, профилировщики, фаззеры и тд.) преимущественно для языков Rust/C и утилиты работающие в пользовательском пространстве. Из последнего такого я собирал tracy https://packages.altlinux.org/ru/tasks/417727/. 

Это многофункциональный профилировщик кода работающий по клиент-серверной архитектуре с поддержкой профилирования кода на C/C++/Python/Fortran и пользовательской поддержкой Rust, Zig и других языков.

Поспрашивал знакомых, - посоветовали https://github.com/deckhouse/prompp. Это форк Prometheus с меньшими требованиями к оперативной памяти. По требованиям подходит, но боюсь что его сборка займёт очень много времени. Там используются npm и bazel, которые насколько мне известно не очень дружелюбны к вендорингу.

Мда... Естественно, я думал что-то гораздо более простое. Tracy посмотрю.

Сергей, могу предложить творческое задание — упаковать реле для дельта-чата (вещь в современных условиях очень полезная):

https://github.com/chatmail/relay/

Творческая часть заключается в том, что, судя по документации и беглому просмотру кода, установка и настройка этой программы (программ) осуществляется специально написанными скриптами (aka deploy scripts). То есть, по-моему предполагается, что администратор будет запускать эти скрипты после установки пакета. Но такой подход, когда пусть даже и проверенные упакованные скрипты вносят изменения в системные конфигурационные файлы на живой системе имеет свои недостатки и, вообще говоря, не является традиционным для пакетной системы. И даже при сборке контейнера (то есть для установки без возможности обновления и удаления) это не всегда удобно. Однако у меня есть предположение, что нужные конфигурационные файлы с разумными значениями по умолчанию можно получить при сборке пакета и потом просто упаковать. Но, естественно, никакой гарантии на этот счёт нет, поэтому задание творческое.

Вы можете отказаться и предложить что-то своё абсолютно без всяких последствий для рецензирования.

(Ответ для manowar@altlinux.org на комментарий #29)
> Сергей, могу предложить творческое задание — упаковать реле для дельта-чата
> (вещь в современных условиях очень полезная):
> 
> https://github.com/chatmail/relay/
> 
> Творческая часть заключается в том, что, судя по документации и беглому
> просмотру кода, установка и настройка этой программы (программ)
> осуществляется специально написанными скриптами (aka deploy scripts). То
> есть, по-моему предполагается, что администратор будет запускать эти скрипты
> после установки пакета. Но такой подход, когда пусть даже и проверенные
> упакованные скрипты вносят изменения в системные конфигурационные файлы на
> живой системе имеет свои недостатки и, вообще говоря, не является
> традиционным для пакетной системы. И даже при сборке контейнера (то есть для
> установки без возможности обновления и удаления) это не всегда удобно.
> Однако у меня есть предположение, что нужные конфигурационные файлы с
> разумными значениями по умолчанию можно получить при сборке пакета и потом
> просто упаковать. Но, естественно, никакой гарантии на этот счёт нет,
> поэтому задание творческое.
> 
Мне не нравится сильная любовь разработчиков к хардкоду и использованию подключения по ssh к руту.

Как я понимаю, проект состоит из шаблонов конфигураций сторонних сервисов таких nginx, mtail, iroh-relay, dovecot и тд. и скриптов для их настройки. Без пользовательского вмешательства они не представляют никакого интереса.

> Вы можете отказаться и предложить что-то своё абсолютно без всяких
> последствий для рецензирования.
iroh-relay (https://github.com/n0-computer/iroh/tree/main) проект написан на Rust и предоставляет реле для защищённого подключения в децентрализованной сети или 
https://github.com/google/mtail предоставляет сервис для мониторинга приложений.

(Ответ для Сергей Жидких на комментарий #30)
> iroh-relay (https://github.com/n0-computer/iroh/tree/main) проект написан на
> Rust и предоставляет реле для защищённого подключения в децентрализованной
> сети

Хорошо, давайте его.

https://packages.altlinux.org/ru/tasks/421579/

Маленькое замечание: я бы, всё же, явно проверил, что пользователя и группы нет и тогда создавал, а не просто игнорировал (любые) ошибки через "боян".

Если вы писали часть, касающуюся пользователей, на основании https://www.altlinux.org/Pseudo_User_Policy, то, вероятно, стоит поправить вики.

А так я увидел, что хотел, спасибо!

Работоспособность пакета проверять не буду: если он не заработает, вам напишут об этом в багзиллу. Удачи!

(Ответ для manowar@altlinux.org на комментарий #33)
> Маленькое замечание: я бы, всё же, явно проверил, что пользователя и группы
> нет и тогда создавал, а не просто игнорировал (любые) ошибки через "боян".
> 
> Если вы писали часть, касающуюся пользователей, на основании
> https://www.altlinux.org/Pseudo_User_Policy, то, вероятно, стоит поправить
> вики.
> 
> А так я увидел, что хотел, спасибо!
> 
> Работоспособность пакета проверять не буду: если он не заработает, вам
> напишут об этом в багзиллу. Удачи!

Спасибо!

Пользователь добавлен в группу мейнтейнеров.

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