51793 2024-10-22 14:48:37 +0300 [5.0] join ulysses@ 2026-09-04 13:40:00 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux ASSIGNED P5 normal --- 1 aoipkn glebfm andy antohami glebfm grenka ldv rider ulysses zerg cas oldest_to_newest 253304 0 17039 aoipkn 2024-10-22 14:48:37 +0300 Created attachment 17039 Публичная часть GPG-ключа Псевдоним: ulysses Электронная почта: Ulysses Apokin <ulysses@altlinux.org> Адрес пересылки почты: aoipkn@yandex.ru Имя ментора: Григорий Устинов Почта ментора: <grenka@altlinux.org>. Трудоустройство в ООО "Базальт СПО" на испытательный срок. 253305 1 17040 aoipkn 2024-10-22 14:50:24 +0300 Created attachment 17040 Публичная часть SSH-ключа 253315 2 grenka 2024-10-22 16:04:58 +0300 Менторство подтверждаю. 254288 3 grenka 2024-11-12 12:02:16 +0300 Прошу выдать гитовницу! 254335 4 glebfm 2024-11-12 20:57:14 +0300 Ментор есть, ключи в порядке. 254345 5 glebfm 2024-11-12 21:18:06 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 255745 6 grenka 2024-12-09 17:43:00 +0300 Прошу выдать доступ к сборочнице. 255766 7 glebfm 2024-12-09 22:20:25 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. Адрес подписан на devel@. T/J/S -> 3.6. 262073 8 grenka 2025-03-28 20:19:32 +0300 Кандидат собрал очень большое количество пакетов и мне кажется, что уловил основные тенденции сборки по альт. Рекомендую его для дальнейших проверок рецензентам. 270459 9 glebfm 2025-08-05 16:20:35 +0300 Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 270578 10 rider 2025-08-07 12:00:16 +0300 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 прослеживается везде). Присылайте новые задания на ревью уже мне (можно в телеграм). 271517 11 aoipkn 2025-08-28 09:52:29 +0300 Антон, отправлял вам таски на почту. Сегодня продублировал письма. 271518 12 rider 2025-08-28 10:11:04 +0300 (In reply to Ulysses Apokin from comment #11) > Антон, отправлял вам таски на почту. > Сегодня продублировал письма. Ответил по почте, спасибо. 278347 13 zerg 2025-12-03 13:36:11 +0300 https://git.altlinux.org/tasks/401479/gears/500/git?p=git;a=commitdiff;h=549b25ffb89e3fd6ee71af280a52834224338048 %{name}_%soversion-devel -- это черезчур. 278348 14 aoipkn 2025-12-03 13:38:05 +0300 Обсуждение происходит в https://bugzilla.altlinux.org/56619 Eigen3 это библиотека шаблонов. Если происходят обратно-несовместимые изменения, и мы хотим плавной миграции, то стоит рассмотреть возможность сборки нескольких версий -devel пакетов. 278374 15 rider 2025-12-03 16:14:28 +0300 В данном случае не надо городить огород а просто надо исправить всех клиентов 278376 16 zerg 2025-12-03 16:19:00 +0300 (Ответ для Anton Farygin на комментарий #15) > просто надо исправить всех клиентов Не ломая совместимость с p11. Возможно, сперва провести в p11 подготовку. 280636 17 andy 2026-01-21 19:54:51 +0300 Пакет 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 Это так и должно быть? :-) 280641 18 grenka 2026-01-22 01:50:47 +0300 (Ответ для Andrew Vasilyev на комментарий #17) > Это так и должно быть? :-) Всех своих подопечных я обычно раскалённой кочергой отучиваю от всяких там bindir/* libdir/* и в частности python3_sitelibdir_noarch/*. Видимо здесь удалось как-то избежать этой проблемы во время обучения=) У меня у самого на днях пакет при обновлении захотел упаковать python3_sitelibdir/{docs,examples}. Доверяй апстриму, но проверяй! 280646 19 rider 2026-01-22 07:22:50 +0300 В связи с неготовностью кандидата к самостоятельной работе передаю его дальше ментору для окончания обучения. 4.2 -> 3.5 280649 20 aoipkn 2026-01-22 07:44:10 +0300 (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 > > Это так и должно быть? :-) Создайте пожалуйста отдельную багу. 280651 21 aoipkn 2026-01-22 08:03:05 +0300 (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, это объёмная проблема. Причем бывает, что сам учитель говорит, что так не делай, а в его спеках попадается конструкция, которую использовать нежелательно. Объединяется это все с тем, что коммуникация затруднена, ведь у учителей есть своя работа и свои пакеты. И приходится учиться из воздуха. Из опыта, на своих ошибках, чужих, или пока как в этом случае опытный мейнтейнер с желанием сообщить о замеченной ошибке не ткнет в нее носом. 280652 22 aoipkn 2026-01-22 08:14:46 +0300 Хорошо, что сейчас высокие требования к начинающим мейнтейнерам. Но хочелось бы, чтобы все старшие товарищи в 100% своих пакетов тоже демонстировали высокое качество. Чтобы в общем случае можно было использовать случайный спек из Сизифа в качестве примера. Также хотелось бы, чтобы старшие товарищи часто документировали в Вики лучшие практики, а не чтобы они передавались из уст в уста. 280655 23 grenka 2026-01-22 09:13:19 +0300 (Ответ для Ulysses Apokin на комментарий #21) > И это не только с python3, это объёмная проблема. Причем бывает, что сам > учитель говорит, что так не делай, а в его спеках попадается конструкция, > которую использовать нежелательно. Если это камень в мой огород, покажите, пожалуйста пальцем, где у меня конструкция, которую использовать нежелательно. Обычно я только приветствую, когда подопечные указывают на такие моменты. Впрочем... Некоторые более опытные мейнтейнеры собирают в десятки раз больше пакетов и уследить иногда действительно бывает проблематично. Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=) 280657 24 aoipkn 2026-01-22 09:32:02 +0300 (In reply to Grigory Ustinov from comment #23) > (Ответ для Ulysses Apokin на комментарий #21) > > И это не только с python3, это объёмная проблема. Причем бывает, что сам > > учитель говорит, что так не делай, а в его спеках попадается конструкция, > > которую использовать нежелательно. > > Если это камень в мой огород, покажите, пожалуйста пальцем, где у меня > конструкция, которую использовать нежелательно. Обычно я только приветствую, > когда подопечные указывают на такие моменты. Впрочем... Некоторые более > опытные мейнтейнеры собирают в десятки раз больше пакетов и уследить иногда > действительно бывает проблематично. > > Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть > проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=) Я не про конкретно про вас, Григорий, в конкретно в этой ситуации. Ваши пакеты python действительно образцово-показательные и их можно использовать в качестве примера. Я не хочу кидаться камнями в кого-либо, тем более придется обращаться к личной переписке с различными участниками. И вы действительно говорили мне, что так делать нельзя. Но если посмотреть некоторые пакеты других очень опытных мейнтейнеров, которые сопровождают некоторые python-модули, то там встречается эта конструкция. Да и не суть в этой конкретной конструкции, явной ошибке, которую я не заметил, два моих аппрувера для этого пакета и еще пять человек, контрибьютивших в этот пакет. Посмотреть только одну SLibsPolicy, я вижу, что много опытный мейнтейнеров поголовно ее не знают. Я уже столько пакетов насобирал, следуя старой SLibsPolicy которая висела (или еще висит?) в вики, и через столько людей это все прошло и никто ничего не сказал, потому что сами были не в курсе. Соответствие SLibsPolicy зашевелилось только этой осенью, когда Антон в списке расссылки эту тему поднял. Я уже не говорю про мелкие баги, вроде использования %dir и /dir/*, которому подавляющая часть пакетов не соответствует, макросов в именах пакетов и т.д. 280659 25 aoipkn 2026-01-22 09:47:25 +0300 А уж про конструкции вроде %_bindir/* я вообще молчу, которые до сих пор используют даже притчи во языцех. А должен ли эмулятор терминала предоставлять x-terminal-emulator до сих пор консенсуса нет. Я не хотел бы, чтобы на меня и других новичков, вешали всех собак. Сами мейнтейнеры тоже должны соответствовать своим же требованиям, чтобы был личный пример и все спеки писались правильно. Одно дело, когда есть ошибка специфическая для пакета, а другое дело, когда написано неправильно. И, конечно, не хватает политик и документации о том, что правильнои допустимо, а что нет. И вы сами понимаете, что очень много разногласий между мейнтейнерами и приходится подстраиваться. Да и не во всех нюансах конкретные мейнтейнеры хорошо разбираются, документации мало или нет, спеки в Сизифе в общем случае смотреть в качестве примера нельзя. И получается что получается. Я не про конкретно эту ошибку, которую я и много кто еще пропустил. Мне действительно очень обидно за нее. И теперь наученный горьким опытом, я знаю, что надо всегда полностью проверять, какие файлы попадают в пакет, и не доверять прошлым мейнтейнерам и тем более асптриму. Учитывая, что эта программа ужасна и я поднимая ее из FTFBS сильно намучился вместе с мейнтейнерами из других дистров, которые пытались ее собрать. 280661 26 aoipkn 2026-01-22 10:18:39 +0300 > Считаю, что заводить новую багу насчёт opensnitch не нужно, можно закрыть проблему в рамках этой. У нас тут не бюрократия, все собрались по делу=) Я считаю, это важным. Это исключает путаницу. Я встречался с ситуациями, когда выполняешь работу, и выясняется, что сделал не то, потому что другое имелось ввиду и т.д. или что-то потерялось где-то в сообщениях. Тогда заведу сам. 280685 27 ldv 2026-01-22 13:36:45 +0300 (In reply to Ulysses Apokin from comment #25) > А уж про конструкции вроде %_bindir/* я вообще молчу А какие вопросы есть к этой конструкции? 280690 28 zerg 2026-01-22 13:56:05 +0300 (Ответ для Ulysses Apokin на комментарий #25) > А должен ли эмулятор терминала предоставлять x-terminal-emulator до сих пор > консенсуса нет. Как только мантейнеру пакета с отсутствующим провайдом x-terminal-emulator силой напихают другой x-terminal-emulator, кроме его любимого, сразу найдётся. :-) 280694 29 aoipkn 2026-01-22 14:02:06 +0300 (In reply to Dmitry V. Levin from comment #27) > (In reply to Ulysses Apokin from comment #25) > > А уж про конструкции вроде %_bindir/* я вообще молчу > > А какие вопросы есть к этой конструкции? Я не хочу отвечать на данный вопрос, потому что очевидно не являюсь авторитетом. Но мне все мейнтейнеры, с которыми я взаимодействовал, сообщали о недопустимости данной конструкции. Обоснованием является то, что легко пропустить какие-либо новые файлы, которые попали в пакет, но не должны были в него попасть или должны были быть перемещены. Мне кажется, что аналогичное произошло и opensnitch. Я бы обратил внимание, что по таким базовым вопросам нету документации и общепринятого решения. Для меня это неожиданно. 282313 30 grenka 2026-02-19 20:14:51 +0300 На мой взгляд кандидат готов! 293092 31 antohami 2026-08-23 19:04:36 +0300 Здравствуйте. Я ваш рецензент. Посмотрю то, что вы уже собрали, выскажу замечания. Для всех тасков за аппрувом обращайтесь теперь ко мне, а не к ментору. Со мной можно связаться по почте или в матрикс. T/J/M -> 4.2 293097 32 ulysses 2026-08-24 09:38:40 +0300 Здравствуйте. Хорошо. Я сейчас работаю над бекпортированием freecad в Sisyphus. Андрей Черепанов выдал мне аппрув. Потом были замечания со стороны отдела тестирования, которые я подправил. Сейчас жду ответа от них. И мне после этого еще понадобится аппрув на два позадания в этом же таске. https://packages.altlinux.org/en/tasks/429329/ Еще я работаю над handy (https://github.com/cjpais/handy) по заданию Андрея Черепанова. Но пока на локалхосте. Там проблема с рассинхроном зависимостей tauit между rust и nodejs. Но я близко, мне кажется к разрешению, поэтому скоро пришлю вам вариант на проверку. Так же параллельно я обновляю пакеты. На данный момент все обновлено, что можно обновить. Буду вым присылать таски с обновлениями на аппрув по мере их появления. 293101 33 antohami 2026-08-24 09:41:57 +0300 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. С одной стороны собрали впечатляющее количество пакетов в том числе и по сложности и набили на них много шишек, с другой - вам вовремя не объясняли, где вы совершаете ошибки. Продолжу смотреть позже. 293103 34 ulysses 2026-08-24 10:01:03 +0300 Я думал, что в первый коммит в репозиторий следует делать сразу со всем. Учту. Буду разделять на несколько. > 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 293104 35 antohami 2026-08-24 10:10:18 +0300 (Ответ для 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 Спасибо, что указали на эту статью. Изобилие ошибок. 293154 36 ldv 2026-08-25 13:48:29 +0300 (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 ? 293155 37 antohami 2026-08-25 13:55:46 +0300 (Ответ для 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 не нужно. Поспешил. 293658 38 antohami 2026-08-31 07:36:40 +0300 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. 293659 39 antohami 2026-08-31 07:39:00 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/opensnitch/specfiles/ Почему используете макрос %make, а не %make_build? 293698 40 ulysses 2026-08-31 12:21:34 +0300 (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. 295434 41 antohami 2026-09-04 13:40:00 +0300 Ревью закончил. Считаю, что кандидат готов к самостоятельной сборке пакетов. 17039 2024-10-22 14:48:37 +0300 2024-10-22 14:48:37 +0300 Публичная часть GPG-ключа public.gpg application/pgp-keys 3078 aoipkn LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdjWGlxd0JFQUN3c3pm Q0xreVdXV3VNM3ZXZ1NlZXlkMGlPRDVSbUx5NE1ZbXpqc1RoRHkySGpNd3N4ClI0eHBTTlFpVmV2 bUpZbFpnV0oxa3htWi81OHluZ0NEMjFHanM3VXYrbXVxNCsvR2k3UEZnR3hXc1VVY3huNVkKb1Np UittTHlZdjNlQnc0UXZsM3ErUnp2WXZIeWdtRlpDZUtkVWx1YjZUZlN5RHV3ZTU1a3MybXRqS3Bo WlJnTgpSQjdpb0JFT0JrSVcrbVNtWllhdlkwUHRWYWsyY3BVKzZQQUU1MUJMQjN6QVJ1WlQzNlJN RGk0VGhaOUFhekFMCkdKbnFmWHhuMnlEbW5lUkUzT3I5WXZiY0wrMk1MN3JpTzR1RWtDVExGLzBK NlRRVkFsNm41T09EdldPaWdQZkgKRUYxWE1XVVFYTzJGSFlWcTFqUm5RMHl1Qnd3U0JUTkwySmJX c3Z6YkNoVjFwZnBvNHFDckFWMlZGSXhPWVlhTgpUSlluckx6WTJyOVNtYUo2c2NtcllPRTZKd0Rp MEpZaVNML0hTQnlacmZGQkVxU1dlRGZCQVdPb1FwZ0FaMlplCjF0SnNXVTUvL091VW5mQklBQmx5 WUdQSlU4b3dCb1BCa2RuMTZaaXI1aFBSWFh0bU5FTkh1VjlRK0dJb2QyWGgKdXJRVkNkMzRrUGQ4 SFJBUXlrRnprYjc1dG0zcTZSTlJVOUh3UTlFREU3bW8yL1ZkTjROamZ4YkFEajROSTJSNApMelQz eDdNYmYrbWdoQUljbGRsd1ZHQzRmUGQxNmhuY3VxYTJVNmlMTU1RNFJWY1BhbWhpTERIbzU2dSs3 clFFCmEvM0FUV2tQUjZ3S1BTQ2xxVWpaQVZXZUsrb0VNV1hGQkJ3UDBVZVkzOXkxRWZSOFpBbkky N0Z4YXdBUkFRQUIKdENWVmJIbHpjMlZ6SUVGd2IydHBiaUE4ZFd4NWMzTmxjMEJoYkhSc2FXNTFl QzV2Y21jK2lRSTRCQk1CQ0FBaQpCUUpuRjRxc0Foc0RCZ3NKQ0FjREFnWVZDQUlKQ2dzRUZnSURB UUllQVFJWGdBQUtDUkJvMFZCVHlnZGJrOVRjCkVBQ1FtQnpoZVZWemJEQmx1ZlY0WlR2QlJpYTNi OUdBeU1xcVR4eTVyeVoySGRJUnFVZTU4S3M5Vko1b2N4VG4KWGt0bU9XOWVnSGdPVDVDSWlXRnEv VkRMSENWL055b0QxQ1d1Z2dLc21KSGJ3bXFIMHh1MTE0ZW5NSDBZcG9qMQovcWJKRThJWkQ1eEkz YXA2dVVaZmxnRmY5bUJDM2dyV3RENUhiZHhpMVhQNVZPU2llMk93VXNQY29FYW41Rk1OCnRRbDF6 RDM2SGhIM3dzTkRjK2ZSbUFXcEJrY3dQRUExVFlOOVNZRzFzNWt0REpaK2I5YkZuY3Z2Um5EV3do eXgKQzNVTmdlWUpiTUsyY1dmTDc3dFZwQzdiVStYeHUzUU1pMHoxNTROSHBVV0taUmZDT3ovTHhM QTd4bDNxZHgycwpQaGNLUmdzN0g0alJpbGJpUlFrOFBObWkzQldKalhyaC83bzhDWFg5UG12L2lU a2U5UVBVdjBzbjNrK0psaStOCjJ6OEJITWRrTjZEWkxjUmN1VTQ0d1hyYm5ENENHblkxaTVVdmJJ QllPTTVyTkJOdUIrOE9vYWYzRzNJejZNYnYKWVBOU2NtSEtFaWFyMDhYb0pwYzA0ZHd3NGxxckcv NExTVFd0U1ZMYjBpdmdxR3NQRkdzc2xVRWNLK1VLUVkxUApocFpOUGpMS0hLZDZtWDBZcXRGZXI3 R0ZpQUdZN1U5WDlCNFRxZFZVR0FLSDhHQzZ1c2pGejIyWEdYZitydFlpClNyTHR3UmR1S3BZcWM4 aCtkeG5GOTVCVUlVWDN1YzNSYXRSUU1TVEsrRVFpdDdMbzZoY09CbTJUMG9Kci8wemYKcVNidHdV alllM1JNQ3E5cFJmUmxORlhOSFZ3UXQ3ZlcvMVZPOVZySERFQmN3TGtDRFFSbkY0cXNBUkFBMCtK YQp5WGx1WmJhWTduNFMwUWlZbmJablNmbU51SFE4UmpucmNRTUlCekZBOWVITEE2cHczSGlVVzRX NGJlMVAxNlB0CjRDcDh6cHlBSWtLMC9WaElvWFl3My9FKzVxSVNBNTRFT1gyVUx0MUhIdWZ3eVVW N1BzYVBkYVFPM05UamtmZDkKMGhCOFlUNHpRV2NnQUlQWTZYU3RtZWsvUFlsSjNtOFBnTHJ0MXFF dFI2bGtNbk1ydkZUWVFJSnIwTlROT05oZQpFZU5mMVU5eGNlU2xBWlFYNjBBOFRSMjBEenlqWU5I Y21BaHZJeDljUy9pbDdvS3hxTzE2TlNwelA3eE5tZFV5CndPSVhKNjFuWUZEVHhBL041Y1V0MHNQ WDJHaXg3OUU5UWRYcWdoL1liNnh6YnZnWVlwZmwxMld3bUxmM3NjbXEKYVUzZTRSRzBZUWF4TnhI SmVTTXByZGRWUkxnTjNla21vQWU1VEplU1EvamJDWXc3YnJURVBDekEraXhCWW03NApjdVp6N1Ix eEdEc2Exa2tUQlZaOUp1TDBxR1F3NjZMQlhiYUwwKzZXR1IyOW5jSWFsT0dqOHZ2d29OQndkd1Mz CmNqZ0o0ZFYyR3p2bHd0UUE4N0NaQjVuL3l3cDVKTEk1Q1Z3ZUI0ZzA1UUE5T1Q4WWZWb2tRaUNC bFVJTjNvejEKMmRzNWVhazcxWDlIczdDdTF4VkRkY2Q4N1g2U2dFL3lNcFFCMk44eVRpSE5HMktX WEJkZzZ0ODQ4YVU3VFhaRgpwcHM3dklsYzNIRlpkWE5jUDdVRERLUVFGOVltVEZJVjU1ZjRxQlBX VVlSTTJUT2Nib3JKM3Z5MTNDamJvNDE5ClNtTDJSUWhQZGxKanhXa1lCVW94aHNacnhDV05adTAz d0NZazR0TUFFUUVBQVlrQ0h3UVlBUWdBQ1FVQ1p4ZUsKckFJYkRBQUtDUkJvMFZCVHlnZGJrL1Zv RC85U1kvaDZpR1BCc3VDS29DN0c2dlJqalVWaFNUZnFETEdiemZQLwpXZ0diNGtOeEU3OHFyaDQ3 d2RqZFdrQ251aXYyeG5xMm1kQk9Pc3FkMVVIL2tVck9MazBPb1krTVF2Z3NZTjZlCkJ1TUlraEo2 N2hoSEJZYlRIeWpPMi9MYUdhVlk5Wkl4eDhhekxTeWdBZjNOQ0JLQktQR0RNY1Ruc2VzanRYbUoK RGRVaFZlRS91RWJyZ1FSYkNKTnp5YkVDM3pMWHc2alVRTCt0QUJjYW5Nby9YbFFjd3AzVEEvZnA3 c3Y4QURaTApVa2c5NUVoSTFxaXphVjhOK21ZUU11REloS2NWb1U3K0hsa3hSU0dIczVaWE5RaEpH V1drZHYzNEtxdGZqdURBCnVqeWZjN0d2R0dFMS84R202ck9NTzB2MUxaN0lDalNraTV6c1NaMXQ0 Q3V5anZSL09BUE14Y3RjYUJJZEo0YVcKeFd1Z2lFdWRQSzA4VUNITiticzVJYitvNXhrekM2czkv RzZNV3prU01tNzBOME9oYlJvcWljUHowdE4xMGFKegpONTlVM3RpZFBJQnhyNmZTdW53by80NC82 eDlxMjhucUdpZXFOYmJEckRKclpEQk5XV2pXYUM4SVlLSnFWZlR6CjlrODQ2Z1hFdktPUWxYdDZ1 bFk3UVZpdStEbGJMbUZNM1F5aW1HVVJ6b1czTjNhN1I4MVNBeTFXbTFMMkNhTmkKY3BESnFCYUJM QW4zSEhxMGJPeE1FZlJlclpmaC9uek83Q2ZlNUJaL1dReGJIY210TmRFQXdyc1dnSThseUhMMgp3 THdUemtOdTRWNG5oQ2NQZTR1UU8xNEF0MkswUGJkazI4NXh3ZzdwdkV6a2NYSEd1SEhGM2RxaldE cW1KY2YvCkk2NUp5QT09Cj1MYUtTCi0tLS0tRU5EIFBHUCBQVUJMSUMgS0VZIEJMT0NLLS0tLS0K 17040 2024-10-22 14:50:24 +0300 2024-10-22 14:50:24 +0300 Публичная часть SSH-ключа id_ed25519.pub application/vnd.ms-publisher 95 aoipkn c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUlUTU9JYW1GcWt1c04zaDF5S0xB SE1ZamROTGdiOFY5R0w4dHdVZTgyRmcgdWx5c3Nlc0BhbHRocAo=