Created attachment 11990 [details] SSH public key Имя ментора: Михаил Ефремов <sem@altlinux.org> Псевдоним: paksa Адрес пересылки почты: stepan_paksa@mail.ru Цель вступления: Создание и поддержка пакетов и участие в продвижении открытого ПО.
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 надо писать в прошедшем времени (с большой буквы и точку в конце ставить), так делают не все, но в любом случае, лучше когда есть какое-то единообразие.
Ещё актуально?
Переоткройте, если будет снова актуально.
