Created attachment 9613 [details] ssh and gpg public keys Добрый день! Прошу принять меня в ALT Linux Team. Мой псевдоним kotopesutility, адрес для перессылки почты kotopesutility@yandex.ru. Моим ментором прошу назначить Георгия Владимировича Курячего. Я уже несколько лет пользователь Linux и владею несколькими языками программирования, но я хотел бы научиться собирать пакеты и принять участие в разработке.
Created attachment 9614 [details] SSH-key Прошу прощения, почему-то с первого раза прикрепился только GPG-ключ
> Моим ментором прошу назначить Георгия Владимировича Курячего. Подтвержаю
(In reply to kotopesutility from comment #1) > Created attachment 9614 [details] > SSH-key Мы рекомендуем ssh ключи ed25519 или RSA >= 4096.
Created attachment 9622 [details] SSH-key Простите, вот ключ нужной длины.
(In reply to kotopesutility from comment #4) > Created attachment 9622 [details] > SSH-key > > Простите, вот ключ нужной длины. Ok. T/J/S -> 1.3.
Пора заводить аккаунты, я считаю. T/J/S 1.3 → T.J.S 2.1
ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.4.
Надо бы пакеты на сборочнице потестить, кандидат готов! → 3.0
Пакет alt-gpgkeys обновлён. T/J/S -> 3.4.
Мне кажется, Кандитат уже вполне кандидат, и пора ему подыскать Рецензента! → 4.0
ping 4.0
Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
ping Может, рецензента поменять?
(Ответ для Fr. Br. George на комментарий #13) > ping > > Может, рецензента поменять? Извиняюсь, пропустил. Если хотите поменять - с моей стороны возражений нет. Или же я посмотрю в ближайшее время.
https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=summary 1) Оформление: почему бы не объединить следующие два коммита в один? https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commit;h=dcc699335a37b835faa83cbca90526e6fae62533 https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commit;h=a69f4e6bdd7445b34ac02ad690d48c4509add21d 2) Оформление: в следующем коммите зачем-то присутствует лишний файл .gear/rules~. Он для сборки пакета не нужен и стоит его удалить. https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=dcc699335a37b835faa83cbca90526e6fae62533 3) Из spec-файла: %files /usr/bin/slurp Для путей принято по возможности использовать макросы. Т.е. "/usr/bin/slurp" стоит заменить на "%_bindir/slurp". Подробный, но не полный, список макросов и их значений можно найти здесь: https://www.altlinux.org/Spec/Предопределенные_макросы 4) Указана версия пакета 1.3.2, но пакет собирается из апстримных исходников из коммита https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=ce12cb2be7add82792211113745df0321c3cb115 в то время как тэг v1.3.2 указывает на другой коммит https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=commitdiff;h=04945facb2f16ab212bbe7069908b850f654b9fa Вот соответственно лог: https://git.altlinux.org/people/kotopesutility/packages/?p=slurp.git;a=shortlog;h=dcc699335a37b835faa83cbca90526e6fae62533 В случаях когда пакет собирается из апстримного коммита, не соответствующего апстримному выпуску, стоит указывать информацию о таком коммите в релизе пакета: https://www.altlinux.org/Spec#Промежуточные_upstream-релизы Другим вариантом решения может быть, если эти коммиты не нужны, делать сборку пакета из релизного коммита. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=summary 1) Оформление: опять же не вижу смысла не объединять эти два коммита, или же не разбить изменения другим способом: сначала в один коммит изменения в самом пакете, затем в другой коммит spec-файл и .gear/rules. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commit;h=a28e37d0040519f1acf39181221da7afb8069624 https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commit;h=e27e92a26f7a2cb462a4f310529b30d24a9f313c К тому же из тэга 1.3.2-alt1 пакет явно не соберётся, других тэгов пригодных для сборки я тоже не вижу. 2) Опять-таки стоит использовать макросы: /usr/bin/grim -> %_bindir/grim /usr/share/man/man1/grim.1.xz -> %_man1dir/grim.1* /usr/share/zsh/Completion/ALT/_grim -> %_datadir/zsh/Completion/ALT/_grim /usr/share/fish/vendor_completions.d/grim.fish -> %_datadir/fish/vendor_completions.d/grim.fish /usr/share/bash-completion/completions/grim.bash -> %_datadir/bash-completion/completions/grim.bash В данном случае, строка "/usr/share/man/man1/grim.1.xz" особенно может вызвать проблемы. Тип сжатия man-страниц ранее уже менялся, и в будущем может легко поменяться снова. Некоторые пакеты переставали собираться просто потому, что в spec-файле был указан файл %_man1dir/something.1.gz, когда из-за сжатия получался файл %_man1dir/something.1.bz2 или %_man1dir/something.1.xz. 3) Та же проблема со сборкой не из релизного коммита и не указанием этого факта в релизе пакета. https://git.altlinux.org/people/kotopesutility/packages/?p=i3lock.git;a=summary 1) Оформление: работа со spec-файлом разбита на несколько коммитов без видимых причин. Последние два коммита с небольшими доработками вполне можно бы совместить с предыдущим коммитом. 2) Оформление: непонятно зачем все исходники были перенесены в директорию i3lock. Прошу прокомментировать зачем это было сделано. 3) Оформление: #BuildRequires: libxcb-devel, libxkbcommon-devel Закомментированное не нужно оставлять и стоит удалить. 4) %attr(2711, root, shadow) %_bindir/* Такие права явно не стоит выдавать всем приложениям по маске. Сегодня такое приложение одно, в следующем обновлении их станет два, и права такие будут у обоих. Лучше явно указать конкретное приложение: %_bindir/i3lock 5) Оформление: из .gear/rules: "copy: *.patch". Я в таких случаях предпочитаю использовать "copy?: *.patch" - если файлов *.patch больше не будет, то это не станет ошибкой и не потребуется менять .gear/rules. 6) Та же проблема что и в прошлых пакетах со сборкой не из релизного коммита и не указанием этого факта в релизе пакета. Помимо этого: 1) 3 новых пакета c простыми spec-файлами и 1 пакет с обновлением. Но в пакете с обновлением из изменений в спеке - новая версия и запись в changelog. Нередко для сборки новой версии пакета требуется больше действий, и по данным репозиториям не получается понять как с этим справится вступающий. Возможно, стоит дать какой-то нетривиальный пакет на обновление. 2) Все .gear/rules - без использования тэгов и ключевых слов (keywords из man-страницы gear-rules). Непонятно хорошо ли вступающий разобрался с gear-rules. С учётом всего вышенаписанного у меня есть сомнения в готовности кандидата хорошо собирать различные пакеты в репозиторий.
Спасибо за ответ! >5) Оформление: из .gear/rules: "copy: *.patch". Я в таких случаях предпочитаю использовать "copy?: *.patch" - если файлов *.patch больше не будет, то это не станет ошибкой и не потребуется менять .gear/rules. Я оставил как есть, контролировать наличие или отсутствие *.patch я готов и, честно говоря, мне так удобнее. Остальные правки я внес, вот задание: https://git.altlinux.org/tasks/292489/
slurp: 1) К сожалению не помню как было в прошлой версии. Было ли там только 2 указанных коммита? Сейчас там всё смешано в 1 коммит. Я бы предпочёл один коммит под импорт апстримных исходников, один - под спек-файл, gear-rules и прочее содержимое директории .gear. 2) %define commit_num .9.gf4e7559 %define slurp_num 1.3.2 Version: %slurp_num%commit_num Release: alt1 Информацию о коммите сборки помимо версии обычно записывают в релиз, наподобии подобного: Version: %slurp_num Release: alt1%commit_num grim: 1) Тоже самое про перенос информации о коммите в тэг Release. 2) Неправильная запись в changelog: * Wed Feb 09 2022 Daniel Zagaynov <email> - Initial build for Sisyphus. Отсутствует информация о версии. 3) Тэг, из которого собирается, указывает на предыдущий коммит, в котором создаётся спек-файл и всё прочее. В моём представлении такие тэги указывают в ситуации, когда берётся репозиторий из апстрима, на коммит сделанный апстримом. И в такой ситуации не потребуется делать два коммита, их можно будет объединить в один. Либо же сделать без указания на тэг в .gear/rules вообще. 4) В секции %files: %_man1dir/grim.1.xz Та же проблема, о которой я писал в прошлый раз: явно указан тип сжатия man-страниц. В случае очередной смены типа сжатия man-страниц данный пакет перестанет пересобираться. Этого можно избежать и заранее сделать лучше: "%_man1dir/grim.1*": вне зависимости от типа сжатия, такая строка должна работать верно всегда. i3lock: 1) Как и в других пакетах, теперь всё объединено в 1 коммит. Конечно, это не ошибка, но я бы предпочёл разбитие на отдельные части: отдельно то, что сделано/взято из апстрима, отдельно что сделано мэйнтейнером. 2) BuildRequires: gcc BuildRequires: autoconf_2.60 BuildRequires: m4 Насколько мне известно, gcc и m4 можно явно не писать, они устанавливаются во все сборочные окружения. А к autoconf_2.60 у меня есть вопрос: будет ли пакет собираться с версией autoconf по-умолчанию? Или, по другому, зачем здесь явно указана версия autoconf? Если этого можно не делать, лучше этого не делать. Тогда и autoconf явно можно не указывать. spread-sheet-widget: 1) Опять таки, предпочёл бы отдельный коммит с импортом новой версии и отдельный с патчем и изменением спека и т.д. pspp: 1) То же, что и в прошлом пакете. 2) https://git.altlinux.org/gears/p/pspp.git Пакет уже существовал в Сизифе, пусть он и удалён сейчас, и спек, судя по changelog-у, был взят оттуда. Почему не был взят весь репозиторий? Я считаю, что это лучше было бы оформить как обновление пакета, а не сборка с нуля, раз за основу берётся уже ранее существовавший пакет.
(Ответ для Aleksei Nikiforov на комментарий #17) > Информацию о коммите сборки помимо версии обычно записывают в релиз, > наподобии подобного: > > Version: %slurp_num > Release: alt1%commit_num Да, я понимаю, что есть риск "странного" версионнирования со стороны upstream и тогда новая версия может стать меньше предыдущей, но, во-первых, не похоже, чтобы этот upstream так себя вел,а во-вторых, и это в самом крайнем случае, есть эпоха, которой, конечно, злоупотреблять нельзя. Остальные требования я вроде все выполнил.
(Ответ для kotopesutility на комментарий #18) > (Ответ для Aleksei Nikiforov на комментарий #17) > > Информацию о коммите сборки помимо версии обычно записывают в релиз, > > наподобии подобного: > > > > Version: %slurp_num > > Release: alt1%commit_num > Да, я понимаю, что есть риск "странного" версионнирования со стороны > upstream и тогда новая версия может стать меньше предыдущей, но, во-первых, > не похоже, чтобы этот upstream так себя вел,а во-вторых, и это в самом > крайнем случае, есть эпоха, которой, конечно, злоупотреблять нельзя. > > Остальные требования я вроде все выполнил. Я обычно использовал такой подход: Version: 4.6.3.0.16.git5ecb40bc https://git.altlinux.org/gears/p/python3-module-lxml.git?p=python3-module-lxml.git;a=commit;h=6bb5374190b199e38c30f6ad52962d1134aa1701 Сейчас до меня дошло, что он тоже неправильный, потому что не исключает полностью возможность поломки версионирования. Я теперь буду придерживаться совета darktemplar@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов.
(In reply to Grigory Ustinov from comment #19) > полностью возможность поломки версионирования. Никакой подход не исключает, но я всё равно считаю, что версия должна быть в поле Version:, а не в полe Release:. Нет никаких ограничений в том, какое количество нулей вы добавите к предыдущей версии. Напремер, в этом случае я бы сделал версию 1.3.2.0.9.<commit id>. Достаточно только убедить себя в том, что апстрим никогда не выпустит что-то типа 1.3.2.0.1, если неубедительно, то нужно добавить ещё один нолик.
(Ответ для Gleb F-Malinovskiy на комментарий #20) > (In reply to Grigory Ustinov from comment #19) > > полностью возможность поломки версионирования. > > Никакой подход не исключает, но я всё равно считаю, что версия должна быть в > поле Version:, а не в полe Release:. Нет никаких ограничений в том, какое > количество нулей вы добавите к предыдущей версии. > Напремер, в этом случае я бы сделал версию 1.3.2.0.9.<commit id>. > Достаточно только убедить себя в том, что апстрим никогда не выпустит что-то > типа 1.3.2.0.1, если неубедительно, то нужно добавить ещё один нолик. Такой подход удобен в автоматизированных сборках из тэга, чтобы временно не ломать её, но зато repology мрачно грустнеет от таких версий. Чем плохо класть <commit id> в поле release?
А не пора бы уже дать кандидату право коммитить в Сизиф? pspp уже заждался =)
>Сейчас до меня дошло, что он тоже неправильный, потому что не исключает полностью возможность поломки версионирования. Я теперь буду придерживаться совета darktemplar@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов. Ну, я так и сделал. Посмотрите, пожалуйста! Вот задание: https://git.altlinux.org/tasks/292489/
(Ответ для kotopesutility на комментарий #18) > Остальные требования я вроде все выполнил. https://git.altlinux.org/people/kotopesutility/packages/?p=pspp.git;a=commitdiff;h=bc30ec7b4521d5e5fabc1e5d1970b6d549d2b4d4 --- a/.gear/rules +++ b/.gear/rules @@ -1 +1 @@ -tar.gz: pspp +tar.zst: pspp 1) Не уверен, может что-то уже и поменялось, но насколько мне известно сжатие исходников всё ещё излишне. Не критичный пункт. -License: GPLv3+ +License: GPLv3 2) Согласно сайту https://www.gnu.org/software/pspp/ лицензия всё ещё GPLv3+ (GPLv3-or-later): Freedom ensured; It is licensed under the GPLv3 or later. -Url: http://www.gnu.org/software/pspp/ +Url: http://gnu.mirror.constant.com/pspp/ 3) Я понимаю что Вы могли взять копию исходников с зеркала, но от этого домашняя страница проекта не меняется. 4) Вот это можно сократить, но это не обязательно: %_datadir/applications/org.fsf.pspp.desktop -> %_desktopdir/org.fsf.pspp.desktop https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=commitdiff;h=3aa1005d4e44d68f64f301f598fd98c206658cd0 1) Мне решительно не ясно зачем в этом merge commit ещё добавлены изменения в файлы .gear/rules и grim.spec, а также добавлены файлы в диретории .gear/tags. Ревьюить такое, мягко говоря, неудобно. Более того, мне непонятно зачем вообще здесь merge commit. Ничего не мешает создать ветку из коммита 1573b10, а затем одним коммитом (простым, не merge commit) добавить .gear/rules, .gear/tags/* и grim.spec. https://git.altlinux.org/people/kotopesutility/packages/?p=grim.git;a=blob;f=grim.spec;h=c60d87a64033c9a0370c16e7626f91a31c4da08e;hb=af5ce9d421dcef703a3a0dbf2065b78c46b83252 1) Я считаю, что лучше будет заменить %_man1dir/grim.1.* на %_man1dir/grim.1*. В случае, если сжатие man-страниц будет по какой-либо причине отключено, вторая запись в отличии от первой всё ещё будет работать. С учётом, что вероятность такого события мала, замечание не критично. Замечаний осталось не много, и я хочу верить что вступающий с ними справится без дополнительных пинков. В связи с этим думаю, что можно пропускать дальше. (Ответ для neurofreak-alt@yandex.ru на комментарий #22) > А не пора бы уже дать кандидату право коммитить в Сизиф? pspp уже заждался =) А для этого кандидату право коммитить не нужно, всегда может выдать approve любой другой член команды, в том числе его ментор.
(Ответ для Aleksei Nikiforov на комментарий #24) > Замечаний осталось не много, и я хочу верить что вступающий с ними справится > без дополнительных пинков. В связи с этим думаю, что можно пропускать дальше. Отлично! Благодарю за серьёзный подход к делу, надеюсь, кандидат принял к сведению). Я, по крайней мере, принял. В следующий раз сам кое-какие аспекты проверять буду, не дожидаясь рецензента. Ждём действий Секретаря.
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
