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@.
Пользователь добавлен в группу мейнтейнеров.

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