Created attachment 17705 [details] GPG Давид Султаниязов (x1z53) <x1z53@корсаков.рус> Ментор: Георгий Курячий <george@altlinux.org> Цель: Познакомиться со сборкой пакетов для ALT Linux, собирать востребованные сообществом пакеты. Сборка пакетов с использованием сборочных систем Meson, Make, CMake и без сборочных систем.
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
Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
