Created attachment 8571 [details]
Публичная часть SSH-ключа

Created attachment 8572 [details]
Публичная часть GPG-ключа

Спасибо.
Ментор не против.

(In reply to Ivan Alekseev from comment #1)
> Created attachment 8571 [details]
> Публичная часть SSH-ключа
Ok.

(In reply to Ivan Alekseev from comment #2)
> Created attachment 8572 [details]
> Публичная часть GPG-ключа
Ok.

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

T/J/S -> 3.0.

Испытуемый готов перейти к этапу 3.

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

T/J/S -> 3.5.

gpg ключ протух 2021-02-02, нельзя ли добавить проверку на валидность при регистрации ключа?

(In reply to Stanislav Levin from comment #8)
> gpg ключ протух 2021-02-02, нельзя ли добавить проверку на валидность при
> регистрации ключа?

Прецедентов с новыми ключами не было.  Стоит добавить, да.

Прошу прощения за неудобства. Сгенерировал новый ключ, на этот раз бессрочный.

Created attachment 10153 [details]
Публичная часть GPG-ключа

(In reply to Ivan Alekseev from comment #11)
> Created attachment 10153 [details]
> Публичная часть GPG-ключа

Мне кажется, что проще продлить старый ключ.  Новый нужно запушить на git.alt как описано в https://www.altlinux.org/Работа_с_ключами_разработчика#Обновление_существующего_GPG-ключа_в_пакете_alt-gpgkeys 

gpg: key 34283EF51C1FC29B was created 7170 seconds in the future (time warp or clock problem)
Проверьте часы, пожалуйста.

(Ответ для Gleb F-Malinovskiy на комментарий #12)
> (In reply to Ivan Alekseev from comment #11)
> > Created attachment 10153 [details] [подробности] [details]
> > Публичная часть GPG-ключа
> 
> Мне кажется, что проще продлить старый ключ.
Продлил старый ключ, запушил в приватный репозиторий на git.alt.

Открыл заявку на компонент alt-gpgkeys:

https://bugzilla.altlinux.org/41754

На текущий момент собрано 13 проектов:
dlib
freeipa-healthcheck (p9/p10/sisyphus)
freeipmi (обновлено: p10/sisyphus)
howdy
kms-cmake-utils
kms-jsoncpp
kms-jsonrpc
kurento-module-creator
pastel
python3-module-bowler (sisyphus)
python3-module-fissix (sisyphus)
python3-module-moreorless (sisyphus)
spotify-tui (p10/sisyphus)

Фактически собранные пакеты:
- local-only (но текущая версия не проверялась ментором):
  dlib
  howdy
  
  Почему не запушено в репозиторий:
  howdy зависит от python-pam, который в свою очередь все еще не поддерживает 
  Python3 и не может быть отправлен в сизиф.
  See https://sourceforge.net/p/pam-python/tickets/5/

- отправленные в сизиф:
  freeipa-healthcheck
  freeipmi (обновление)
  python3-module-bowler
  python3-module-fissix
  python3-module-moreorless
  spotify-tui
  shfmt

Пакеты, отправленные в сизиф, достаточно простые, исполняли тренировочную роль, но в то же самое время полезные для пользователей.

Думаю, что кандидат готов перейти на следующий этап.

Можно, пожалуйста, узнать имя рецензента?

Я не нашёл рецензента и решил, что я и сам подойду.

Общие замечания:
* .gear/rules: tar.gz: ...
нет никакого смысла сжимать исходники потому что промежуточный временный tarball (который генерирует gear для того, чтобы передать hasher-у) сжимается zstd, а src.rpm сжимается xz, т.е. происходит ненужное двойное сжатие, которое влияет и на скорость работы и на степень сжатия.
* Макросы типа %__ являются внутренними для rpm, потому и имеют такой префикс.  Гораздо проще запустить нужную программу, чем использовать внутренние макросы для выяснения её названия, которое и так известно.
* У вас во многих пакетах есть файлы я new blank line at EOF.  (совет) Посмотрите на pre-commit hook, который идёт прямо в комплекте с git, он сообщает о таких ошибках (а заодно ещё и о некоторых других).  Я сделал у себя так, чтобы он включался во всех моих git-репозиториях.
* (мысли вслух) Мне кажется, у нас принято в первых сборках пакета писать в %changelog что-то о том, что это initial build, это настолько привычно, что когда этого не видишь, удивляешься, хотя возможно вы просто не сразу начали это делать. :)
* (мысли вслух) Лично мне не нравится практика складывания абсолютно всех файлов, связанных со сборкой пакета (включая spec) в каталог .gear/.  Обычно, когда я собираю пакет из апстримного git-а, я кладу и spec и все дополнительные файлы в каталог alt/.

dlib
* У коммита 00d7b1e8 автором значится Стас, а коммитером вы, скорее всего он видоизменялся в процессе.  Сам коммит разбандливает только pybind11, хотя в commit-message написано, что разбандливается гораздо больше всего.
* В spec-файле есть такой фрагмент:
 # cpp.req unconditionally adds /usr/include/dlib to the include path,
 # dlib doesn't support that
 %add_findreq_skiplist %_includedir/dlib/*
Возможно, вы решили, что ошибки, которые генерирует cpp.req страшнее, чем они есть, но на самом деле это просто информационные сообщения.  Действительно, получается, что cpp.req не может найти в этих хедерах никаких зависимостей, но при этом выводит очень много текста.  Во-первых, это экономия на спичках.  Во-вторых, если мы точно знаем, что cpp.req ничего не найдёт и точно хотим сэкономить на спичках, то, возможно, лучше явно выключить именно этот генератор зависимостей (AutoReq: nocpp).
* %python3_build_debug ... --compiler-flags "-O2 -g"
зачем передавать эти флаги, если они уже есть в optflags и %python3_build_debug должен их экспортировать правильным образом?  Если же нет, то использовать в качестве флагов нужно как раз %optflags.
* License: BSL and PDDL
Я сходу не нашёл, где там PDDL.


howdy
* BuildArch: x86_64
Это не будет работать на архитектурах отличных от x86_64 потому что там нельзя собрать пакет под x86_64.  Для ограничения списка архитектур нужно использовать ExclusiveArch: или ExcludeArch: в зависимости от задачи.  Совсем хорошо будет, если вы возле этого ограничения напишите, чем оно обусловлено.
* .gear/rules copy: fedora/com.github.boltgolt.howdy.policy
Зачем копировать файл, который и так является частью апстримных исходников?

spotify-tui
* (мысли вслух) В update-vendored-sources.sh я бы добавил в начало
toplevel="$(git rev-parse --show-toplevel)"
cd "$toplevel/alt"
Меня немного пугают скрипты, которые неизвестно где делают rm -rf.  Кстати, инструкция "sh update-vendored-sources.sh" делает почти бесполезным shebang (в котором, кстати, написано bash) в начале скрипта.
* Зависимость BuildRequires: на /proc больше не нужна поскольку она с какого-то момента есть у пакета rust.


shfmt
* (мысли вслух) В пакете spotify-tui update-vendored-sources.sh получился лучше потому что в этой ситуации
mv -f vendor/ alt/
mv откажется заменять каталог alt/vendor если он не пустой.


Хорошая работа, я считаю, что кандидат готов к самостоятельной работе в Team.

(Ответ для Gleb F-Malinovskiy на комментарий #18)

Глеб, большое спасибо за рецензию, замечания приму к сведению.

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

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