Bug 40788

Summary: [done] join kotopesutility@
Product: Team Accounts Reporter: kotopesutility <kotopesutility>
Component: joinAssignee: Gleb F-Malinovskiy <glebfm>
Status: CLOSED FIXED QA Contact: Andrey Cherepanov <cas>
Severity: normal    
Priority: P5 CC: darktemplar, darktemplaralt, george, glebfm, grenka, ldv, neurofreak-alt
Version: unspecified   
Hardware: x86_64   
OS: Linux   
URL: https://www.altlinux.org/Team/Join/Secretary
Attachments:
Description Flags
ssh and gpg public keys
none
SSH-key
none
SSH-key none

Description kotopesutility 2021-08-19 22:24:34 MSK
Created attachment 9613 [details]
ssh and gpg public keys

Добрый день!
Прошу принять меня в ALT Linux Team. 
Мой псевдоним kotopesutility, адрес для перессылки почты kotopesutility@yandex.ru. Моим ментором прошу назначить Георгия Владимировича Курячего. 
Я уже несколько лет пользователь Linux и владею несколькими языками программирования, но я хотел бы научиться собирать пакеты и принять участие в разработке.
Comment 1 kotopesutility 2021-08-19 22:28:58 MSK
Created attachment 9614 [details]
SSH-key

Прошу прощения, почему-то с первого раза прикрепился только GPG-ключ
Comment 2 Fr. Br. George 2021-08-20 20:46:18 MSK
> Моим ментором прошу назначить Георгия Владимировича Курячего.
Подтвержаю
Comment 3 Gleb F-Malinovskiy 2021-08-24 22:05:14 MSK
(In reply to kotopesutility from comment #1)
> Created attachment 9614 [details]
> SSH-key

Мы рекомендуем ssh ключи ed25519 или RSA >= 4096.
Comment 4 kotopesutility 2021-08-25 01:20:32 MSK
Created attachment 9622 [details]
SSH-key

Простите, вот ключ нужной длины.
Comment 5 Gleb F-Malinovskiy 2021-09-02 15:39:08 MSK
(In reply to kotopesutility from comment #4)
> Created attachment 9622 [details]
> SSH-key
> 
> Простите, вот ключ нужной длины.

Ok.

T/J/S -> 1.3.
Comment 6 Fr. Br. George 2021-09-02 17:21:44 MSK
Пора заводить аккаунты, я считаю.

T/J/S 1.3 → T.J.S 2.1
Comment 7 Gleb F-Malinovskiy 2021-09-02 17:25:17 MSK
ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.4.
Comment 8 Fr. Br. George 2021-09-07 19:48:53 MSK
Надо бы пакеты на сборочнице потестить, кандидат готов! → 3.0
Comment 9 Gleb F-Malinovskiy 2021-09-14 17:32:48 MSK
Пакет alt-gpgkeys обновлён.

T/J/S -> 3.4.
Comment 10 Fr. Br. George 2021-10-30 22:34:12 MSK
Мне кажется, Кандитат уже вполне кандидат, и пора ему подыскать Рецензента!
→ 4.0
Comment 11 Fr. Br. George 2021-11-15 20:42:11 MSK
ping 4.0
Comment 12 Gleb F-Malinovskiy 2021-11-16 15:10:49 MSK
Призван ещё один человек (darktemplar@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.
Comment 13 Fr. Br. George 2021-12-07 11:53:33 MSK
ping

Может, рецензента поменять?
Comment 14 Aleksei Nikiforov 2021-12-07 15:05:19 MSK
(Ответ для Fr. Br. George на комментарий #13)
> ping
> 
> Может, рецензента поменять?

Извиняюсь, пропустил. Если хотите поменять - с моей стороны возражений нет. Или же я посмотрю в ближайшее время.
Comment 15 Aleksei Nikiforov 2021-12-07 17:51:20 MSK
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.


С учётом всего вышенаписанного у меня есть сомнения в готовности кандидата хорошо собирать различные пакеты в репозиторий.
Comment 16 kotopesutility 2022-03-21 19:51:50 MSK
Спасибо за ответ!

>5) Оформление: из .gear/rules: "copy: *.patch". Я в таких случаях предпочитаю использовать "copy?: *.patch" - если файлов *.patch больше не будет, то это не станет ошибкой и не потребуется менять .gear/rules.

Я оставил как есть, контролировать наличие или отсутствие *.patch я готов и, честно говоря, мне так удобнее.

Остальные правки я внес, вот задание: https://git.altlinux.org/tasks/292489/
Comment 17 Aleksei Nikiforov 2022-03-22 00:09:27 MSK
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-у, был взят оттуда. Почему не был взят весь репозиторий? Я считаю, что это лучше было бы оформить как обновление пакета, а не сборка с нуля, раз за основу берётся уже ранее существовавший пакет.
Comment 18 kotopesutility 2022-04-18 21:50:31 MSK
(Ответ для Aleksei Nikiforov на комментарий #17)
> Информацию о коммите сборки помимо версии обычно записывают в релиз,
> наподобии подобного:
> 
> Version: %slurp_num
> Release: alt1%commit_num
 Да, я понимаю, что есть риск "странного" версионнирования со стороны upstream и тогда новая версия может стать меньше предыдущей, но, во-первых, не похоже, чтобы этот upstream так себя вел,а во-вторых, и это в самом крайнем случае, есть эпоха, которой, конечно, злоупотреблять нельзя.

Остальные требования я вроде все выполнил.
Comment 19 Grigory Ustinov 2022-04-19 03:21:39 MSK
(Ответ для 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@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов.
Comment 20 Gleb F-Malinovskiy 2022-04-19 13:47:12 MSK
(In reply to Grigory Ustinov from comment #19)
> полностью возможность поломки версионирования.

Никакой подход не исключает, но я всё равно считаю, что версия должна быть в поле Version:, а не в полe Release:.  Нет никаких ограничений в том, какое количество нулей вы добавите к предыдущей версии.
Напремер, в этом случае я бы сделал версию 1.3.2.0.9.<commit id>.  Достаточно только убедить себя в том, что апстрим никогда не выпустит что-то типа 1.3.2.0.1, если неубедительно, то нужно добавить ещё один нолик.
Comment 21 Grigory Ustinov 2022-04-19 15:50:54 MSK
(Ответ для 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?
Comment 22 neurofreak-alt@yandex.ru 2022-04-19 17:25:27 MSK
А не пора бы уже дать кандидату право коммитить в Сизиф? pspp уже заждался =)
Comment 23 kotopesutility 2022-04-25 18:24:45 MSK
>Сейчас до меня дошло, что он тоже неправильный, потому что не исключает полностью возможность поломки версионирования. Я теперь буду придерживаться совета darktemplar@ и вам советую того же. Хотя бы из соображений единобразия подходов к оформлению спекфайлов.

Ну, я так и сделал. Посмотрите, пожалуйста!
Вот задание: https://git.altlinux.org/tasks/292489/
Comment 24 Aleksei Nikiforov 2022-04-27 22:32:09 MSK
(Ответ для 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 любой другой член команды, в том числе его ментор.
Comment 25 Fr. Br. George 2022-04-28 15:55:01 MSK
(Ответ для Aleksei Nikiforov на комментарий #24)
> Замечаний осталось не много, и я хочу верить что вступающий с ними справится
> без дополнительных пинков. В связи с этим думаю, что можно пропускать дальше.

Отлично! Благодарю за серьёзный подход к делу, надеюсь, кандидат принял к сведению). Я, по крайней мере, принял. В следующий раз сам кое-какие аспекты проверять буду, не дожидаясь рецензента.

Ждём действий Секретаря.
Comment 26 Gleb F-Malinovskiy 2022-05-17 13:06:22 MSK
Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

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