Created attachment 17040 [details]
Публичная часть SSH-ключа

Менторство подтверждаю.

Прошу выдать гитовницу!

Ментор есть, ключи в порядке.

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

T/J/S -> 2.3.

Прошу выдать доступ к сборочнице.

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

T/J/S -> 3.6.

Кандидат собрал очень большое количество пакетов и мне кажется, что уловил основные тенденции сборки по альт. Рекомендую его для дальнейших проверок рецензентам.

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

T/J/S -> 4.2.

https://git.altlinux.org/tasks/archive/done/_379/388339/logs/events.2.3.log

В пакетах opensnitch лучше исправить ошибки с неупакованными каталогами.
Как раз вышла новая версия. Присылайте на review обновление.

В git мне не очень понравилось то, что тарболл делается всего дерева. Лучше делать тарболлы отдельно для вендоринга, отдельно для апстрима (из тэга). Так нагляднее видно в src.rpm ваши изменения.
----
В пакете  libphosphor-logging https://packages.altlinux.org/ru/tasks/382793/ вы не использовали SharedLibsPolicy - этот пакет надо переделать, пока на него не появились зависимости.

В этом же пакете надо улучшить description, сейчас он дублирует summary и очень слабый.
И в нём же надо попробовать включить тесты.
----
В пакете conky https://packages.altlinux.org/ru/tasks/382376/ проделана большая работа, но URL в specfile остался недействительный (идёт редирект). Такое лучше всегда проверять и исправлять при каждом изменении пакета.

И в этом же пакете апстрим сделал достаточно много тестов, которые лучше выполнить в секции %check
----
https://packages.altlinux.org/ru/tasks/381934/ 
пакет libgovarnam не сделан в соответствии с shared libs policy, это надо обязательно исправить. Так-же надо включить тесты (это замечание касается всех пакетов).
https://bugzilla.altlinux.org/54897 - не надо ждать реакции апстрима, если у нас пакет сломан надо чинить.
Ну и у вас в пакете, который использует эту библиотеку почему-то отключен PkgConfig. Это криво, предлагаю данный патч убрать и исправить работу c pkgconfig.

Итого из того что я посмотрел - кандидат проделал большую работу но пока не готов к самостоятельной работе в репозитории. Менторы (cas и grenka) многие вещи апрувили без достаточной проверки.
Предлагаю кандидату попробовать исправить все озвученные проблемы, в том числе в тех пакетах которые я не посморел (очевидно что недопонимание необходимости использования SharedLibsPolicy прослеживается везде).

Присылайте новые задания на ревью уже мне (можно в телеграм).

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

(In reply to Ulysses Apokin from comment #11)
> Антон, отправлял вам таски на почту.
> Сегодня продублировал письма.

Ответил по почте, спасибо.

https://git.altlinux.org/tasks/401479/gears/500/git?p=git;a=commitdiff;h=549b25ffb89e3fd6ee71af280a52834224338048

%{name}_%soversion-devel -- это черезчур.

Обсуждение происходит в https://bugzilla.altlinux.org/56619
Eigen3 это библиотека шаблонов.
Если происходят обратно-несовместимые изменения, и мы хотим плавной миграции, то стоит рассмотреть возможность сборки нескольких версий -devel пакетов.

В данном случае не надо городить огород а просто надо исправить всех клиентов

(Ответ для Anton Farygin на комментарий #15)
> просто надо исправить всех клиентов
Не ломая совместимость с p11. Возможно, сперва провести в p11 подготовку.

  Пакет opensnitch-ui:

opensnitch-ui: /usr/lib/python3/site-packages/usr/share
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/applications
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/applications/opensnitch_ui.desktop
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48/apps
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48/apps/opensnitch-ui.png
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64/apps
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64/apps/opensnitch-ui.png
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable/apps
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable/apps/opensnitch-ui.svg
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/kservices5
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/kservices5/kcm_opensnitch.desktop
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/metainfo
opensnitch-ui: /usr/lib/python3/site-packages/usr/share/metainfo/io.github.evilsocket.opensnitch.appdata.xml
opensnitch-ui: /usr/share/applications/opensnitch_ui.desktop
opensnitch-ui: /usr/share/icons/hicolor/48x48/apps/opensnitch-ui.png

  Это так и должно быть? :-)

(Ответ для Andrew Vasilyev на комментарий #17)
>   Это так и должно быть? :-)

Всех своих подопечных я обычно раскалённой кочергой отучиваю от всяких там bindir/* libdir/* и в частности python3_sitelibdir_noarch/*.
Видимо здесь удалось как-то избежать этой проблемы во время обучения=)

У меня у самого на днях пакет при обновлении захотел упаковать python3_sitelibdir/{docs,examples}. Доверяй апстриму, но проверяй!

В связи с неготовностью кандидата к самостоятельной работе передаю его дальше ментору для окончания обучения.

4.2 -> 3.5

(In reply to Andrew Vasilyev from comment #17)
>   Пакет opensnitch-ui:
> 
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/applications
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/applications/opensnitch_ui.desktop
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48/apps
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/48x48/apps/opensnitch-
> ui.png
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64/apps
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/64x64/apps/opensnitch-
> ui.png
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable/apps
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/icons/hicolor/scalable/apps/
> opensnitch-ui.svg
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/kservices5
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/kservices5/kcm_opensnitch.desktop
> opensnitch-ui: /usr/lib/python3/site-packages/usr/share/metainfo
> opensnitch-ui:
> /usr/lib/python3/site-packages/usr/share/metainfo/io.github.evilsocket.
> opensnitch.appdata.xml
> opensnitch-ui: /usr/share/applications/opensnitch_ui.desktop
> opensnitch-ui: /usr/share/icons/hicolor/48x48/apps/opensnitch-ui.png
> 
>   Это так и должно быть? :-)

Создайте пожалуйста отдельную багу.

(In reply to Grigory Ustinov from comment #18)
> (Ответ для Andrew Vasilyev на комментарий #17)
> >   Это так и должно быть? :-)
> 
> Всех своих подопечных я обычно раскалённой кочергой отучиваю от всяких там
> bindir/* libdir/* и в частности python3_sitelibdir_noarch/*.
> Видимо здесь удалось как-то избежать этой проблемы во время обучения=)
> 
> У меня у самого на днях пакет при обновлении захотел упаковать
> python3_sitelibdir/{docs,examples}. Доверяй апстриму, но проверяй!

Нету вашей вины в этом Григорий. Я недоглядел.
Справедливости ради скажу, что эту ошибку не я сделал. Я просто ее не заметил и не исправил. Я поднимал пакет из FTBFS, и так сделали опытные мейнтейнеры до меня. История git тому свидетель.
И в целом, если дошло до даунгрейда, я считаю важным дать обратную связь.
У нас большая проблема с политиками и мануалами  по сборке пакетов. Понятно, что каждый нюанс рассмотреть в Вики очень тяжело, но часто приходится работать почти не с чем. Например, сейчас я собираю веб-приложение, а политика с очень скромным по объему материлом не обновлялась почти 16 лет https://www.altlinux.org/Web_Policy. И с такими ситуациями приходится часто сталкиваться.
Приходится пользоваться вторым вариантом - смотреть чужие спеки, примеры того как делают другие, опытные мейнтейнеры. И плохой пример попадается, конечно, реже, чем хороший, но не настолько реже, чем следовало бы ожидать. Можете провести эксперимент, посмотреть десяток другой пакетов python3-module-*, и несколько штук %python3_module_dir/* вы гарантировано увидете. Может быть даже увидете с первого раза. Лично я увидел это первым, тыкнув в случайный пакет.
И это не только с  python3, это объёмная проблема. Причем бывает, что сам учитель говорит, что так не делай, а в его спеках попадается конструкция, которую использовать нежелательно.
Объединяется это все с тем, что коммуникация затруднена, ведь у учителей есть своя работа и свои пакеты. И приходится учиться из воздуха. Из опыта, на своих ошибках, чужих, или пока как в этом случае опытный мейнтейнер с желанием сообщить о замеченной ошибке не ткнет в нее носом.

Хорошо, что сейчас высокие требования к начинающим мейнтейнерам. Но хочелось бы, чтобы все старшие товарищи в 100% своих пакетов тоже демонстировали высокое качество. Чтобы в общем случае можно было использовать случайный спек из Сизифа в качестве примера.
Также хотелось бы, чтобы старшие товарищи часто документировали в Вики лучшие практики, а не чтобы они передавались из уст в уста.

(Ответ для Ulysses Apokin на комментарий #21)
> И это не только с  python3, это объёмная проблема. Причем бывает, что сам
> учитель говорит, что так не делай, а в его спеках попадается конструкция,
> которую использовать нежелательно.

Если это камень в мой огород, покажите, пожалуйста пальцем, где у меня конструкция, которую использовать нежелательно. Обычно я только приветствую, когда подопечные указывают на такие моменты. Впрочем... Некоторые более опытные мейнтейнеры собирают в десятки раз больше пакетов и уследить иногда действительно бывает проблематично.

Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=)

(In reply to Grigory Ustinov from comment #23)
> (Ответ для Ulysses Apokin на комментарий #21)
> > И это не только с  python3, это объёмная проблема. Причем бывает, что сам
> > учитель говорит, что так не делай, а в его спеках попадается конструкция,
> > которую использовать нежелательно.
> 
> Если это камень в мой огород, покажите, пожалуйста пальцем, где у меня
> конструкция, которую использовать нежелательно. Обычно я только приветствую,
> когда подопечные указывают на такие моменты. Впрочем... Некоторые более
> опытные мейнтейнеры собирают в десятки раз больше пакетов и уследить иногда
> действительно бывает проблематично.
> 
> Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть
> проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=)

Я не про конкретно про вас, Григорий, в конкретно в этой ситуации. Ваши пакеты python действительно образцово-показательные и их можно использовать в качестве примера.
Я не хочу кидаться камнями в кого-либо, тем более придется обращаться к личной переписке с различными участниками. И вы действительно говорили мне, что так делать нельзя.

Но если посмотреть некоторые пакеты других очень опытных мейнтейнеров, которые сопровождают некоторые python-модули, то там встречается эта конструкция.

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

Посмотреть только одну SLibsPolicy, я вижу, что много опытный мейнтейнеров поголовно ее не знают. Я уже столько пакетов насобирал, следуя старой SLibsPolicy которая висела (или еще висит?) в вики, и через столько людей это все прошло и никто ничего не сказал, потому что сами были не в курсе. Соответствие SLibsPolicy зашевелилось только этой осенью, когда Антон в списке расссылки эту тему поднял.

Я уже не говорю про мелкие баги, вроде использования %dir и /dir/*, которому подавляющая часть пакетов не соответствует, макросов в именах пакетов и т.д.

А уж про конструкции вроде %_bindir/* я вообще молчу, которые до сих пор используют даже притчи во языцех.
А должен ли эмулятор терминала предоставлять x-terminal-emulator до сих пор консенсуса нет.

Я не хотел бы, чтобы на меня и других новичков, вешали всех собак. Сами мейнтейнеры тоже должны соответствовать своим же требованиям, чтобы был личный пример и все спеки писались правильно. Одно дело, когда есть ошибка специфическая для пакета, а другое дело, когда написано неправильно. И, конечно, не хватает политик и документации о том, что правильнои допустимо, а что нет. И вы сами понимаете, что очень много разногласий между мейнтейнерами и приходится подстраиваться.
Да и не во всех нюансах конкретные мейнтейнеры хорошо разбираются, документации мало или нет, спеки в Сизифе в общем случае смотреть в качестве примера нельзя. И получается что получается.
Я не про конкретно эту ошибку, которую я и много кто еще пропустил. Мне действительно очень обидно за нее. И теперь наученный горьким опытом, я знаю, что надо всегда полностью проверять, какие файлы попадают в пакет, и не доверять прошлым мейнтейнерам и тем более асптриму. Учитывая, что эта программа ужасна и я поднимая ее из FTFBS сильно намучился вместе с мейнтейнерами  из других дистров, которые пытались ее собрать.

> Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=)

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

(In reply to Ulysses Apokin from comment #25)
> А уж про конструкции вроде %_bindir/* я вообще молчу

А какие вопросы есть к этой конструкции?

(Ответ для Ulysses Apokin на комментарий #25)
> А должен ли эмулятор терминала предоставлять x-terminal-emulator до сих пор
> консенсуса нет.
Как только мантейнеру пакета с отсутствующим провайдом x-terminal-emulator силой напихают другой x-terminal-emulator, кроме его любимого, сразу найдётся. :-)

(In reply to Dmitry V. Levin from comment #27)
> (In reply to Ulysses Apokin from comment #25)
> > А уж про конструкции вроде %_bindir/* я вообще молчу
> 
> А какие вопросы есть к этой конструкции?

Я не хочу отвечать на данный вопрос, потому что очевидно не являюсь авторитетом. Но мне все мейнтейнеры, с которыми я взаимодействовал, сообщали о недопустимости данной конструкции. Обоснованием является то, что легко пропустить какие-либо новые файлы, которые попали в пакет, но не должны были в него попасть или должны были быть перемещены. Мне кажется, что аналогичное произошло и opensnitch.

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

На мой взгляд кандидат готов!

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

T/J/M -> 4.2

Здравствуйте.

Хорошо.

Я сейчас работаю над бекпортированием freecad в Sisyphus.
Андрей Черепанов выдал мне аппрув. Потом были замечания со стороны отдела тестирования, которые я подправил. Сейчас жду ответа от них. И мне после этого еще понадобится аппрув на два позадания в этом же таске.
https://packages.altlinux.org/en/tasks/429329/


Еще я работаю над handy (https://github.com/cjpais/handy) по заданию Андрея Черепанова. Но пока на локалхосте. Там проблема с рассинхроном зависимостей tauit между rust и nodejs. Но я близко, мне кажется к разрешению, поэтому скоро пришлю вам вариант на проверку.

Так же параллельно я обновляю пакеты. На данный момент все обновлено, что можно обновить. Буду вым присылать таски с обновлениями на аппрув по мере их появления.

https://git.altlinux.org/tasks/archive/done/_412/422711/gears/400/git?p=git;a=commitdiff;h=bfde7c729a689b51025926214fa8a9af95737fcb

+# Install man pages
+pushd doc/man
+       for i in *.1 ;
+       do
+               install -Dpm 0644 $i %buildroot%_man1dir/$i
+       done
+popd

Пример оверинженеринга, которого стоит избегать. Если есть возможность написать проще, надо делать проще. Как правило, в спеке циклы не требуется использовать.

Достаточно же:
mkdir -p %buildroot%_man1dir
install -Dpm 0644 doc/man/*.1 %buildroot%_man1dir

https://git.altlinux.org/tasks/archive/done/_409/419708/gears/360/git?p=git;a=commitdiff;h=14c1f08703578a9ac212a7335da2f8282567d109

Тут вы одним коммитом добавили исходники и спек.
Никогда так не делайте. И сразу возникает вопрос: почему не использовали git пакета ранее удалённого из Сизифа пакета?

И тут тоже самое:
https://git.altlinux.org/tasks/archive/done/_409/419708/gears/400/git?p=git;a=commitdiff;h=6cdab965522dee9e393dc3294c9acd1b66a085e8#patch2

А здесь вы сабмодули тем же коммитом добавили:
https://git.altlinux.org/tasks/archive/done/_409/419708/gears/2300/git?p=git;a=commitdiff;h=9cf0082375c92e32c8363b4877c9977ebb603a8b

И вот здесь опять одним коммиты исходники и спек:
https://git.altlinux.org/tasks/archive/done/_409/419119/gears/600/git?p=git;a=commitdiff;h=3aa70d611f98a60d23a59bc319fe8a084e552e91

Это грубые ошибки. Прошу в будущем никогда так не делать.
Строго разделяйте свои коммиты от апстримных.

https://git.altlinux.org/tasks/archive/done/_399/409314/gears/1600/git?p=git;a=commitdiff;h=3d283bfc3dc3e6b0beeb013bf8e3c87a657dc6e3

Какая интересная опечатка:
BuildRequires(Pre): rpm-build-cmake

pre маленькими буквами нужно писать.

Общие замечания по тем пакетам, которые просмотрел:
1. URL и VCS надо писать заглавными, так как это аббревиатуры.
2. В BuildRequires(pre) нужно помещать исключительно пакеты с макросами, которые нужны для сборки srpm.

С одной стороны собрали впечатляющее количество пакетов в том числе и по сложности и набили на них много шишек, с другой - вам вовремя не объясняли, где вы совершаете ошибки. Продолжу смотреть позже.

Я думал, что в первый коммит в репозиторий следует делать сразу со всем. Учту. Буду разделять на несколько.

> BuildRequires(Pre): rpm-build-cmake

Я намеренно делал это, потому что видел пакеты которые делают также.
Хорошо, исправлю в след. обновлениях в своих пакетах.

> В BuildRequires(pre) нужно помещать исключительно пакеты с макросами, которые нужны для сборки srpm.

Да, это выяснил позже опытным путем, но позже. Это обязательно исправлю в след. обновлениях.

> 1. URL и VCS надо писать заглавными, так как это аббревиатуры.

Я смотрел по спекам, что эти аббревиатуры пишут как "Url" и "Vcs" даже чаще, чем  "URL"  и "VCS" в Сизифе. В частности даже в вики есть статьи, в которых используют первый вариант, например, [1]. Поэтому писал так же. Исправлю на более верный вариант, как вы предлагаете. 

Спасибо, что просмотрели работы и указали на недочеты, которые следует исправить.

[1]https://www.altlinux.org/%D0%9E_%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8_%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B8_RPM_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2

(Ответ для ulysses@altlinux.org на комментарий #34)
> [1]https://www.altlinux.org/
> %D0%9E_%D1%81%D1%82%D1%80%D0%B0%D1%82%D0%B5%D0%B3%D0%B8%D0%B8_%D1%81%D0%B1%D0
> %BE%D1%80%D0%BA%D0%B8_RPM_%D0%BF%D0%B0%D0%BA%D0%B5%D1%82%D0%BE%D0%B2

Спасибо, что указали на эту статью. Изобилие ошибок.

(In reply to Антон Мидюков from comment #33)
> https://git.altlinux.org/tasks/archive/done/_412/422711/gears/400/git?p=git;
> a=commitdiff;h=bfde7c729a689b51025926214fa8a9af95737fcb
> 
> +# Install man pages
> +pushd doc/man
> +       for i in *.1 ;
> +       do
> +               install -Dpm 0644 $i %buildroot%_man1dir/$i
> +       done
> +popd
> 
> Пример оверинженеринга, которого стоит избегать. Если есть возможность
> написать проще, надо делать проще. Как правило, в спеке циклы не требуется
> использовать.
> 
> Достаточно же:
> mkdir -p %buildroot%_man1dir
> install -Dpm 0644 doc/man/*.1 %buildroot%_man1dir

-D     create all leading components of DEST except the last, or all components of --target-directory, then copy SOURCE to DEST

Возникает закономерный вопрос: зачем в предлагаемом альтернативном варианте -D ?

(Ответ для Dmitry V. Levin на комментарий #36)
> (In reply to Антон Мидюков from comment #33)
> > https://git.altlinux.org/tasks/archive/done/_412/422711/gears/400/git?p=git;
> > a=commitdiff;h=bfde7c729a689b51025926214fa8a9af95737fcb
> > 
> > +# Install man pages
> > +pushd doc/man
> > +       for i in *.1 ;
> > +       do
> > +               install -Dpm 0644 $i %buildroot%_man1dir/$i
> > +       done
> > +popd
> > 
> > Пример оверинженеринга, которого стоит избегать. Если есть возможность
> > написать проще, надо делать проще. Как правило, в спеке циклы не требуется
> > использовать.
> > 
> > Достаточно же:
> > mkdir -p %buildroot%_man1dir
> > install -Dpm 0644 doc/man/*.1 %buildroot%_man1dir
> 
> -D     create all leading components of DEST except the last, or all
> components of --target-directory, then copy SOURCE to DEST
> 
> Возникает закономерный вопрос: зачем в предлагаемом альтернативном варианте
> -D ?

Ошибка. -D не нужно. Поспешил.

https://packages.altlinux.org/ru/sisyphus/srpms/sakura/specfiles/

1. License не в SPDX формате
2. Packager указывать не нужно.
3. Вместо
BuildRequires: ImageMagick
нужно
BuildRequires: ImageMagick-tools

ImageMagick слишком жирно.

4. Не стоит указывать расширение явно, замените на *:
%_man1dir/%name.1.xz

5. URL - это аббревиатура, не хватает VCS.

https://packages.altlinux.org/ru/sisyphus/srpms/opensnitch/specfiles/

Почему используете макрос %make, а не %make_build?

(In reply to Антон Мидюков from comment #39)
> https://packages.altlinux.org/ru/sisyphus/srpms/opensnitch/specfiles/
> 
> Почему используете макрос %make, а не %make_build?

Там были проблеми со сборкой с несолькими заданиями. И в целом с makefile. Посмотрю при следующем обновлении, что можно сделать. В любом случае, это не сильно тормозит сборку. Потому что в makefile только ui на python и небольшая ebpf программа. Основная часть собирается отдельно c помощью %golang_build.

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