Summary: | [4.2] join smasher@ | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Team Accounts | Reporter: | Vladislav Glinkin <glinkinvd> | ||||||||
Component: | join | Assignee: | Gleb F-Malinovskiy <glebfm> | ||||||||
Status: | ASSIGNED --- | QA Contact: | Andrey Cherepanov <cas> | ||||||||
Severity: | normal | ||||||||||
Priority: | P5 | CC: | ancieg, arseny, glebfm, ldv | ||||||||
Version: | unspecified | ||||||||||
Hardware: | all | ||||||||||
OS: | Linux | ||||||||||
URL: | https://altlinux.org/Team/Join | ||||||||||
Attachments: |
|
Description
Vladislav Glinkin
2023-03-14 19:35:45 MSK
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. :) (Ответ для Arseny Maslennikov на комментарий #21) > В общем: > - жду ответов на вопросы; > - хочу увидеть хотя бы 1 собранный не-noarch пакет на базе традиционных > кросс-языковых систем управления проектом (meson/cmake/autotools); например, > https://github.com/wolfpld/tracy был бы не самым бесполезным пакетом; > - как уже писал выше, хочу увидеть обновление какого-нибудь пакета на > rust-cargo, раз уж вам интересны пакеты на rust. :) Арсений, здравствуйте. Хочу поблагодарить вас за вашу рецензию. Узнал для себя что-то новое и сделал выводы. 1. Обновление rust пакетов: https://packages.altlinux.org/ru/tasks/343071/ https://packages.altlinux.org/ru/tasks/343619/ https://packages.altlinux.org/ru/tasks/343843/ При обновлении данных пакетов произвёл очистку зависимостей вендора от бинарных артефактов. Все подробности и изменения можно просмотреть в гите (старался делать информативные коммиты). 2. Собрал tracy по вашей просьбе, однако пакет на данный момент не попал в сизиф (находится на ревью у ментора). Сборочное задание: https://packages.altlinux.org/ru/tasks/343948/ 3. Ответы на вопросы. > Обоснуйте, пожалуйста, выбор gear-схемы. Если бы в пакете гипотетически появилась необходимость исправлять исходники, как вы бы это оформили? На примере pem'а я тренировался собирать пакет с исходниками в виде тарболла с помощью gear. Правку исходников я бы оформил в виде патчей, полагаю. > Пожалуйста, обоснуйте, почему вы выбрали именно такой способ поправить setup.cfg. (babi) Пакет собирался из тэга, но на момент сборки пакета, в основной ветке upstream'а setup.cfg уже был исправлен. Принял решение поправить недочёт в setup.cfg с помощью sed'а в спеке (с соответствующим комментарием), так как в следующей версии пакета данное исправление не понадобится и строчку из спека можно будет удалить. Почему-то такое решения мне показалось самым простым. Дополнительно собрал: https://packages.altlinux.org/ru/tasks/344421/ https://packages.altlinux.org/ru/tasks/344504/ |