> Имя ментора: Егор
> Почта ментора: egori@altlinux.org

Подтверждаю.

Created attachment 9454 [details]
GPG

Created attachment 9455 [details]
SHH

(Ответ для Дмитрий на комментарий #3)
> Создано вложение 9455 [details] [подробности]
> SHH
Ok.

(Ответ для Дмитрий на комментарий #2)
> Создано вложение 9454 [details] [подробности]
> GPG

Мы просим делать uid в ключе в формате Firstname Lastname.

Created attachment 9463 [details]
GPG

исправил

(Ответ для Дмитрий на комментарий #5)
> Создано вложение 9463 [details] [подробности]
> GPG
Ok.

(Ответ для Дмитрий на комментарий #0)
> адрес пересылки почты: fruktime@altlinux.org
А на какой адрес пересылать почту для fruktime@a.o?

(Ответ для Gleb F-Malinovskiy на комментарий #6)
> (Ответ для Дмитрий на комментарий #5)
> > Создано вложение 9463 [details] [подробности]
> > GPG
> Ok.
> 
> (Ответ для Дмитрий на комментарий #0)
> > адрес пересылки почты: fruktime@altlinux.org
> А на какой адрес пересылать почту для fruktime@a.o?

fruktime@basealt.ru

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

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

Не могу залогиниться на gyle и gitary по ключу 
ssh: sign_and_send_pubkey: signing failed: agent refused operation
ssh: git_fruktime@gyle.altlinux.org: Permission denied (publickey).

config файл прописал

(In reply to Дмитрий from comment #10)
> ssh: sign_and_send_pubkey: signing failed: agent refused operation

Эта фраза значит, что вы используете ssh-agent, а он по какой-то причине на даёт использовать ключ.
Чаще всего это значит, что используется ключ без пароля (не самая лучшая практика), ~/.xprofile успешно загрузил ключ в ssh-agent в режиме подтверждения каждой операции, а ssh-agent не смог запросить подтверждение (либо потому что у вас нет ssh-askpass, либо потому что ssh-askpass не смог запустить графическое окошко).

Реализации ssh-askpass:
$ apt-cache show /usr/lib/openssh/ssh-askpass
Package /usr/lib/openssh/ssh-askpass is a virtual package provided by:
  x11-ssh-askpass 1:1.2.4.1-alt5:sisyphus+278100.7500.1.1@1626060657
  plasma5-ksshaskpass 1:5.22.3-alt1:sisyphus+277521.2100.4.3@1625815540
  gtk2-ssh-askpass 5.4p1-alt1:sisyphus+278100.2000.1.1@1626058462
You should explicitly select one to show.
E: Package /usr/lib/openssh/ssh-askpass is a virtual package with multiple providers.

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

Текущий репозиторий: https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-environ.git;a=summary

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

T/J/S -> 3.5.

Считаю, что кандитат освоил сборку пакетов разных типов и готов отправлять пакеты в Сизиф.

Прошу призвать рецензента для независимой оценки готовности кандидата.

Текущие репозитории:
https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-storages.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-minify-html.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-htmlmin.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-environ.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=minify-html.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=ttyd.git;a=summary

А также обновлены:
https://git.altlinux.org/people/fruktime/packages/?p=python3-module-django-ckeditor.git;a=summary
https://git.altlinux.org/people/fruktime/packages/?p=libwebsockets.git;a=summary

так и не призвали рецензента

Я готов быть вторым ментором, если есть проблемы с поиском.

Честно говоря, я эту багу в упор не замечаю потому что она не в том статусе.

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

Общие замечания:

* Наш rpm поддерживает тег VCS, его не нужно оставлять закомментированным.
* У вас в некоторых файлах No newline at end of file, а в некоторых других, наоборот, new blank line at EOF (иногда даже две), это касается почти всех ваших пакетов.  (совет) Посмотрите на pre-commit hook, который идёт прямо в комплекте с git, он сообщает о таких ошибках (а заодно ещё и о некоторых других).  Я сделал у себя так, чтобы он включался во всех моих git-репозиториях.
* (принцип наименьшего удивления) Почему-то почти во всех spec-ах вы везде делаете два перевода строки между секциями %files и %changelog, хотя во всех остальных местах вы этого не делаете, в первый раз это кажется случайностью, но в итоге выглядит как непоследовательный стиль.
* (мысли вслух) Лично мне не нравится практика складывания абсолютно всех файлов, связанных со сборкой пакета в каталог .gear/.  Обычно, когда я собираю пакет из апстримного git-а, я кладу и spec и все дополнительные файлы в каталог alt/ потому что .gear предназначен для конфигурации.

python3-module-django-minify-html

* Почему ExcludeArch: i586 armh?  О таких вещах лучше писать рядом в виде комментария.


python3-module-django-htmlmin

* Версионирование нерелизных коммитов из апстрима.
 ** (совет) Вместо version:  0.11.0, release: alt0.git.01575db, лучше
использовать версию производную от той, которую даёт git describe,
т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version:
0.11.0.21.g01575db, а релиз делал alt1.  Идея в том, что версия это версия апстримного кода, а релиз это версия нашего пакета, предлагаемый подход гораздо лучше отражает это разделение.
 ** (совет) Лучше никогда не использовать alt0 в релизе, это плохая привычка
потому что для релиза alt0.git.01575db очень сложно сделать *меньший*,
например если нужно собрать backport в бранч.


python3-module-django-environ

* В этом пакете что-то не так пошло с commit message, я не понимаю, что в нём написано.


minify-html

В этом пакете я не очень понимаю, что и откуда растёт и как должно было выглядеть.
* В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного пробела.
  ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть лучше записать то, что он делает прямо в спек-файл?  По сути, когда вы запускаете в скрипте git archive, вы делаете то же самое, что делает gear, но заново.  Я делал похожую вещь в пакете shellcheck, там я реализовал специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки пакета скачиваются все нужные исходники.
* В коммите 94ef1e1 вы добавляете сгенерированные файлы.  Откуда они берутся?  Нельзя ли их генерировать во время сборки пакета?
* Почему ExcludeArch: ?


ttyd

* Почему-то в BuildRequires попал vim-common.  Вообще-то есть инструмент для получения списка необходимых сборочных зависимостей, посмотрите на buildreq.


python3-module-django-ckeditor
* В коммите 3ffa4 вопреки commit message просто в другое место добавляется spec-файл, а старый spec-файл пропадает почему-то в мерж-коммите 4937e4, это сбивает с толку, если честно.  Я понимаю, что вы хотели поменять схему сборки пакета, но получилось совершенно непонятно с точки зрения git-овой истории.


libwebsockets
* По поводу коммита 050fd54:
 ** Использовали ли вы утилиту gear-import для импорта исходников?  Это хороший способ делать это правильно.
 ** (совет) Я бы использовал "Import <url>" в качестве commit message, так будет сразу понятно, что именно и откуда было импортировано.
* Было бы гораздо лучше, если бы вы отразили в %changelog то изменение, которое вы сделали в этом пакете.  Вы же включили в нём дополнительную функциональность, а не только обновили его, а это стоит отражать в %changelog.
* При обновлении у пакета поменялся soname.  Посмотрите, пожалуйста https://www.altlinux.org/Shared_Libs_Policy

В целом, ваши более новые пакеты выглядят достаточно хорошо (за мелких замечаний), можно завершить вступление в команду.  Не забывайте, что грамотное оформление git-репозитория и %changelog поможет другим людям (например, вам самому через несколько лет) понять, зачем и как что-то было сделано.

(In reply to Gleb F-Malinovskiy from comment #18)

> python3-module-django-htmlmin
> 
> * Версионирование нерелизных коммитов из апстрима.
>  ** (совет) Вместо version:  0.11.0, release: alt0.git.01575db, лучше
> использовать версию производную от той, которую даёт git describe,
> т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version:
> 0.11.0.21.g01575db, а релиз делал alt1.  Идея в том, что версия это версия
> апстримного кода, а релиз это версия нашего пакета, предлагаемый подход
> гораздо лучше отражает это разделение.
В таком случае думаю стоит обновить вики.
https://www.altlinux.org/Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B%D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B
"При сборке промежуточных релизов upstream-кода (срезов по дате, по системе контроля версий), следует указывать информацию о срезе в поле Release:"


> minify-html
> 
> В этом пакете я не очень понимаю, что и откуда растёт и как должно было
> выглядеть.
> * В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это
> хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного
> пробела.
Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не раздувать репозиторий. По похожей схеме собирается например alacritty.
>   ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть
> лучше записать то, что он делает прямо в спек-файл?  По сути, когда вы
> запускаете в скрипте git archive, вы делаете то же самое, что делает gear,
> но заново.  Я делал похожую вещь в пакете shellcheck, там я реализовал
> специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки
> пакета скачиваются все нужные исходники.
Как по мне, внешний скрипт, который вендорит зависимости, гораздо понятнее, чем 'специальный режим' в спеке, это, конечно, красиво, но ИМХО мисюз.
Хотя сам бы я коммитил зависимости в гит и не мучался с srpm.

> python3-module-django-ckeditor
> * В коммите 3ffa4 вопреки commit message просто в другое место добавляется
> spec-файл, а старый spec-файл пропадает почему-то в мерж-коммите 4937e4, это
> сбивает с толку, если честно.  Я понимаю, что вы хотели поменять схему
> сборки пакета, но получилось совершенно непонятно с точки зрения git-овой
> истории.
Да, странно, что в 3ffa490 есть сразу 2 django-ckeditor.spec


В остальном согласен с Глебом.
Дим, исправь, пожалуйста, что можно исправить.

(In reply to Egor Ignatov from comment #19)
> (In reply to Gleb F-Malinovskiy from comment #18)
> >  ** (совет) Вместо version:  0.11.0, release: alt0.git.01575db, лучше
> > использовать версию производную от той, которую даёт git describe,
> > т.е. в этом случае 0.11.0-21-g01575db я бы превратил в version:
> > 0.11.0.21.g01575db, а релиз делал alt1.  Идея в том, что версия это версия
> > апстримного кода, а релиз это версия нашего пакета, предлагаемый подход
> > гораздо лучше отражает это разделение.
> В таком случае думаю стоит обновить вики.
> https://www.altlinux.org/
> Spec#%D0%9F%D1%80%D0%BE%D0%BC%D0%B5%D0%B6%D1%83%D1%82%D0%BE%D1%87%D0%BD%D1%8B
> %D0%B5_upstream-%D1%80%D0%B5%D0%BB%D0%B8%D0%B7%D1%8B
> "При сборке промежуточных релизов upstream-кода (срезов по дате, по системе
> контроля версий), следует указывать информацию о срезе в поле Release:"

Это был просто совет -- оба варианта рабочие, но на вики точно стоит написать о таком способе, если не написано.

> > minify-html
> > 
> > В этом пакете я не очень понимаю, что и откуда растёт и как должно было
> > выглядеть.
> > * В коммите b9ff2db вы добавляете целый скрипт для получения crates.tar (это
> > хорошая идея), но crates.tar так и остаётся файлом, состоящим из одного
> > пробела.
> Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не
> раздувать репозиторий. По похожей схеме собирается например alacritty.
В таком случае об этом стоит написать в spec-е, написать инструкцию (в идеале со скриптом) по получению сгенерированного исходного кода и класть сгенерированный код (хотя бы средствами gear) в отдельный tarball.

> >   ** (мысли вслух) Если код из этого скрипта всё же нужен, то может быть
> > лучше записать то, что он делает прямо в спек-файл?  По сути, когда вы
> > запускаете в скрипте git archive, вы делаете то же самое, что делает gear,
> > но заново.  Я делал похожую вещь в пакете shellcheck, там я реализовал
> > специальный режим, в котором при сборке пакета нужна сеть, но вместо сборки
> > пакета скачиваются все нужные исходники.
> Как по мне, внешний скрипт, который вендорит зависимости, гораздо понятнее,
> чем 'специальный режим' в спеке, это, конечно, красиво, но ИМХО мисюз.
> Хотя сам бы я коммитил зависимости в гит и не мучался с srpm.
Согласен, что мисюз, но я бы этим скриптом не смог сходу воспользоваться, его бы пришлось для этого прочитать, а всё что в spec-е работает в воспроизводимой изолированной среде с известными свойствами.

Я спрошу здесь, что бы не заводить пока что отдельную багу.

А почему бы нам не приравнять каталог altlinux/ в дереве к .gear/ по смыслу (в gear) ?

Тогда все, что надо для сборки лежало бы в осмысленном каталоге altlinux (по аналогии с debian) и одним камнем преткновения было бы меньше.

(In reply to Anton Farygin from comment #21)
> Я спрошу здесь, что бы не заводить пока что отдельную багу.
> 
> А почему бы нам не приравнять каталог altlinux/ в дереве к .gear/ по смыслу
> (в gear) ?

.gear-rules и .gear/rules это уже слишком много вариантов, а ты предлагаешь это ещё усложнить, тем более, что выбрать название этого дополнительного каталога будет сложно.

> Тогда все, что надо для сборки лежало бы в осмысленном каталоге altlinux (по
> аналогии с debian) и одним камнем преткновения было бы меньше.

Мне не кажется, что это такой уж камень преткновения.  Я просто привык, что .gear/rules единственный файл, который нужно менять в .gear, а остальные файлы меняют только инструменты.  А спек может быть где угодно, почему именно здесь?

(In reply to Anton Farygin from comment #21)
> Я спрошу здесь, что бы не заводить пока что отдельную багу.

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

(In reply to Gleb F-Malinovskiy from comment #20)
> (In reply to Egor Ignatov from comment #19)
> > Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не
> > раздувать репозиторий. По похожей схеме собирается например alacritty.
> В таком случае об этом стоит написать в spec-е, написать инструкцию (в
> идеале со скриптом) по получению сгенерированного исходного кода и класть
> сгенерированный код (хотя бы средствами gear) в отдельный tarball.
Хочу вернуться чуть-чуть к этому вопросу: мне кажется, что такой путь очень сложный...

> > Хотя сам бы я коммитил зависимости в гит и не мучался с srpm.
... и стоит делать вот так.
Потому что:
1. сгенерированные исходники лучше генерировать при сборке пакета потому что так проще всего показать, откуда они берутся и как;
2. экономия на размере репозитория это экономия на спичках, а п. 1. важнее.

(Ответ для Gleb F-Malinovskiy на комментарий #24)
> (In reply to Gleb F-Malinovskiy from comment #20)
> > (In reply to Egor Ignatov from comment #19)
> > > Это сделано, чтобы не тянуть в git историю блобы с зависимостями и не
> > > раздувать репозиторий. По похожей схеме собирается например alacritty.
> > В таком случае об этом стоит написать в spec-е, написать инструкцию (в
> > идеале со скриптом) по получению сгенерированного исходного кода и класть
> > сгенерированный код (хотя бы средствами gear) в отдельный tarball.
> Хочу вернуться чуть-чуть к этому вопросу: мне кажется, что такой путь очень
> сложный...
> 
> > > Хотя сам бы я коммитил зависимости в гит и не мучался с srpm.
> ... и стоит делать вот так.
> Потому что:
> 1. сгенерированные исходники лучше генерировать при сборке пакета потому что
> так проще всего показать, откуда они берутся и как;
> 2. экономия на размере репозитория это экономия на спичках, а п. 1. важнее.

Так не получится сделать, у некоторых зависимостей есть папка .git, и чексуммы считаются с учетом этой папки, а если тянуть зависимости в репозиторий, то .git игнорится и чексуммы в итоге не совпадают.
Можно собрать без отдельного скрипта например как тут: https://packages.altlinux.org/ru/sisyphus/srpms/rust-cargo-c/specfiles/

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

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