Ментор согласен.
Жду ключи.

Created attachment 8554 [details]
ssh-ключ

Created attachment 8555 [details]
gpg-ключ

Поправьте, пожалуйста, uid list для gpg:
uid           Sergey Ivanov <zagagyka@altlinux.org>
uid           Sergey <zagagyka@altlinux.org>

Created attachment 8556 [details]
gpg-ключ

Поправил

(Ответ для Sergey Ivanov на комментарий #5)
> Создано вложение 8556 [details] [подробности]
> gpg-ключ
> 
> Поправил

Спасибо.

(In reply to Sergey Ivanov from comment #2)
> Created attachment 8554 [details]
> ssh-ключ
Ok.

(In reply to Sergey Ivanov from comment #5)
> Created attachment 8556 [details]
> gpg-ключ
Ok.

ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 3.0.

В ходе процедуры сменился ментор.
Свое менторство подтверждаю.
Прошу Станислава подтвердить отсутствие возражений.

Считаю, что кандидат готов к переходу к этапу 3 по "новой классификации"

(Ответ для Николай Костригин на комментарий #9)
> В ходе процедуры сменился ментор.
> Свое менторство подтверждаю.
> Прошу Станислава подтвердить отсутствие возражений.

Станислав не возражает.

Я не могу добавлять свои пакеты в таск, т.к. моего gpg ключа нет в пакете alt-gpgkeys и соответственно на сборочнице.
$ ssh girar task add repo vkmark 2017.08-alt1.git.cf45f2fa
gpg: Signature made Thu Dec 23 07:15:42 2021 UTC
gpg:                using RSA key 0x53DFA6CA8CF1B778
gpg: Can't check signature: public key not found
task add: 2017.08-alt1.git.cf45f2fa: tag signature verification failure

Пакет alt-gpgkeys обновлён.

T/J/S -> 3.5.

Собрал следующие пакеты:
Эмулятор xbox original:
http://git.altlinux.org/people/zagagyka/packages/xemu.git
http://webery.altlinux.org/task/298724

Vulkan benchmark:
http://git.altlinux.org/people/zagagyka/packages/vkmark.git
http://webery.altlinux.org/task/297786

Текстовый редактор для работы с openQA
http://git.altlinux.org/people/zagagyka/packages/python3-module-openqa-scripting-tool.git
http://webery.altlinux.org/task/298722

kernel-modules-raw-gadget
http://git.altlinux.org/people/zagagyka/packages/kernel-modules.git
http://git.altlinux.org/people/zagagyka/packages/kernel-source-raw-gadget.git
В данный момент не соберется на сборочнице, т.к ему для сборки нужно ядро с включенными параметрами:
CONFIG_USB_GADGET=m
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
По согласованию с моим ментором, оставим как есть у меня в репозитории. Он будет нужен для экспериментов с локальной сборкой ядер при фаззинге

Полагаю, что работа кандидата уже готова к рецензированию.

(Ответ для Sergey Ivanov на комментарий #14)
> Vulkan benchmark:
> http://git.altlinux.org/people/zagagyka/packages/vkmark.git
> http://webery.altlinux.org/task/297786
На e2k тоже собрался и заработал (801-РС с RX580), если что.

Призван ещё один человек (vseleznv@) для независимой оценки готовности кандидата.

T/J/S -> 4.2.

Hi!

По просмотренным репозиториям в packages кандидата.

kernel-modules: OK

kernel-source-raw-gadget:

Исходники берутся из тега (по gear-rules), тем не менее в рабочем дереве репозитория присутствуют сами исходники. Это некрасиво и может ввести в заблуждение. Лучше выбрать одно: или брать исходники из коммита апстрим ветки, а саму ветку мёржить в отдельную, не связанную изначально историей с апстрим-веткой, ветку (orphan-ветку) со стратегией ours, либо брать исходники из текущего дерева. Это же замечание справедливо и для остальных пакетов с такой же проблемой.

Также не стоит подписывать самопоставленные теги (как, например, в bd086cef44f3e9c6ae72b3bebf1bed62f68c3566) на апстримные коммиты, чтобы не возникало впечатления, будто бы это апстримные теги.

Ещё зачем-то при копировании файлов в коммите 87acbf313b93655beee378fd8ceef9caddef536e используется ключ cp -r. Зачем? Возможно, подразумевался ключ cp -a.

python3-module-openqa-scripting-tool: По спеку замечаний нет, кроме того, что Url ведёт на несуществующий адрес и лицензия указана не полно: следует указал GPL-3.0-or-later (см. SPDX [1]).

vkmark: То же замечание с указанием лицензии LGPL-2.1-or-later.
Вместо %_man1dir/%name.1.xz следует писать %_man1dir/%name.1*

xemu:

Сложносоставной пакет из множества исходных кодов с разными источниками. Надо отдельно проверить совместимость лицензии по связыванию, и в случае множества различных лицензий перечислить их через and. С другой стороны: все ли эти исходники должны быть вместе и статически связаны, или часть можно вынести и использовать динамическую линковку?

Копировать файлы лучше с явным сохранением всех пермишнов и таймстампов, используя, например, cp -a.


Общее замечание: пока пакет не собран в Сизиф, можно переписывать гитовую историю и не повышать релиз.

--
[1] https://spdx.org/licenses/

Прошу учесть кандидата описанные замечания.

Володя, вообще конечно ты не прав - гораздо удобнее вести дерево разработки так, что бы было видно всё дерево исходников, а не только альтовые спеки и gear-rules.

Поэтому я всегда делаю так. что бы в master было дерево исходников + всё что нужно для сборки альта, включая изменения поверх master.

Это не является ошибкой.

так же не является ошибкой повесить свой подписанный тэг на апстримный коммит, если в этом есть необходимость (например, некоторые апстримы забывают пушить тэги).

Если же апстримный тэг уже есть на этом коммите, то можно сделать алиас:
git tag <new tag> <upstream tag>

(Ответ для Vladimir D. Seleznev на комментарий #18)
> [...]
> Общее замечание: пока пакет не собран в Сизиф, можно переписывать гитовую
> историю и не повышать релиз.

Спасибо за ревью.
Конкретно по этому пункту: это я просил Сергея выполнить именно обновление, т.е. чтобы был виден "процесс".
Думаю, перед отправкой в Сизиф, будет разумно собрать сразу финальную версию.

(In reply to Anton Farygin from comment #20)
> Володя, вообще конечно ты не прав - гораздо удобнее вести дерево разработки
> так, что бы было видно всё дерево исходников, а не только альтовые спеки и
> gear-rules.

Нет, я не пишу, что репозиторий надо вести именно так, я вообще не давал совету о предпочтительной схемы ведения репозитория, я писал о том, что если вести так, то не надо оставлять апстримные исходники в дереве.

(In reply to Anton Farygin from comment #21)
> так же не является ошибкой повесить свой подписанный тэг на апстримный
> коммит, если в этом есть необходимость (например, некоторые апстримы
> забывают пушить тэги).

Это другой случай.

> Если же апстримный тэг уже есть на этом коммите, то можно сделать алиас:
> git tag <new tag> <upstream tag>

Кандидат повесил свой тег на нерелизный коммит. Я считаю, что такой тег не следует подписывать, чтобы не возникало впечатления, будто бы это апстримный тег.

(In reply to Николай Костригин from comment #22)
> (Ответ для Vladimir D. Seleznev на комментарий #18)
> > [...]
> > Общее замечание: пока пакет не собран в Сизиф, можно переписывать гитовую
> > историю и не повышать релиз.
> 
> Спасибо за ревью.
> Конкретно по этому пункту: это я просил Сергея выполнить именно обновление,
> т.е. чтобы был виден "процесс".
> Думаю, перед отправкой в Сизиф, будет разумно собрать сразу финальную версию.

Ага, понял.

(Ответ для Vladimir D. Seleznev на комментарий #23)
> (In reply to Anton Farygin from comment #20)
> > Володя, вообще конечно ты не прав - гораздо удобнее вести дерево разработки
> > так, что бы было видно всё дерево исходников, а не только альтовые спеки и
> > gear-rules.
> 
> Нет, я не пишу, что репозиторий надо вести именно так, я вообще не давал
> совету о предпочтительной схемы ведения репозитория, я писал о том, что если
> вести так, то не надо оставлять апстримные исходники в дереве.

нет, я категорически против такого подхода.
Релизные исходники в дереве - это удобно и правильно, так и надо делать.

Вот пример практически идеального репозитория: 
https://git.altlinux.org/people/zagagyka/packages/vkmark.git?p=vkmark.git;a=tree;h=4b49d2b21fe87d69a31680189582a37482cb3a72;hb=4b49d2b21fe87d69a31680189582a37482cb3a72


А тэг, если он повешен и публикуется, должен быть подписан. В авторе тега можно увидеть апстрим это или нет.

(In reply to Anton Farygin from comment #25)
> (Ответ для Vladimir D. Seleznev на комментарий #23)
> > (In reply to Anton Farygin from comment #20)
> > > Володя, вообще конечно ты не прав - гораздо удобнее вести дерево разработки
> > > так, что бы было видно всё дерево исходников, а не только альтовые спеки и
> > > gear-rules.
> > 
> > Нет, я не пишу, что репозиторий надо вести именно так, я вообще не давал
> > совету о предпочтительной схемы ведения репозитория, я писал о том, что если
> > вести так, то не надо оставлять апстримные исходники в дереве.
> 
> нет, я категорически против такого подхода.
> Релизные исходники в дереве - это удобно и правильно, так и надо делать.

Нет, я не про это говорю. Если оставлять исходники в дереве, то тогда берите дифф между ними и релизным коммитом.

> Вот пример практически идеального репозитория: 
> https://git.altlinux.org/people/zagagyka/packages/vkmark.git?p=vkmark.git;
> a=tree;h=4b49d2b21fe87d69a31680189582a37482cb3a72;
> hb=4b49d2b21fe87d69a31680189582a37482cb3a72
> 
> 
> А тэг, если он повешен и публикуется, должен быть подписан. В авторе тега
> можно увидеть апстрим это или нет.

В общем случае невозможно отличить апстримный тег от самоповешенного.

(Ответ для Vladimir D. Seleznev на комментарий #26)
> (In reply to Anton Farygin from comment #25)
> > (Ответ для Vladimir D. Seleznev на комментарий #23)
> > > (In reply to Anton Farygin from comment #20)
> > > > Володя, вообще конечно ты не прав - гораздо удобнее вести дерево разработки
> > > > так, что бы было видно всё дерево исходников, а не только альтовые спеки и
> > > > gear-rules.
> > > 
> > > Нет, я не пишу, что репозиторий надо вести именно так, я вообще не давал
> > > совету о предпочтительной схемы ведения репозитория, я писал о том, что если
> > > вести так, то не надо оставлять апстримные исходники в дереве.
> > 
> > нет, я категорически против такого подхода.
> > Релизные исходники в дереве - это удобно и правильно, так и надо делать.
> 
> Нет, я не про это говорю. Если оставлять исходники в дереве, то тогда берите
> дифф между ними и релизным коммитом.

Зачем, если можно просто взять релизный коммит ?
https://git.altlinux.org/people/zagagyka/packages/vkmark.git?p=vkmark.git;a=blob;f=.gear/rules;h=4d01b413522130a474d552824b1c9c03803955df;hb=4b49d2b21fe87d69a31680189582a37482cb3a72

Прикладывать изменения патчем или в дереве - это выбор и судьба ментейнера, видимо кому как удобнее. Никаких требований по этому поводу у нас нет.


> 
> > Вот пример практически идеального репозитория: 
> > https://git.altlinux.org/people/zagagyka/packages/vkmark.git?p=vkmark.git;
> > a=tree;h=4b49d2b21fe87d69a31680189582a37482cb3a72;
> > hb=4b49d2b21fe87d69a31680189582a37482cb3a72
> > 
> > 
> > А тэг, если он повешен и публикуется, должен быть подписан. В авторе тега
> > можно увидеть апстрим это или нет.
> 
> В общем случае невозможно отличить апстримный тег от самоповешенного.

Это весьма странно, что значит невозможно ? у tag достаточное количество атрибутов для того, что бы это было возможно.

(Ответ для Vladimir D. Seleznev на комментарий #19)
> Прошу учесть кандидата описанные замечания.

Спасибо большое за ревью.

Я поправил свои spec файлы согласно вашим замечаниям:

http://git.altlinux.org/people/zagagyka/packages/kernel-source-raw-gadget.git
Заменил cp -r на cp -a

http://git.altlinux.org/people/zagagyka/packages/vkmark.git
Поправил лицензию и секцию %files

http://git.altlinux.org/people/zagagyka/packages/python3-module-openqa-scripting-tool.git
Поправил лицензию и добавил альтернативную ссылку в Url (в какой то момент этот проект почему то пропал с pypi.org)

http://git.altlinux.org/people/zagagyka/packages/xemu.git
Заменил cp -r на cp -a
Перечислил в License лицензии для всех сабмодулей
Добавил в ExcludeArch макросы для 32-x битных архитектур

http://git.altlinux.org/people/zagagyka/packages/kernel-modules.git
оставил без изменений

Структуру дерева в своих репозиториях я оставил прежней, т.к. судя по репозиториям других мейнтейнеров (и по обсуждениям в данном баге) - такое ведение рабочего дерева не возбраняется
Свой подписанный тег на апстримный коммит в kernel-source-raw-gadget и python3-module-openqa-scripting-tool я оставил т.к. в данном случае апстрим не поставил свои теги.

Вышеописанные изменения я запушил с увеличением релиза для того, что бы видны были изменения (и только до согласования с ревьюером)
Перед отправкой в Sisyphus я всё "засквошу" в единый коммит c релизом alt1

(Ответ для Vladimir D. Seleznev на комментарий #19)
> Прошу учесть кандидата описанные замечания.

Все ли замечания устранил кандидат? Можем ли двигаться дальше по процедуре?

(In reply to Николай Костригин from comment #29)
> (Ответ для Vladimir D. Seleznev на комментарий #19)
> > Прошу учесть кандидата описанные замечания.
> 
> Все ли замечания устранил кандидат? Можем ли двигаться дальше по процедуре?

Да, все замечания устранены.

(Ответ для Vladimir D. Seleznev на комментарий #30)
> (In reply to Николай Костригин from comment #29)
> > [...]
> > Все ли замечания устранил кандидат? Можем ли двигаться дальше по процедуре?
> 
> Да, все замечания устранены.

Полагаю, согласно https://www.altlinux.org/Team/Join/Mentor, уже можно подкрутить счетчик этапов...

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

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