Created attachment 17039 [details] Публичная часть GPG-ключа Псевдоним: ulysses Электронная почта: Ulysses Apokin <ulysses@altlinux.org> Адрес пересылки почты: aoipkn@yandex.ru Имя ментора: Григорий Устинов Почта ментора: <grenka@altlinux.org>. Трудоустройство в ООО "Базальт СПО" на испытательный срок.
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 не нужно. Поспешил.
