Псевдоним: zagagyka E-mail: zagagyka@basealt.ru Ментор: Станислав Левин (slev@altlinux.org) Моя цель: Научиться собирать пакеты. Освоить git.alt.
Ментор согласен. Жду ключи.
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@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
