Created attachment 13087 [details]
GPG ключ

Created attachment 13088 [details]
SSH ключ

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

Comment on attachment 13087 [details]
GPG ключ

>-----BEGIN PGP PUBLIC KEY BLOCK-----
>
>mQINBGRQpksBEAC1Cuanvd6ItCFyz2TkxdbwDJ016Lt4Rz1MLDH6h6lqUDPBEJ/Y
>4Zz37eeY1swvQfq6IXYYHas5k2ALvscaf3qDq/gQ/TsRt0zCrShqrstVuJ7IkcBX
>XbFjKbu7Jq4/AjmOZj7vqQgu1xkLBPhSbxAQxpockiW8CrfsNV9XS99FyyTTmRUX
>Q+uIh0KjMdpksPj5LR3m4YuPKL+YpT+alwdLnjBumHBLxfiAIUxwC6pOTT1bMZq9
>2b9u7UluQEATR4N3dhU5cXkv7+MNRxSHJ+gQSXRvJQu9uYm2bE7Dv9arBqMW/s0g
>t+ceGRXfqZyqT+sBv9MrJ4v19pgFKnPWtyOcYkVre+oQa/R3ztgHOE2+0nA5g65l
>4PDx5BPcclx/HmCwfErhbq+GjFCrs4AnuvcfnC/ddl985iZ0L6bq6uqS0lQMTaPZ
>EnzmcGPaCuIx1ztv7eVy96f3llB70ddd916dK94//QghdFqQJ66QvBzuC/S76A/L
>laTR/nalqp5OAAer1zvCVNgs8YhRbhEdk8OCFZe2ERNFLz+qupuCpJ2yfjz/LnUw
>NYhb9h/h6VUR6Cq6mED3zEE5hmr1tScIRxiGZbUtj0+DmDQ6U9Kvzl2/d3HAaYud
>EyNlkv+czWbzF/kU0kc+JsS2CI+S5mWbH3EbZgREAT9/jEl1C4tQmLcn+wARAQAB
>tC5NaWNoYWVsIENoZXJuaWdpbiA8bWljaGFlbGNoZXJuaWdpbkBnbWFpbC5jb20+
>iQJUBBMBCAA+FiEEp16bMPx1cKmigmmR2OpMeey2hdgFAmRQpksCGwMFCQHhM4AF
>CwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ2OpMeey2hdiYDA//TIUHK810RGyU
>txKLPF+keJP7U6KgfSZ1RG89voeyXMd5ImMtHkWgs+NeMz5CXkqy8tme4E8iYvFE
>j+Ojovbu6+dbgW08QHu3tQcMLfNwXB39E7OMQtbvboITYZtKInLWx7TNWbPl8Xt0
>MAFQzKZswSeMrmM9FNR90J1gNLHh+MTxF9KNFhHw8cWptatNCyaMftUEW1zD7Q1v
>pTM2yU9tOs/qmP8ukh10HE1WuYM99S3nub6te6GxS/ccGWVGftt/YjdQHz252eB8
>EWdhyy5FlrL7zrLa41sN6Ld6oe1ZRnWGXVK9hmDhW+fGwLH7qPhjhtpeznmmOBlt
>k60WNEd0zDnRNhu+Em0SjtC1sanGoiamx1CDZsw1FxqkINkb0flU49CMjwBO4T8C
>d1Nj4UYU5steTghgwnAegiZXuGFZWHiJKKO5JItGqUM9G8fUNAePrH6WiWHF/6O8
>N9YFYPjfEWHyd1E1UG9MA+1xHJmbJmFk5o1+/9KyHyCBIVulgTlkztw//qx18fRR
>LyV987RhXc/wtm8DXAvbZtC9ZLn0LJRq5WdKYtKKJuTVi7Sd7uZiSCI2elE3jHPG
>lbTNVO5Jhbf2vQu+0YNsaRacN+/Dpaqm7XfW8wFYdxX1ejk+HIiUogRhQnE3fofE
>Ku+LJOABI5zq8MUiNegavmRjntkLIKi5Ag0EZFCmSwEQANNUsV38bmIxnJyfbpas
>o7jKkp2roGK2T2MhsZA3lV6grHVuSJIfxGSAyZW4l5PdPpZjVT0ccO61Lz0ZsKg6
>69/T5jI+YRt/cydBpvxgQhkQNVcthEO4n4FCIF/I04TgUpEhKgkq4RModBnla1T8
>unNgymqi+8UiQrijWIbmBcemqJPUgSHDMtyhdkGW6oqCG20TB9VPZzLqhouSissP
>94hoyniywwfHi2966DJiedt4TITMs93P1V13hh9BjTYl9Ys5osDV/Qznda7Nvuhw
>+NALQCdlqLZUZDwaDunPtQvzVf0cI81ppUabShG8Ljd7//0AK8/nVAWyiSKZGc9i
>eJ+22uvY4tSSMNZjSIwpXx6jx6GI7f8OHpSN4ELhCX4G+kgNNOnONlyc40aScRGd
>dXcOzAI4gUTMXlGjy67BezPuXNEXDkUbcseJ6BdxYf+kXx5b+vXYXXoa7H61T7J5
>YGylhAyxfNERQhQ/O1pVNnok+r8Snswq8vMlvU5Tr8FZfQFLhY3lHY4/r2OdtVcY
>+O1Eb0kscFSK7lCU3LoJBg8VnXSH0lbVivM6lhkiOTv7oGTRTupoBNe2jwwwZl2f
>QiVsNmzv8c+akoKoXKRPRKkdcwQptacncdKObEOH7nIJqgsYvIa1dKmA7gfK8S7V
>3URV/OgnnqjwQEYi2+YFyB13ABEBAAGJAjwEGAEIACYWIQSnXpsw/HVwqaKCaZHY
>6kx57LaF2AUCZFCmSwIbDAUJAeEzgAAKCRDY6kx57LaF2NM+D/94QJ4GiHgEM347
>dB3f6Wk7A7+xOyshyK4JLrIXpmj71VmMm/4wIkUGZlzzEcwblYyWvKewOOoR+gCD
>Ckl88HAQps78xudtyISAEqS52ZCi3NZzoGnVUDhS97rKtCr8fgx56DFXsIZIaoUB
>lyQc8lzWXOGq9NJorS9tdx7fLX93MlgSv7bTBgGxIRtmMpaLQ5bVQUGWWCtIyW7x
>JwWmm6LKqGyi9ciHhe88tlaXKOaAyXEmPHvJ/fSb+ZPOJhU64LZ6WELCz3sM78MA
>i/vurJzrcJWrXYaemXNtV9X9Oao52gidw7wok43ONphR20dROndfFQBoYP4I3BFp
>z0Twb5ZBB7OIUMvjSHgGCr6x4JWgMwLbL1yx9dy5YfTngmAmvqiAjjYEbIFJbdZm
>4W3qctycWS6VXjQQdoODD5Or4Tn42A8/GFu5luTcT7QojTXj82ntY8Vj8vZOi2fL
>O+rQ9DUTEycE5meXPcyTnc27LNBrCxVAk2lck0yzGkjbtLrTwPQhDaYxzLYn6yi4
>tOAcrzdM762WK1qpPE3FqIGPZ1WuOBrbvwFHPz4MMWRO39nOz2CeFrv8ptqpcigc
>hmPDROp79Adnbzo13YZNFynyUzATscXE5uFwAybR7b4aOj6WaDDGWoPan2Vb1H8w
>YvesRkjSW+cvJgXJM18TSBZwNm454A==
>=yoJ2
>-----END PGP PUBLIC KEY BLOCK-----

Created attachment 13093 [details]
GPG ключ

Created attachment 13094 [details]
SSH ключ

Ничего не изменилось.
GPG ключ (3.09 KB, text/plain) 
SSH ключ (760 bytes, text/plain)

Created attachment 13112 [details]
SSH ключ

Created attachment 13113 [details]
SSH ключ

Created attachment 13114 [details]
GPG ключ

(Ответ для Michael Chernigin на комментарий #10)
> Создано вложение 13114 [details] [подробности]
> GPG ключ

В ключь нужно добавить комментарий, желательно осмысленный, одно-два слова.

(Ответ для Иван Савин на комментарий #11)
> (Ответ для Michael Chernigin на комментарий #10)
> > Создано вложение 13114 [details] [подробности]
> > GPG ключ
> 
> В ключь нужно добавить комментарий, желательно осмысленный, одно-два слова.

И срок действия ключа. Вы хотите его продливать через год?

(In reply to Иван Савин from comment #11)
> В ключ нужно добавить комментарий, желательно осмысленный, одно-два слова.
Да нет, комментарий как раз не нужен если туда нечего написать.  Лучше и проще без комментария, но когда он есть он должен быть осмысленным.

> И срок действия ключа. Вы хотите его продлевать через год?
Это абсолютно нормальная практика, некоторые члены Team так и делают.

Тогда у меня нет вопросов, думаю кандидат разобрался с ключами достаточно.

(In reply to Michael Chernigin from comment #10)
> Created attachment 13114 [details]
> GPG ключ

Этот ключ не подходит соответствует только по одному критерию:

> В ключе должны быть ... и uid вида псевдоним@altlinux.org.
https://www.altlinux.org/Team/Join/Candidate#Сбор_информации

(Ответ для Иван Савин на комментарий #14)
> Тогда у меня нет вопросов, думаю кандидат разобрался с ключами достаточно.

Ладно, помолчу.

Created attachment 13119 [details]
GPG ключ

Секретарь, считаю что кандидат умеет генерировать ключи и готов к следующему шагу.

На данный момент я попробовал собрать 2 пакета.

1. Сборщик статистики о кодовой базе Tokei: https://github.com/mchernigin/tokei
2. Генератор статических сайтов Hugo: https://github.com/mchernigin/hugo

(In reply to Michael Chernigin from comment #9)
> Created attachment 13113 [details]
> SSH ключ
Ok.
(In reply to Michael Chernigin from comment #17)
> Created attachment 13119 [details]
> GPG ключ
Я не понимаю, зачем нужен такой комментарий к ключу, но формально ключ, конечно, соответствует критериям.

Кандидат готов начать встаупление в team.

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

T/J/S -> 2.3.

Прошу кандидата предоставить примеры пакетов на git.altlinux.org.

Добавил 2 пакета на gitery.alt: http://git.altlinux.org/people/chernigin/packages/

(In reply to Michael Chernigin from comment #24)
> Добавил 2 пакета на gitery.alt:
> http://git.altlinux.org/people/chernigin/packages/

Поскольку я прошёл по ссылке, хочу сказать, что не надо экономить на коммитах.  Как минимум, импорт исходников стоит делать в отдельном коммите и в сообщении стоит писать, как эти исходники были получены, т.е. стоит дать URL или список команд, с помощью которых вы получили исходники.

(Ответ для Gleb F-Malinovskiy на комментарий #25)
> (In reply to Michael Chernigin from comment #24)
> > Добавил 2 пакета на gitery.alt:
> > http://git.altlinux.org/people/chernigin/packages/
> 
> Поскольку я прошёл по ссылке, хочу сказать, что не надо экономить на
> коммитах.  Как минимум, импорт исходников стоит делать в отдельном коммите и
> в сообщении стоит писать, как эти исходники были получены, т.е. стоит дать
> URL или список команд, с помощью которых вы получили исходники.

Поправил: теперь есть пустой коммит со ссылкой на источник исходного кода

(Ответ для Michael Chernigin на комментарий #26)
> (Ответ для Gleb F-Malinovskiy на комментарий #25)
> > (In reply to Michael Chernigin from comment #24)
> > > Добавил 2 пакета на gitery.alt:
> > > http://git.altlinux.org/people/chernigin/packages/
> > 
> > Поскольку я прошёл по ссылке, хочу сказать, что не надо экономить на
> > коммитах.  Как минимум, импорт исходников стоит делать в отдельном коммите и
> > в сообщении стоит писать, как эти исходники были получены, т.е. стоит дать
> > URL или список команд, с помощью которых вы получили исходники.
> 
> Поправил: теперь есть пустой коммит со ссылкой на источник исходного кода

Господи, нет. Сдаётся мне, что Глеб имел совершенно не это в виду!

Кандидат, нужно добавить ветку по умолчанию в репозитории.
$ssh gitery default-branch <branch_name>
Как правило, ветка по умолчанию называется "sisyphus".

(Ответ для Иван Савин на комментарий #28)
> $ssh gitery default-branch <branch_name>"

$ssh gitery default-branch <repo_name> <branch_name>".

(In reply to Grigory Ustinov from comment #27)
> (Ответ для Michael Chernigin на комментарий #26)
> > (Ответ для Gleb F-Malinovskiy на комментарий #25)
> > > (In reply to Michael Chernigin from comment #24)
> > > > Добавил 2 пакета на gitery.alt:
> > > > http://git.altlinux.org/people/chernigin/packages/
> > > 
> > > Поскольку я прошёл по ссылке, хочу сказать, что не надо экономить на
> > > коммитах.  Как минимум, импорт исходников стоит делать в отдельном коммите и
> > > в сообщении стоит писать, как эти исходники были получены, т.е. стоит дать
> > > URL или список команд, с помощью которых вы получили исходники.
> > 
> > Поправил: теперь есть пустой коммит со ссылкой на источник исходного кода
> 
> Господи, нет. Сдаётся мне, что Глеб имел совершенно не это в виду!

Тогда я ничего не понял... Что Глеб всё-таки имел в виду?

(In reply to Michael Chernigin from comment #30)
> (In reply to Grigory Ustinov from comment #27)
> > (Ответ для Michael Chernigin на комментарий #26)
> > > (Ответ для Gleb F-Malinovskiy на комментарий #25)
> > > > (In reply to Michael Chernigin from comment #24)
> > > > > Добавил 2 пакета на gitery.alt:
> > > > > http://git.altlinux.org/people/chernigin/packages/
> > > > 
> > > > Поскольку я прошёл по ссылке, хочу сказать, что не надо экономить на
> > > > коммитах.  Как минимум, импорт исходников стоит делать в отдельном коммите и
> > > > в сообщении стоит писать, как эти исходники были получены, т.е. стоит дать
> > > > URL или список команд, с помощью которых вы получили исходники.
> > > 
> > > Поправил: теперь есть пустой коммит со ссылкой на источник исходного кода
> > 
> > Господи, нет. Сдаётся мне, что Глеб имел совершенно не это в виду!
> 
> Тогда я ничего не понял... Что Глеб всё-таки имел в виду?

Я имел в виду, что лучше сделать отдельный коммит с импортом исходников.  И как раз в нём описывать, откуда эти исходники взялись.  И при последующем обновлении исходников тоже стоит делать отдельный коммит.

(In reply to Gleb F-Malinovskiy from comment #31)
> Я имел в виду, что лучше сделать отдельный коммит с импортом исходников.  И
> как раз в нём описывать, откуда эти исходники взялись.  И при последующем
> обновлении исходников тоже стоит делать отдельный коммит.

То есть в репозитории не должно быть других коммитов кроме моих. История должна выглядеть вот так:

* <Michael Chernigin> Update v0.124.0 -> v0.125.0
* <Michael Chernigin> Update v0.123.0 -> v0.124.0
* <Michael Chernigin> Initial build for ALT: adds .gear and spec
* <Michael Chernigin> Source for v0.123.0 code from https://github.com/smth/smth

И тогда история будет полностью повторять сhangelog, за исключением самого первого коммита. Получается, что мы пренебрегаем историей из upstream.

Я всё правильно понял?

(In reply to Michael Chernigin from comment #32)
> (In reply to Gleb F-Malinovskiy from comment #31)
> > Я имел в виду, что лучше сделать отдельный коммит с импортом исходников.  И
> > как раз в нём описывать, откуда эти исходники взялись.  И при последующем
> > обновлении исходников тоже стоит делать отдельный коммит.
> 
> То есть в репозитории не должно быть других коммитов кроме моих. История
> должна выглядеть вот так:
> 
> * <Michael Chernigin> Update v0.124.0 -> v0.125.0
> * <Michael Chernigin> Update v0.123.0 -> v0.124.0
> * <Michael Chernigin> Initial build for ALT: adds .gear and spec
> * <Michael Chernigin> Source for v0.123.0 code from
> https://github.com/smth/smth

Нет, если вы собираете из апстримного git-репозитория, то его историю следует оставить.

У меня начало закрадываться сомнение, что я с самого начала правильно понял, что было сделано у вас.  Для меня это выглядело так, будто у вас весь импорт исходников и добавление спека и сборочных файлов сделан в виде одного коммита, с этим и был связан кой комментарий.  Скорее всего я ошибся из-за того, что на том месте, на котором обычно показывают список коммитов у вас показывается список тегов (он один).  Извините, если я ошибся.  И не забудьте, пожалуйста, последовать совету вашего ментора и установить для ваших git-репозиториев default-branch, именно из-за этого сейчас не отображается список коммитов.

(Ответ для Иван Савин на комментарий #28)
> Кандидат, нужно добавить ветку по умолчанию в репозитории.
> $ssh gitery default-branch <branch_name>
> Как правило, ветка по умолчанию называется "sisyphus".

Готово.

В spec файлах:
1) %changelog : при сборке новой upstream-версии это указывается первым пунктом.
  https://www.altlinux.org/%D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog#%D0%A1%D0%BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B5
  Следует придерживаться этого правила.
 
2) "Packager:" - не обязательныей тег. Писать его не ошибка, так что можно оставить наверное.

(Ответ для Иван Савин на комментарий #35)
> В spec файлах:
> 1) %changelog : при сборке новой upstream-версии это указывается первым
> пунктом.
>  
> https://www.altlinux.org/
> %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%
> BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog#%D0%A1%D0
> %BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B5
>   Следует придерживаться этого правила.
>  
> 2) "Packager:" - не обязательныей тег. Писать его не ошибка, так что можно
> оставить наверное.

Добавил в сообщениях хэш коммита и ветку, а так же поле Vcs с ссылкой на upstream. Packager решил оставить в текущем виде.

(Ответ для Michael Chernigin на комментарий #36)
> (Ответ для Иван Савин на комментарий #35)
> > В spec файлах:
> > 1) %changelog : при сборке новой upstream-версии это указывается первым
> > пунктом.
> >  
> > https://www.altlinux.org/
> > %D0%A0%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE_%D0%BF%D0%
> > BE_%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D1%8E_changelog#%D0%A1%D0
> > %BE%D0%B4%D0%B5%D1%80%D0%B6%D0%B8%D0%BC%D0%BE%D0%B5
> >   Следует придерживаться этого правила.
> >  
> > 2) "Packager:" - не обязательныей тег. Писать его не ошибка, так что можно
> > оставить наверное.
> 
> Добавил в сообщениях хэш коммита и ветку, а так же поле Vcs с ссылкой на
> upstream. Packager решил оставить в текущем виде.

Изменять одну запись %changelog'а в разных коммитах плохая идея, это может запутать. Изменения, которые у Вас в релизе 2 (alt2) должны быть в первом, второй тут не нужен. Лучше переделать.

(Ответ для Иван Савин на комментарий #37)
> Изменять одну запись %changelog'а в разных коммитах плохая идея, это может
> запутать. Изменения, которые у Вас в релизе 2 (alt2) должны быть в первом,
> второй тут не нужен. Лучше переделать.

Переделал.

Меня смущают огромные коммиты 'Vendor packages'. diff'ы на 3,4 и 1,6 миллиона строк.
Как будут сопровождаться эти вендорские библиотеки?

(In reply to Иван Савин from comment #39)
> Меня смущают огромные коммиты 'Vendor packages'. diff'ы на 3,4 и 1,6
> миллиона строк.
> Как будут сопровождаться эти вендорские библиотеки?

Как я понял, именно так и пакетируются вещи, написанные на Go или Rust. По крайней мере, все пакеты, которые я нашёл, делают именно так.

Примеры на Rust:
- https://git.altlinux.org/gears/r/ripgrep.git
- https://git.altlinux.org/gears/g/git-delta.git
- https://git.altlinux.org/gears/j/just.git

Примеры на Go:
- https://git.altlinux.org/gears/c/caddy.git
- https://git.altlinux.org/gears/m/minio.git
- https://git.altlinux.org/gears/d/docker-engine.git

В обоих языках есть файл, в котором перечислены все зависимости с указанием версии. Инструменты сборки `go` и `cargo` позволяют генерировать папку `vendor` для сборки без доступа к сети. Идея в том, чтобы вместе с каждым будущим обновлением списка зависимостей повторно выполнять команду `cargo vendor`, например, для обновления исходного кода зависимостей. Тогда в репозитории будет всегда лежать папка с актуальным исходным кодом используемых библиотек.

Я бы хотел ещё запакетировать [difftastic](https://github.com/Wilfred/difftastic), которым сам пользуюсь. Это diff для git, который парсит исходный код и показывает разницу по токенам.

Только с ним возникает такая проблема: upstream содержит свои реализации парсеров для большого числа языков программирования. Плюс ещё зависимости в папке `vendor`, необходимые для сборки без доступа к сети.

```
difftastic (sisyphus) > du -h -d 1 .
1,4G    ./.git
12K     ./scripts
12K     ./tests
48K     ./img
762M    ./vendored_parsers
46M     ./sample_files
480K    ./src
12K     ./.gear
120K    ./manual
32K     ./.github
228M    ./vendor
120K    ./translation
2,4G    .
```

По итогу получается репозиторий размером в 2,4 GB, который я не могу отправить в gitery без поднятия квоты. Возникают 2 вопроса.
1. Стоит ли мне вообще так делать, или репозиторий на 2,4 GB — это плохая идея?
2. Если стоит, то что нужно сделать для понятия квоты?

(In reply to Michael Chernigin from comment #41)
> difftastic (sisyphus) > du -h -d 1 .
> 1,4G    ./.git
> 2,4G    .
> 
> По итогу получается репозиторий размером в 2,4 GB

Размер репозитория - это размер каталога .git, добавлять к нему размер working copy незачем.

> 2. Если стоит, то что нужно сделать для понятия квоты?

Запросить увеличение квоты.

(Ответ для Michael Chernigin на комментарий #40)
> (In reply to Иван Савин from comment #39)
> > Меня смущают огромные коммиты 'Vendor packages'. diff'ы на 3,4 и 1,6
> > миллиона строк.
> > Как будут сопровождаться эти вендорские библиотеки?
> 
> Как я понял, именно так и пакетируются вещи, написанные на Go или Rust. По
> крайней мере, все пакеты, которые я нашёл, делают именно так.
> 
> Примеры на Rust:
> - https://git.altlinux.org/gears/r/ripgrep.git
> - https://git.altlinux.org/gears/g/git-delta.git
> - https://git.altlinux.org/gears/j/just.git
> 
> Примеры на Go:
> - https://git.altlinux.org/gears/c/caddy.git
> - https://git.altlinux.org/gears/m/minio.git
> - https://git.altlinux.org/gears/d/docker-engine.git
> 
> В обоих языках есть файл, в котором перечислены все зависимости с указанием
> версии. Инструменты сборки `go` и `cargo` позволяют генерировать папку
> `vendor` для сборки без доступа к сети. Идея в том, чтобы вместе с каждым
> будущим обновлением списка зависимостей повторно выполнять команду `cargo
> vendor`, например, для обновления исходного кода зависимостей. Тогда в
> репозитории будет всегда лежать папка с актуальным исходным кодом
> используемых библиотек.

Ясно.

Считаю, что кандидат готов к следующему шагу.
Прошу секретаря дать доступ к сборочнице.

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

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

T/J/S -> 3.5.

Успешно собрались:
- difftastic: https://packages.altlinux.org/tasks/326437
- hugo: https://packages.altlinux.org/tasks/326435
- tokei: https://packages.altlinux.org/tasks/326434

На ppc64le не собирается tealdeer, из-за зависимости ring: https://bugzilla.redhat.com/show_bug.cgi?id=1869980

Добавил ppc64le в ExcludeArch, всё успешно собралось: https://packages.altlinux.org/tasks/326439/

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

Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.

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

T/J/S -> 4.2.

(Ответ для Michael Chernigin на комментарий #47)
> Успешно собрались:
> - difftastic: https://packages.altlinux.org/tasks/326437
> - hugo: https://packages.altlinux.org/tasks/326435
> - tokei: https://packages.altlinux.org/tasks/326434
> 
> На ppc64le не собирается tealdeer, из-за зависимости ring:
> https://bugzilla.redhat.com/show_bug.cgi?id=1869980
> 
> Добавил ppc64le в ExcludeArch, всё успешно собралось:
> https://packages.altlinux.org/tasks/326439/

Посмотрел и одобрил. Замечаний серьёзных нет.
Посмотрел, что кандидат за прошедшее разработал библиотеку libqbase и опакетил её:
https://packages.altlinux.org/ru/sisyphus/srpms/libqbase/

Есть несколько замечаний:
- в Summary точку ставить в конце не надо, а вот в %description в конце каждого предложения нужно ставить точку
- группу пакету стоит назначить Development/C++
- не очень понял, почему нет библиотеки с soname в отдельном пакете, но пакеты с header'ами и библиотеками без soname в %_libdir должны называться имя-devel
- Url указан старый, надо было после изменения имени проекта и Url в спеке актуализировать. Редирект хорошо, но сразу правильный лучше
- макрос %cmakeinstall_std устарел, надо %cmake_install использовать

Но проект давно не обновлялся. Он актуален?

Также кандидат недавно дорабатывал пакет alterator-manager и собрал версию 0.1.15-alt1. Без замечаний.

Жду одобренные пакеты в Сизифе и ответ про актуальность libqbase.

А ещё жду от кандидата, что он удалит старые неактуальные тестовые задания.
И нужно научиться удалять субтаски и добавлять новые. Столько старых заданий поэтому.

1. Пакеты, которые были одобрены, отправил в Сизиф (hugo, tealdeer, difftastic и tokei).
2. libqbase актуален. Устранил замечания, спасибо, собрал новую версию с тегом 0.1.0-alt2. Если получу одобоение, отправлю в Сизиф.
3. Прибрался на gyle.

(Ответ для Michael Chernigin на комментарий #53)
> 1. Пакеты, которые были одобрены, отправил в Сизиф (hugo, tealdeer,
> difftastic и tokei).

Отлично.

> 2. libqbase актуален. Устранил замечания, спасибо, собрал новую версию с
> тегом 0.1.0-alt2. Если получу одобрение, отправлю в Сизиф.

Отлично. Одобрил.

> 3. Прибрался на gyle.

Отлично.

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

Пользователь добавлен в группу мейнтейнеров.

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