Created attachment 12742 [details] SSH Public Key Псевдоним: glinkinvd Почта для пересылки: VladislavDenisov2002@mail.ru Имя ментора: ancieg Цель вступления: Научиться собирать и сопровождать пакеты
Created attachment 12743 [details] GPG Public Key
(Ответ для Vladislav Glinkin на комментарий #0) > Имя ментора: ancieg Согласен быть ментором.
> Псевдоним: glinkinvd UPD: В качестве псевдонима хочу использовать: smasher Прикрепляю изменённый публичный GPG ключ
Created attachment 12759 [details] GPG Public Key
(Ответ для Vladislav Glinkin на комментарий #3) > > Псевдоним: glinkinvd > UPD: > В качестве псевдонима хочу использовать: smasher > Прикрепляю изменённый публичный GPG ключ ОК. Просьба сразу выдать доступ к gitery.
Ключи в порядке.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
Прошу выдать доступ к gyle.
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
На данный момент собрано: https://pypi.org/project/onigurumacffi/ https://pypi.org/project/remote-pdb/ https://pypi.org/project/babi-grammars/ https://pypi.org/project/babi/ в https://packages.altlinux.org/ru/tasks/328594/ https://crates.io/crates/hunt в https://packages.altlinux.org/ru/tasks/328085/
UPD: Новые, собранные пакеты https://crates.io/crates/procs в https://packages.altlinux.org/ru/tasks/326698/ https://pkg.go.dev/github.com/six-ddc/plow в https://packages.altlinux.org/ru/tasks/326695/
Новые пакеты: https://onefetch.dev/ в https://packages.altlinux.org/ru/tasks/326691/ https://www.gnu.org/software/pem/ в https://packages.altlinux.org/ru/tasks/326612/ https://pkg.go.dev/github.com/cenkalti/rain в https://packages.altlinux.org/ru/tasks/332277/
Думаю, что пора звать рецензента.
Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.
Призван рецензент (arseny@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
(In reply to Gleb F-Malinovskiy from comment #15) > Призван рецензент (arseny@) для независимой оценки готовности кандидата. > > T/J/S -> 4.2. Посмотрю на этой неделе.
Ну что ж, потихоньку начнём. :) pem --- В спеке в %files ман-страницы указаны как `.1.xz`. Лучше `.1*`, потому что тип сжатия ман-страниц может измениться независимо от вашего пакета (и суффикс вместе с ним). Например: %_man1dir/*.1* В пакете, например, onefetch это (формально) учтено, поэтому в ошибки упаковки не записываю. Но фрагмент имени про секцию лучше синхронизировать с номером секции в подкаталоге %_datadir/man, чтобы ловить у апстрима несовпадения. Придирки: * файл pem.txt с примером CSV-базы, видимо, является демонстрационным и для работы программы pem(1) не нужен, но апстрим его кладёт под %_datadir и, вероятно, более не занимается проектом. Я б его переложил под директиву %doc. (впрочем, пакет заработает и без этого). * вы зачем-то его переименовываете в example.pem, хотя программа сама не заканчивает имена файлов под ~/.pem этим суффиксом. Такой суффикс часто применяют для хранения реальных файлов PEM — base64-подобный контейнерный формат для блобов, например, x509-данных: ключи шифрования, сертификаты, ..., или блоков с цифровой подписью, проч. Формат PEM и это соглашение гораздо более популярны, чем GNU Pem. Я б не стал так делать, можно назвать example.txt, например. Да, реально отличать файлы стоит по сигнатурам их содержимого, но выдумывать соглашения за апстрим, полагаю, ни к чему. Вопрос _к кандидату_: Обоснуйте, пожалуйста, выбор gear-схемы. Если бы в пакете гипотетически появилась необходимость исправлять исходники, как вы бы это оформили?
onefetch -------- Коммит, где фиксируются cargo-зависимости, называется "dependencies for version N"; в этом названии нет сказуемого, создаётся ложное впечатление, что зависимости есть только в этой ревизии дерева и дальше пропадут. > Write your commit message in the imperative: "Fix bug" and not "Fixed bug" > or "Fixes bug." This convention matches up with commit messages generated > by commands like git merge and git revert. https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html А вот %changelog в спеке это соглашение не затрагивает; там рекомендуется прошедшее время. То же самое касается других rust+cargo-пакетов. Придирки: В тексте %description предложения лучше заканчивать точкой (ибо это небольшой, но текст), в отличие от слоганов в %summary. То же самое касается %changelog. То же самое касается других rust+cargo-пакетов. procs ----- Среди cargo-барахла нашёлся, например, крейт winapi-i686-pc-windows-gnu, полный не работающих в нашей системе `.a`. Так как наш пакет, как я могу судить после беглого прочтения, не связан с кросс-компиляцией под маздай или с анализом блобов под эту платформу, этот мусор зря занимает место в архиве; его стоит убрать по мере возможностей. Надёжного инструмента для этого нет, но есть подсказки, как это делать руками: https://altlinux.org/RPM/Rust Рекомендую проверить и другие cargo-пакеты. Придирки: аналогично onefetch. hunt — в общем, аналогично. Сегодня пакеты на базе сборочной системы cargo сложнее обновлять, чем собирать заново. Чтобы закрепить свои навыки, Владиславу стоит обновить какой-нибудь существующий пакет на базе cargo, например, один из своих пакетов. Это заодно и шанс исправить (в будущих коммитах) описанные выше малые недочёты. :) Питон посмотрю в ближайшее время.
(In reply to Arseny Maslennikov from comment #18) > Коммит, где фиксируются cargo-зависимости, называется "dependencies for > version N"; в этом названии нет сказуемого, создаётся ложное впечатление, > что зависимости есть только в этой ревизии дерева и дальше пропадут. > > Write your commit message in the imperative: "Fix bug" and not "Fixed bug" > > or "Fixes bug." This convention matches up with commit messages generated > > by commands like git merge and git revert. > https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html Например, "vendor dependencies for version N". Или update, reflect, ... по вкусу.
(In reply to Arseny Maslennikov from comment #18) > Питон посмотрю в ближайшее время. Судя по всему, модули упакованы в соответствии со следующими гайдами: https://www.altlinux.org/Python_packaging_guide https://www.altlinux.org/Management_of_Python_dependencies_sources Каких-либо нормативных предписаний по поводу Python-модулей у нас нет, так что пусть. Вопрос _к кандидату_. В файле babi.spec: > # Remove the line 'license_file = LICENSE' for setuptools (actual for version 1.5.5) > sed -i '11d' setup.cfg > Пожалуйста, обоснуйте, почему вы выбрали именно такой способ поправить setup.cfg.
В общем: - жду ответов на вопросы; - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных кросс-языковых систем управления проектом (meson/cmake/autotools); например, https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на rust-cargo, раз уж вам интересны пакеты на rust. :)