Created attachment 11991 [details]
GPG public key

> Имя ментора: Михаил Ефремов <sem@altlinux.org>

Ack

(In reply to Stepan Paksashvili from comment #0)
> Created attachment 11990 [details]
> SSH public key
Ok.

(In reply to Stepan Paksashvili from comment #1)
> Created attachment 11991 [details]
> GPG public key

Ключ с типом 3072R не подойдёт, к тому же вы забыли указать <First name> <Last name> в uid ключа.

И не забудьте, пожалуйста, закрыть лишнюю заявку на join.

*** Bug 44475 has been marked as a duplicate of this bug. ***

Created attachment 12075 [details]
GPG public key(update)

(Ответ для Gleb F-Malinovskiy на комментарий #3)
> (In reply to Stepan Paksashvili from comment #0)
> > Created attachment 11990 [details] [подробности] [details]
> > SSH public key
> Ok.
> 
> (In reply to Stepan Paksashvili from comment #1)
> > Created attachment 11991 [details] [подробности] [details]
> > GPG public key
> 
> Ключ с типом 3072R не подойдёт, к тому же вы забыли указать <First name>
> <Last name> в uid ключа.
> 
> И не забудьте, пожалуйста, закрыть лишнюю заявку на join.

GPG Ключ исправил, и первый джоин переведен в duplicate.

(In reply to Stepan Paksashvili from comment #5)
> Created attachment 12075 [details]
> GPG public key(update)
Ok.

Кандидат готов к следующему шагу.

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

T/J/S -> 2.3.

Здравствуйте, мне нужно собрать кубернетес. И не хватает места, можно увеличить на гигабайт ?

Готово.

Кандидат готов к следующему шагу. Что не надо пушить много тэгов, я думаю, тоже осознал :).

ssh ключ на gyle.alt зарегистрирован.
Пакет alt-gpgkeys обновлён.

T/J/S -> 3.5.

Можно переходить к следующему этапу. Часть пакетов кандидата уже прошли в repo:
https://packages.altlinux.org/ru/tasks/?task_owner=paksa

Есть проблема со сборкой clair, но там что-то непонятное, в локальном хэшере пакет собирается. Возможно упирается в какие-то лимиты на сборочнице или что-то go-специфическое. Думаю, что к самому процессу join это уже не относится и с этим кандидату предстоит разбираться уже вне рамок join :).

здравствуйте, будет ли двигаться процесс джоина ?

Призываю самого себя в качестве рецензента для независимой оценки готовности кандидата.

Проблемы:
* Обновление пакета kubernetes-pause выглядит как фикция и это никак не
  отражено в %changelog.  В предыдущем обновлении формулировка тоже не самая
  удачная, но хотя бы предпринята попытка описать, что версия поменялась, а
  исходный код нет.  Я бы написал что-то вроде
«- Bumped package version to 3.9 (no code changes were made since the file
build/pause/linux/pause.c in Kubernetes remained unchanged between versions
v1.24.8 to v1.26.3).».
  Ещё этот пакет ещё не очень понятно:
  ** зачем он нужен в таком виде (эти же исходники можно собирать в пакете
  kubernetes и паковать в отдельный подпакет c тем же именем);
  ** А откуда берётся версия?  У kubernetes, из которого взяты исходники версия
  v1.22.8/v1.24.8/v1.26.3, а у пакета почему-то 3.9.
  ** И почему вообще версия этого пакета хоть сколько-то важна, чтобы
  увеличивать её даже когда исходный код не меняется?
* В fuse-overlayfs BuildRequires: autoconf automake gcc лишние.  Понятно, что
  это было и до вас, но нет повода не убрать.
* В fuse-overlayfs и gitea-act в Summary: не нужна точка в конце, а в
  %description нужна (в  итоге сейчас в description целых две точки):
$ rpm -q --qf '%{description}\n' -p /ALT/Sisyphus/files/SRPMS/fuse-overlayfs-1.10-alt1.src.rpm
FUSE implementation for overlayfs..
$ rpm -q --qf '%{description}\n' -p /ALT/Sisyphus/files/SRPMS/gitea-act-0.1.6-alt2.src.rpm
Act runner is a runner for Gitea based on Gitea fork of act..
* В fuse-overlayfs, ctop и kubectl-who-can есть коммиты "update spec", это
  очень неинформативное описание.  Я бы в этом случае просто сделал
  git commit --amend или git rebase -i и fixup к коммиту с добавлением спека.
  И, таким образом, не пытался делать для таких изменений отдельные коммиты с
  информативным описанием.
  «7 раз amend, 1 раз task run --commit».
* В wuzz стоило сделать добавление исходников в vendor/, обновление go.mod
  и добавление spec-файла в виде трёх отдельных коммитов.
* В clair вы сначала меняете .gear/rules а потом переименовываете файлы,
  которые которые в rules упоминаются, это очень нелогично.  Я бы сделал
  перемещение specfile одним коммитом, а все остальные изменения другим
  коммитом, если хочется сделать это аккуратно в виде нескольких коммитов.
* В trivy в записи %changelog для версии 0.39.0-alt2 не описано, что в этом
  релизе был добавлен service-файл, хотя это user-visible изменение, которые
  как раз и стоит отражать в %changelog.
* В trivy-db непонятно, откуда взяты исходники (от чего он forked), что это
  вообще за пакет и чем отличается от оригинала.

Замечания:
* Для тех пакетов, которые вы обновляете у вас в git-репозиториях основной
  бранч sisyphus, а ваши собственные коммиты сделаны совсем в другом бранче,
  который ещё надо искать.  Это крайне неудобно для любого, кто хочет это
  посмотреть.  Для изменения можно использовать команду "ssh git.alt
  default-branch".
* У вас в ваших git-репозиториях основной бранч sisyphus
* В github-act и ctop было бы логичнее сначала сделать "add vendor", а потом
  все остальные коммиты, чтобы к моменту появления spec уже уже получался
  собирающийся пакет.
* В скриптах лучше использовать rm -r вместо rm -rf потому что rm -f
  значит «удалить если есть, ничего не делать если нет».  Хотя, может зависеть
  от ситуации.
* Существует мнение, что в конце предложения лучше писать точку.  Точки не
  принято ставить в Summary: и первой строчке git commit message (потому что он
  по сути является полем Subject: для письма).
* В kubectl-who-can в "mkdir -p %buildroot{%_bindir}" фигурные скобки
  явно лишние.
* В ceph-ansible лучше поменять
%add_findprov_skiplist */library/*
%add_findreq_skiplist */library/*
на
%add_findprov_skiplist /usr/share/ceph-ansible/library/*
%add_findreq_skiplist /usr/share/ceph-ansible/library/*
* В trivy вы в одном %changelog-entry пишете Added (в прошедшем времени и с
  точкой в конце предложения), а в другом Update (в настоящем времени и без
  точки).  Я считаю, что в %changelog надо писать в прошедшем времени (с
  большой буквы и точку в конце ставить), так делают не все, но в любом случае,
  лучше когда есть какое-то единообразие.

Ещё актуально?

Переоткройте, если будет снова актуально.