Created attachment 17706 [details]
SSH

(In reply to X1Z53 from comment #0)
> Created attachment 17705 [details]
> GPG
Этот ключ не соответствует требованриям сразу по многим пунктам:
https://www.altlinux.org/Team/Join/Candidate#Сбор_информации

Created attachment 17708 [details]
GPG

На мой вкус, ужасный ник. :)

Ключи ОК.

Я готов

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

T/J/S -> 2.3.

В тренировочном режиме собрал 4 несложных пакета и опубликовал на git.altlinux.org:

- https://git.altlinux.org/people/x1z53/packages/barcoder.git
- https://git.altlinux.org/people/x1z53/packages/bmi.git
- https://git.altlinux.org/people/x1z53/packages/diffuse.git
- https://git.altlinux.org/people/x1z53/packages/tactics.git

→ 3.0
Считаю, что пора уже собирать пакеты, в том числе на всякие архитектуры.
Duffuse так вообще хочу в Сизиф уже)

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

T/J/S -> 3.6.

Подготовил к сборке пакет `tcc` по указанию ментора

https://packages.altlinux.org/ru/tasks/378460/

Считаю, что пора призвать метнора
T/J/S -> 4.0

> метнора
Рецензента, разумеется)

Я не "официальный рецензент", но самопризвался из-за gtk тем, собранных в https://git.altlinux.org/tasks/384498/, т.к. они собирались в первую очередь с прицелом возможности использования в Simply Linux.
Для начала мне традиционно не нравится размещение спеков в .gear/:
в этом каталоге размещаются служебные файлы, имеющие отношение к
внутренней кухне самого инструмента gear (тот же rules). Spec, патчи и
т.д. к этой категории явно не относятся. Если зачем-то хочется
разместить эти файлы в подкаталоге, то можно создать свой с именем alt
или altlinux, например (по аналогии с debian).
Но, строго говоря, это не ошибка, часть мантейнеров так зачем-то делает, а policy
на этот счет у нас нет.

По самим пакетам: разделение на подпакеты по цветам крайне неудачное, лучше разделить по версии gtk: gtk2-theme-*, gtk3-theme-*, gtk4-theme-*, ну и можно сделать пустой пакет gtk-theme-*, который вытянет все остальные. Так, например, зависимость на gtk2-themes-murrine будет только у пакета gtk2-theme-* и не будет тянуть gtk2 тем, кому не надо. Для включения в SL это вообще блокер, кстати, т.к в новой версии я избавляюсь от gtk2 там.
Примерно так я собираю https://git.altlinux.org/people/sem/packages/gtk-theme-greybird.git?p=gtk-theme-greybird.git;a=blob;f=gtk-theme-greybird.spec;h=54bb4415a7818535cf4bd197da6f82e5dcea948f;hb=7df150ebcafa3a88a235350161f6a2d2cb921610
Плюс там gtk-theme-greybird-common для каталогов и файлов, общих для всех gtk*-theme-* пакетов, например index.theme.
Также части для конкретных WM тоже выделены в отдельные подпакеты (xfwm4-theme-greybird, openbox-theme-greybird, metacity-theme-greybird) т.к они нужны только соответствующим WM. Но тут уже надо смотреть по целесообразности, например каталоги для plank и gnome-shell я отдельно запаковывать не стал: там всего по одному небольшому файлу лежит.
Можно, конечно, еще и по цветам распилить (gtk*-theme-*-<цвет>), но это уже лишнее, пусть все варианты для одной версии gtk ставятся.

Хуже всего с темой Otis: просто скопировать содержимое гита для установки не вариант.
В результате устанавливаются скрипты на shell и python, из-за чего пакет получает зависимости на python и git-core. Очевидно, что паковать их не надо, зато они скорее всего должны запускаться при сборке для рендеринга каких-то изображений. Апстрим, к сожалению, никакого make-файла для этого не предоставляет, так что надо либо разбираться что они делают и запускать их при сборке из гита, либо вообще не использовать сборку из апстримного гита и собирать из релизных тарболлов апстрима.

(Ответ для Mikhail Efremov на комментарий #13)
> Для начала мне традиционно не нравится размещение спеков в .gear/:
> в этом каталоге размещаются служебные файлы, имеющие отношение к
> внутренней кухне самого инструмента gear (тот же rules). Spec, патчи и
> т.д. к этой категории явно не относятся. Если зачем-то хочется
> разместить эти файлы в подкаталоге, то можно создать свой с именем alt
> или altlinux, например (по аналогии с debian).
> Но, строго говоря, это не ошибка, часть мантейнеров так зачем-то делает, а
> policy
> на этот счет у нас нет.

Не имею чего-либо против подобного, однако лично я помещаю Spec-файлы и другие файлы, связанные со сборкой, в директорию `.gear` для того, чтобы отделять то, что нужно для сборки, и исходное содержимое репозитория проектов.

Как вы отметили, полиси по этому поводу нет, поэтому я бы продолжить делать так.

(Ответ для Mikhail Efremov на комментарий #13)
> Для начала мне традиционно не нравится размещение спеков в .gear/:
> в этом каталоге размещаются служебные файлы, имеющие отношение к
> внутренней кухне самого инструмента gear (тот же rules). Spec, патчи и
> т.д. к этой категории явно не относятся. Если зачем-то хочется
> разместить эти файлы в подкаталоге, то можно создать свой с именем alt
> или altlinux, например (по аналогии с debian).
> Но, строго говоря, это не ошибка, часть мантейнеров так зачем-то делает, а
> policy
> на этот счет у нас нет.

Я зачем-то так и делаю и пожалуй даже готов вступить в дебаты по этому вопросу. На мой взгляд, каталог .gear как раз идеально подходит для хранения и спеков и патчей и даже... не побоюсь так сказать для хранения конфигов, десктопфайлов и любой другой требухи, которая в принципе указывается в rules. И у меня есть следующие аргументы:
1.) Каталог .gear по смыслу как будто содержит именно сборочную требуху. По аналогии с каталогом debian например. Он действительно прекрасно отделяет сорсы от сборочных файлов.
2.) Почему не alt, .alt, altlinux и так далее? Во-первых унификация. Во-вторых, .gear автоматически эксклюдится в команде tar:. насколько мне известно. А если размещать спек в каталоге .alt его надо будет эксклюдить дополнительно
3.) В случаях мерджконфликтов, технология с git read-tree @tag@; git co -- .gear; git commit намного проще, чем как я делаю в том же пакете python3, где git co -- .gear *.spec *.patch *.sh *.cfg и ещё куча всего.

(Ответ для Grigory Ustinov на комментарий #15)
> Я зачем-то так и делаю и пожалуй даже готов вступить в дебаты по этому

Я думаю тут все же не место для таких обсуждений. Свое мнение я высказал: .gear для gear это аналог .git для git, например, мусору там не место. Но полиси нет, так что странные вещи делать никто не запрещает.

Я посмотрел новые сборки тем в https://git.altlinux.org/tasks/388298/ (пожалуйста, пишите о новых сборках здесь или письмом мне на sem@, об этом таске я узнал фактически случайно).
В xfwm4-theme-otis все еще зависимость на git-core из-за скрипта render_assets.sh, render_assets.fish там тоже явно не нужен. Их можно удалить после установки или пометить как %exclude.
Пакет gtk-theme-*, вытягивающий все остальное, есть только для темы orchis, причем в нем запакован README.md, который также запакован в gtk-theme-orchis-common. Не вижу в этом смысла, gtk-theme-orchis может быть совсем пустым пакетом без файлов.
В принципе, наличие gtk-theme-* я считаю не обязательным, хотя и удобным, но в спеках прописаны requires для него, поэтому выглядит так, что намерение его добавить было.
Ну и описание пакетов xfwm4-theme-* не корректно: это темы именно Xfwm4, а не Xfce.
В остальном у меня замечаний нет.

В новой сборке пакетов gtk-theme-* нет ни для одной темы, но будем считать, что так и задумывалось. В остальном замечаний нет, пропускаю.

(In reply to Mikhail Efremov from comment #13)
> Я не "официальный рецензент", но самопризвался
А можешь как официальный посмотреть всё остальное? Если да, то -> 4.2.

(Ответ для Gleb F-Malinovskiy на комментарий #19)
> (In reply to Mikhail Efremov from comment #13)
> > Я не "официальный рецензент", но самопризвался
> А можешь как официальный посмотреть всё остальное? Если да, то -> 4.2.

Ок, я готов.

(Ответ для X1Z53 на комментарий #7)
> В тренировочном режиме собрал 4 несложных пакета и опубликовал на
> git.altlinux.org:
> 
> - https://git.altlinux.org/people/x1z53/packages/barcoder.git
> - https://git.altlinux.org/people/x1z53/packages/bmi.git
> - https://git.altlinux.org/people/x1z53/packages/diffuse.git
> - https://git.altlinux.org/people/x1z53/packages/tactics.git

В description barcoder "&" так и останется, это же не html.
Использовать %def_enable check для BuildRequires плохая идея: в случае использования опций --without check/--disable test/--without test %check отключится, а пакеты из BuildRequires для тестов все равно установятся. См. https://www.altlinux.org/Spec#%check
Ну и %find_lang везде, кроме diffuse, бесполезен, хоть и не мешает: там нет переводов.

Бегло посмотрел еще пакеты, вижу везде используется %find_lang --with-gnome, даже там, где явно ничего от gnome нет. См. https://www.altlinux.org/FindLang_Policy

Мои замечания исправлены, также выборочно посмотрел другие недавно измененные пакеты в x1z53/packages/ (все не смотрел, их слишком много).
У меня серьезных замечаний больше нет, думаю кандидат готов собирать пакеты.

T/J/S -> 5.0

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

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