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. Я бы обратил внимание, что по таким базовым вопросам нету документации и общепринятого решения. Для меня это неожиданно.
На мой взгляд кандидат готов!
