50906 2024-07-15 12:22:09 +0300 [4.0] join rx1513@ 2026-02-21 16:22:49 +0300 1 1 4 Development Team Accounts join unspecified all Linux ASSIGNED P5 normal --- 1 1lion23550 glebfm dutyrok dutyrok glebfm ldv rauty rx1513 writers cas oldest_to_newest 248852 0 1lion23550 2024-07-15 12:22:09 +0300 Псевдоним: Rx1513 E-mail: 1lion23550@gmail.com Ментор: Александр Шашкин ( dutyrok@altlinux.org ) Хочу научиться собирать пакеты 248864 1 1lion23550 2024-07-15 15:15:55 +0300 (Ответ для 1lion23550 на комментарий #0) > Псевдоним: Rx1513 Псевдоним rx1513 248953 2 16440 1lion23550 2024-07-17 10:24:34 +0300 Created attachment 16440 gpg ключ 248954 3 16441 1lion23550 2024-07-17 10:25:16 +0300 Created attachment 16441 ssh ключ 248955 4 dutyrok 2024-07-17 10:27:50 +0300 (Ответ для 1lion23550 на комментарий #0) > Ментор: Александр Шашкин ( dutyrok@altlinux.org ) Согласен быть ментором. 249490 5 dutyrok 2024-07-31 13:49:15 +0300 За время ожидания кандидат освоил инструменты сборки и собрал несколько пакетов локально. Так что считаю, что кандидат готов собирать пакеты на сборочнице. Если так можно, то чтобы не терять время, предлагаю сразу выполнить все шаги join до 3.6. 251025 6 glebfm 2024-09-02 17:54:53 +0300 Ментор есть, ключи в порядке. T/J/S -> 1.3. 251052 7 glebfm 2024-09-02 19:17:45 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 253684 8 dutyrok 2024-10-30 17:14:42 +0300 > Если так можно, то чтобы не терять время, предлагаю сразу выполнить все шаги > join до 3.6. T/J/M -> 3.0. 253865 9 glebfm 2024-11-01 18:24:59 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6. 268231 10 ldv 2025-07-02 13:46:10 +0300 Меня попросили посмотреть 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". Про каждую зависимость, добавленную вручную, напишите, откуда именно она берется. 268266 11 rx1513 2025-07-03 10:58:43 +0300 (Ответ для 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 и сборка из тега, чтобы уменьшить риск случайно собрать пакет не соответствующий релизу. Пожалуйста, укажите конкретные моменты которые стоит подробно расписать, потому что всё что мне показалось недостаточно раскрытым или всё что не может быть получено из контекста я прокомментировал в спеке. 268279 12 ldv 2025-07-03 12:28:43 +0300 (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 С одной стороны, странно, что значения этих тэгов отличаются именно таким образом. С другой стороны, если значения не отличаются, то налицо избыточное дублирование, которого желательно избегать. 268285 13 ldv 2025-07-03 13:20:12 +0300 (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 этого пакета в других дистрибутивах. 268286 14 ldv 2025-07-03 13:27:01 +0300 (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, который вы, как я полагаю, всё-таки не пакуете. 268287 15 rx1513 2025-07-03 13:33:17 +0300 (Ответ для 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 268295 16 ldv 2025-07-03 15:28:43 +0300 (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. 268297 17 ldv 2025-07-03 16:13:18 +0300 (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 268311 18 rx1513 2025-07-03 17:01:04 +0300 (Ответ для 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. 268312 19 rx1513 2025-07-03 17:04:03 +0300 (Ответ для 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. Это не в моей компетенции. 268313 20 rx1513 2025-07-03 17:04:36 +0300 (Ответ для 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 Спасибо. 269635 21 rx1513 2025-07-22 16:30:58 +0300 Я внёс необходимые изменения: https://packages.altlinux.org/ru/tasks/381651/ 270516 22 rx1513 2025-08-06 13:24:59 +0300 За время своего вступления мною было собрано 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/ 270518 23 dutyrok 2025-08-06 13:46:55 +0300 Думаю, пора искать рецензента. T/J/M -> 4.0. 282434 24 rx1513 2026-02-21 16:22:49 +0300 Привет! Прошло уже полгода. Очень хочется взять на себя сопровождение rust и полноценное менторство. Очень не нравится отвлекать коллег по тривиальным изменениям в сопровождаемых пакетах. Какие на данный момент существуют препятствия для поиска рецензента? 16440 2024-07-17 10:24:34 +0300 2024-07-17 10:24:34 +0300 gpg ключ rx1513gpg2.pub application/vnd.ms-publisher 3910 1lion23550 LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdhVStNZ0JFQURXaXRR OER5ektKUE10U0xYbE9lNzl2RXdBT216YjhiL1kyekxRYm40bzVDcENBelFBCmMxYU5DZ2ZhSzkv ZVdBNHJSWFF0QkxPVGhoWTJKSjZUVnVjaCtTQ3lkT1dMRVdQSjRlUlJtVkorOXdEN0dRZ0kKQ1Zv RnFKTG5DUVJjcGxoamJCbllaOHdWOXUyRFo3TTJDR2JrTHdheUtZZEoyVFMvV21QVmFybFB1dFcy VlFqZApuMFVhV2dod0RnTjlyUFZHMXg2YzFEZjVhZkVKTkZ1SXJJZFd3SHdvN0pzQzJva3NmSlB3 MDJrQVV5UGl3UTlvCmdjOHp5NERoMWhUejB5c2ZSTDBsOHJxaW9vRjhUUWtVSEpvK25rcERSM3ph TUNEQU5NN0VJME52UWJ3c2FxZTIKWFVJTExMbVJrN21UT2NJSTB4NlBHQmpUdVYrdEs2bXNld21J Q2JYSlo3bVBHazl0RWs4VDVidDV0RjkrRU1KcwpGTk5vUi9FSUtPTWw2WGdRRmJsdytydGV1NUc5 RnJaV3FQcTIwUmJ2czhsUUxGVzFGRGZad0RRaVNxaUVzNmE4CmdqVTIvZ3ZDM1JxL2Y1MnBpV0F6 bTJTU3M5TytuYWhpbXdQQmU5dzFQQk8rVDhKbUNNdTNKMmVRUTNGem51WFcKUERBRzRSb3BvNWZI dzgvQUsyVkVLVmJacEtwSXYyR2JTZDcyaThxNUsrSUJnSnVydmxwQ0l3ZnhvNjFKRDVqSApJa1Ax T09CMFRZWTVtRjkwMS8yWFRCa1I1VTdNclJvV0RDbCt0ZGNja2djQ3lwR0ZGV1hnNi9iSWR6QWN2 QjE4CjBXYmpUSzV5NWpVSm5tS240bkRaUUtPVjBZais3TzNKWnRvK0gvdk9nZHV4Yyt5TTF5bUVq Q3R0NVFBUkFRQUIKdENSVFpYSm5aWGtnV21ocFpHdHBhQ0E4Y25neE5URXpRR0ZzZEd4cGJuVjRM bTl5Wno2SkFrNEVFd0VJQURnVwpJUVNwUzNXUkJtM1dHQWg1WFRGeWMzRnd5by9qMUFVQ1pwVDR5 QUliQXdVTENRZ0hBZ1lWQ2drSUN3SUVGZ0lECkFRSWVBUUlYZ0FBS0NSQnljM0Z3eW8vajFPejNF QUNUQ2xHdGRiWWE1VTVIR0dpNVZQUElnTCtsSjZtWjVNRWsKOGw4c2hMQTdEQTRzTTVlMVdOSlJU SUVKY3dWU1h2TkNiaWNpNlRiWXpIaWZ1V1RxZEpaUHd5ak10anZJYTJwMgpVa0RkeU5ESHRIYjZq TWpEcVhuc2pScERzdk82L2w5dFZPTUNZSnVUWVM2azBrYmpxVThYVzNoVVdiRldqZzJ6CnlUR29P aG03NVNCRGx6TWpEYmthR3ErSC81RTlhSi9ZMjZYZzMzMU9UK0NhNHdwUEFDWmhhc2R2ZUtlT1RN UWQKT25xZXdqOGQ4V0xvdmcyellZYlNBbXpHWUs4WXlLT0NUdit1V2NMM3RrR0dmdExHbHRXUFhL N3QyTkRTK0krTApocjBHRHlJekl3bU02YVZvTlRVT1RHN3JhNHpqSFBIQ2hRMEtIU3k1MHVvd1FU MU9xeCtxY28yMms0REwyU21SClFEZzdmYUpleXZkWFY3cHU3QnZIY0NhZHNXbGFvZlljWnc3Z0hZ S0JpRFNTL3VoUnhnNXdJQ0I2YTFvZVk5VXQKNmI0TXBsdVoyY0Y3aStiYzJMb1VDK0J0V3ROUDVs K3ZpR2tXUmVxOHEyMXJVZEJKRXhSK3FVcGhZRDgzVUhNOQoxUEhDbjA4TE01VXJCTnR0dmRwT0FM MnJubXdrUUY5QVcvRlFNMHkyKytPYVN5L1gvN3FmQWZRejJPTnZrazZzCnhDekE5aThodjNNZWlM cUF4K085QW1md1IrVkc1TVFBZDdTUllXRDNLUVQ0OW4rckdGQmJPU3pLOHQ1bTc2Y20Kamxjd3dW YWU2eGsxNFhMQ0N3VEFDSzBJVEhvYkZwa0RjcVY1MklLUUtuTndycUg1dWZDVzN0SEh6OFZoSUZ5 QQpOTURoRlZ4TzlMa0NEUVJtbFBqeUFSQUFtSVhlbEptcU56WFpuSWFHaWdOVnN3eWMrdVNlYnZx OUNQL3pTZlI1ClYyQmNERkZCb2wrdXJCM0VXYk52RVA1ZUV0Q1YrcUxac0NpZmZ6UlhxMk4zTXpW Q3FRRTgxSTN6bjJRZnFoTzcKbTBFMEFGdEhnd1U4U01kbUlhd05Wb3BocGNIRTRCUWdmLzNzNS9F RmQrcUVWYjZiK0J5T3QxWFhoV2QySm9tdgorTnBxd0NIWWp3VjdvM01jcjRMVGFUaVhHTE9XWVUw aHBsaVhlV2haRVpZQmJHMkhqQlZtT1pmSkJCUkRsbTFBCk5NaEtETVRtamNrUHZWS3VVZE91aWVJ WlB1Q21aTEM2ME02bUxxZUdBSUFzMkxKUThHa3Q5RzBGNE9BTGpVUHkKUzQ4dEtHQ3g3TkV0WE51 aHh4L0hGOVA0YmtwclJQUjVvMDY2UmdFOHNGVGtLZXNKbHU4YWpINUhvNFZ3Z0dDYQpER2xEWWVi REdDWmxPajlFaGgzQXJPMndhY3hYck9wRjBvQThVTkU1aWdNckVXUkVNRzh0bWtTNm5LTjlVYnFK CjVmWEE1N0ZxSkFxWXNxZ0VIWGpySjY3c2NyVXBaSmVzWEJnYVhmN25ES1VXNzN4SnJhOWJ3MUJB bXVFNXk5aUoKLzVmYUk4dEVWbGpzNGtKQi9kYm1YdFRCa0tDWGdBTDhKWXkwZU1kL2UwWlRRUGJh MEd0by8rTFhydTFUSUx4dwpmYnZ0M0Y2OWVHRGhXSjNSMUpWZTNGNXNqYjc4MnhKcGxFV0lLbW9Q ZFllSytzb2ZhalZqSVQ0SkZoRFUvSUlGClBUTjBSRmlMTC9jRXVSNlBmQnRsRDRYcHJiZWxlamFD SUc3b2VCTU1meCs1RCtRSFBPbG9DNEMrVjk2ZnBsU24KSktVQUVRRUFBWWtFY2dRWUFRZ0FKaFlo QktsTGRaRUdiZFlZQ0hsZE1YSnpjWERLaitQVUJRSm1sUGp5QWhzQwpCUWtEd21jQUFrQUpFSEp6 Y1hES2orUFV3WFFnQkJrQkNBQWRGaUVFd2kxU1JIMXpFRVJKR0c0U3FqcldNMmdDClY4SUZBbWFV K1BJQUNna1FxanJXTTJnQ1Y4TEVWQS8rTjkzVTFoZVVPb3FGYVN3dmozRDV0cFZndmNqWUdoa3UK K0ZNemFhQlRnK29UQmt3bGZZYlM5cko3ZTYyNTNkODFkNWRjTTZya0UxWE5XOUp1c1liMGZITXJ2 Sk9yenFiNgpRb0Q1TEc5YXV0WDlmYmhGT2JsYjRhcFprMjJQTHh6VUhyY0haS25vcHlDcFFBWDh1 aHoraWRhQitqZUp1SjQ1CnlwTWFaZWo4ZVRxSnlWRFFzQ21aS3BDdGVVQ2lUdENJQVVGK3plRDds NGdDT2JWMFM4VWljYmpYVmFGWFZXbWQKQnhZbC8vTW1qaWV6Z21oTzFHOFhSbk01MnF3NGlMV0Zl MmhHcEdjSVlCUmhwMkgraGVZbk00dzN4RmRpUGpLYgoyUkJwaTY0YTRnNmh4cndqNnZ0LzYzYjFT b2VheU56clA5OFV5a3JmcmVOd1YzUjJjNGpkalhOS1Qzc3pZTHhwCitjY3MxbjRVbUFSVjhqS256 MUpYWVE5MVdCdXRnbTZjaitFSlh5YkFmUlB0bHJFV3pFRWhBWVNKaCtZYS9QYmYKWk5uTjQxREZj aHFQam81Tlo0TC82YW5na2E4VlE3WEdlK25VZCtXL0NybEkwMllQNVBmczhFdXU0U29ldW0zbQpq aGtYOXhwNU1ERmV6bWZoYmxUMElYWVczaFR1c0ZtcTlaLzBkeHRSRFhXMWxyQ1hQOFNNL2NpbEMr Rm9ocjFxCkY0aExxY09TcEZoZUpwSUJGMDhvMGNPMmFiRGdzVDhteVlYVzNFOUsvbkZ4Uy93T2RB L0o4dDhzbElNL2l2WlAKUTBPWXJxdlFiZlZXSllaUVRIWHpZQzIwckJia1RGTy9pM0RuQi9wd3Bv dHBOby9Ed3VhSWkwSW90ckIyNlUvWApOMlFQUUVlREk1cTBVQkFBdDRnZ1lrWXBUc2VFZHlFNHg4 SlBYMFhvbnNYbGVzQ2x1U2Zpc3g4OUh2blBPNHZVCi9tNmU4QjhteDVDOWhITDZLTlNzaVk2ZCtw cmNVSWhKRllWZWRkdWt2blpqS01WQlpGR3U3a0wwSGlhVUxNOEoKbWZoUld2M0xTd0tCQlZNRXZS TU43YnNDU3o3em1JbHFPbmorUU5mUGw4aHJ1YUV5cWN4ak5zcHBkcUp1Sm02LwpKMnZ3TTk4dlcv WG50RU1RclA0QVNvam9pUitPVEZiZkpZQjBaNnZPaHYrSVpqekYvaXlzbWlHZHFkeHZ0U3FLClll UjlrUEJZc3RMdmlNaXcyZ0VzNmZGZ2xlS01zR0VGZFdQOG16UG14TmdXTDdJaWliL1l0ZlZtb09z b0lXZE4KSlI5VDd2SlhITTRTdS9jY2VqTko5V0tpNDZCM3NMeFB0QnQyZ0diVFhyYURxTHhXbVNT dnFGL0pNbWJSaTM5YQp2SkFUSjBJMVRlYUk5c3M0NmxsbEh5YW01ajZoL25MZ1NJL2RXMHhnVGtB RmFMeHd3K1FNZUhnbjRzV3RuQnovCnErV2R2YjRxNENRQ3ArRFFyRk1jb24wblJkcTR5NUZuUXo5 dG5VMysxVFFMVE9jZjlRd2VlS053YU1qenpsUGQKbEZVZnlMeC9UM2Ewc3lXWjROb2hKQTlOVTcy bGd4dEtBdjdrZlZ2ZWxWQVVpbDFsOS9TL3FmUXB5NGp4SU92eApCdWY4dTZ5YzBDaVMycHN0cENQ aDRBSWkzSjNTdkdiem9ya1FQQ0R0QW9IZmI2NGZUL3E3MENMTGk5M3JybkdICksvdks2MWxhN0hx Sm5UclpjVGZSOWV4OWZWTUdJRmtPVTNQRFJDYXVHNHM4TWZKSzN6bWZTbUNFRTgwPQo9UDBJdgot LS0tLUVORCBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg== 16441 2024-07-17 10:25:16 +0300 2024-07-17 10:25:16 +0300 ssh ключ rx1513ssh.pub application/vnd.ms-publisher 97 1lion23550 c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUgvcGRBNWYvZW1kNHBwN1B2M1E3 UVJQT0FpTmVqZHVQQ1NGSy90S2J2MTIgZ2VuZXJhbEBzZXJ2ZXJlCg==