Created attachment 11986 [details] ssh pub nickname: toni email: smith.toni91@mail.ru mentor: Grigory Ustinov <grenka@basealt.ru> сопровождение пакетов
Created attachment 11987 [details] gpg pub
Менторство подтверждаю.
Выдайте, пожалуйста, кандидату гитовницу.
(In reply to smith.toni91 from comment #0) > Created attachment 11986 [details] > ssh pub Ok. (In reply to smith.toni91 from comment #1) > Created attachment 11987 [details] > gpg pub uid ключа должен быть в формате <First name> <Last name>.
Created attachment 12067 [details] gpg.pub fix gpg
(In reply to smith.toni91 from comment #5) > Created attachment 12067 [details] > gpg.pub Ok.
Нужна гитовница.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
Кандидат готов спотыкаться о сборочницу!
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
[#312009] DONE (try 2) python3-module-traitsui.git=7.4.2-alt1 ... [#312052] DONE (try 2) codelite.git=16.7.0-alt1 [#312618] DONE (try 2) python3-module-plaster.git=1.1.2-alt1 [#312691] DONE (try 2) shutter.git=0.99.2-alt1 [#312827] TESTED python3-module-blinker.git=1.5-alt1 Всего за месяц кандидат смог обновить пакет так, что мне уже не к чему придраться. Кроме того, показал что ему по силам обновлять и сложные проекты типа codelite с мерджем двух сабмодулей в основное дерево или shutter, где кандидату представилась возможность пообщаться с viy@ относительно сборки дополнительного перлового пакета.
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
У codelite очень странная схема сборки submodules, я хотел бы услышать о ней подробности или какое-то описание.
В альте есть тэг VCS для обозначения URL'ов на git репозиторий. https://git.altlinux.org/tasks/archive/done/_305/312691/gears/100/git?p=git;a=blob;f=shutter.spec;h=d98189f384ecef7dac046617428e84b434a0ba3e;hb=7bd5e6b58009abe368a420587cb42365f86194ca#l20
замечание про тэг VCS касается и других проектов.
Кандидат отлично разобрался с обновлением python пакетов, но есть вопросы к submodules (см. выше) и хотелось бы увидеть самостоятельное написание specfile и работу с shared libs policy.
(Ответ для Anton Farygin на комментарий #13) > У codelite очень странная схема сборки submodules, я хотел бы услышать о ней > подробности или какое-то описание. Эмм.. Обычная схема. Кандидат довольно точно повторил то, как я сам собираю проекты с submodules. Если есть какая-то другая схема, я хотел бы увидеть её реализацию. Тэгом VCS обладают всего 335 пакетов. Считаю его местным обнинским диалектом. Я сегодня первый раз узнал о его существовании. Самостоятельное написание спекфайлов было. toni@, видимо вам всё-таки придётся собрать что-нибудь из первых тех пакетов "которые никому не нужны"=) В качестве работы над shared libs policy могу предложить кандидату задачу https://bugzilla.altlinux.org/42388
Григорий, в целом я хотел бы по вопросам вступления общаться с кандидатом, а не с ментором. При чём тут Обнинск ? Тэг VCS добавлен уже достаточно давно, не надо считать его чьим-то диалектом, просто используйте его для указания git. Я и сам о его существовании узнал всего несколько лет назад. Тэг используется, в частности, watch для поиска обновлений пакетов. Что касается submodules - речь и не идёт о выборе схемы, мне для понимания сделанного нужно описание схемы. Если же хочется посмотреть на то, как submodules обрабатывается в других проектах, то можно посмотреть на zoneminder для примера.
mpdecimal отличный пример ошибки сборки пакета, но проблема в том, что исправить эту ошибку будет крайне сложно, т.к. от пакета mpdecimal зависит python3; https://packages.altlinux.org/ru/sisyphus/srpms/mpdecimal/what_depends/by_binary Но можно попробовать.
Точнее говоря там проблема даже в другом: https://packages.altlinux.org/ru/sisyphus/deps/libmpdec.so.3%2528%2529%252864bit%2529/require У вас libmpdec.so.3 будет переезжать из одного пакета в другой, а apt такие перемещения переносит крайне плохо.
(In reply to Anton Farygin from comment #20) > У вас libmpdec.so.3 будет переезжать из одного пакета в другой, а apt такие > перемещения переносит крайне плохо. Я думаю, что в случае одного клиента у библиотеки это не должно проявиться.
Пока не попробуем - не узнаем.
(Ответ для Anton Farygin на комментарий #18) > Григорий, в целом я хотел бы по вопросам вступления общаться с кандидатом, а > не с ментором. Я не возражаю, у меня были личные вопросы, я их задал. > Если же хочется посмотреть на то, как submodules обрабатывается в других > проектах, то можно посмотреть на zoneminder для примера. Очень интересная реализация, вполне имеющая право на существование. В плане поддержки она наверное даже проще приведённой, но менее очевидная. Хотя для случаев, где сабмодулей достаточно много, пожалуй это единственный вариант.
(In reply to Anton Farygin from comment #16) > Кандидат отлично разобрался с обновлением python пакетов, но есть вопросы к > submodules (см. выше) и хотелось бы увидеть самостоятельное написание > specfile и работу с shared libs policy. Собрал вот такой пакет [#313132] EPERM tmate.git=2.4.0-alt1
Поле Packager лучше убрать, оно заполнится автоматически по тому, кто собирает. В changelog запись не new version, а first build for ALT (или что-то подобное) - старых версий пакета не было. И если сборка делается первый раз, то можно сразу сделать хорошо, без первого коммита с кривым спеком.
(In reply to Anton Farygin from comment #25) > Поле Packager лучше убрать, оно заполнится автоматически по тому, кто > собирает. > В changelog запись не new version, а first build for ALT (или что-то > подобное) - старых версий пакета не было. > > И если сборка делается первый раз, то можно сразу сделать хорошо, без > первого коммита с кривым спеком. Попробовал вот так. [#313165] EPERM tmate.git=2.4.0-alt1
это второе задание зачем ? удалите подзадание в 313132 и добавьте туда изменённый репозиторий. Для удобства работы не надо менять номер задания при внесении изменений в пакет, пока он не стал DONE. https://packages.altlinux.org/ru/tasks/search/?search=toni&task_owner=toni все неиспользуемые задания надо удалять, это хлам.
Another try [#313132] EPERM (try 2) tmate.git=2.4.0-alt1
[00:00:09] Executing(%check): /bin/sh -e /usr/src/tmp/rpm-tmp.43203 [00:00:09] + umask 022 [00:00:09] + /bin/mkdir -p /usr/src/RPM/BUILD [00:00:09] + cd /usr/src/RPM/BUILD [00:00:09] + cd tmate-2.4.0 [00:00:09] + make -j32 check [00:00:09] make: Nothing to be done for 'check'. [00:00:09] + exit 0
Пример работы с shared libs policy. [#313559] TESTED (try 13) blosc2.git=2.6.1-alt1
(Ответ для smith.toni91 на комментарий #30) > Пример работы с shared libs policy. > [#313559] TESTED (try 13) blosc2.git=2.6.1-alt1 неудачный пример - тут нестандартная ситуация, в которой апстрим сам решил назвать проект в соответствии с soname.
На самом деле это скорее вопрос к policy - что делать в таком случае. Ведь у библиотеки blocks2 apiversion может стать 3 и в этом случае приведённый пример не соответствует shared libs policy.
(In reply to Anton Farygin from comment #22) > Пока не попробуем - не узнаем. рассплитить пакет mpdecimal не представляется возможным. Испробовал различные подходы. Поскольку libmpdec.so.3 является симлинком на libmpdec.so.2.5.1 происходит конфликт с уже установленным пакетом.
Как-то странно вы делаете сплит. посмотрите примеры в других пакетах, где пакуется lib%name.so.%soversion.*
(In reply to smith.toni91 from comment #33) > (In reply to Anton Farygin from comment #22) > > Пока не попробуем - не узнаем. > > рассплитить пакет mpdecimal не представляется возможным. > Испробовал различные подходы. Поскольку libmpdec.so.3 является симлинком на > libmpdec.so.2.5.1 происходит конфликт с уже установленным пакетом. Сделайте 2 новых подпакета: %files -n libmpdec3 %_libdir/libmpdec.so.3 %_libdir/libmpdec.so.%version %doc LICENSE.txt %files -n libmpdecxx3 %_libdir/libmpdec++.so.3 %_libdir/libmpdec++.so.%version %doc LICENSE.txt Оставьте в основном пакете только зависимости на эти 2 новых подпакета. Обновите зависимости в devel-подпакете. Со временем, скажем, после p11, старый подпакет-пустышку можно будет упразднить.
Только не забудьте запаковать этот подпакет с зависимостями без файлов, иначе сплит не сработает так, как задумано.
спасибо за разъяснение, получилось [#313369] DONE (try 16) mpdecimal.git=2.5.1-alt2
Быстро очень аппрувите, слишком быстро. abiversion лучше вынести в отдельный define и использовать его везде, где есть цифра 3
(Ответ для Anton Farygin на комментарий #38) > Быстро очень аппрувите, слишком быстро. > abiversion лучше вынести в отдельный define и использовать его везде, где > есть цифра 3 Антон, это рефакторинг ради рефакторинга. При следующем изменении аби я так и сделаю. Если честно, мне есть чем заняться, кроме того как мучать подопечного такими пустяками. У меня полно кандидатов, которые не могут разобраться со сборкой из тэга. Придираться к мелочам можно бесконечно. А я замечу, что это было как никак NMU и в рамках такого обновления не принято осуществлять масштабные изменения с рефакторингом кода. Я кстати даже уже объяснял этот момент одному вашему коллеге, который взял и перехакал весь мой пакет согласно своим представлениям о прекрасном=)) Если хочется погонять кандидата, погоняй по делу. Можно же дофига всего интересного придумать, типа пакет с секциями типа preun postun или чтобы был с кумулятивным патчем:)
(Ответ для Anton Farygin на комментарий #38) > Быстро очень аппрувите, слишком быстро. > abiversion лучше вынести в отдельный define и использовать его везде, где > есть цифра 3 В конце концов, если так уж необходимо вынести этот дефайн, можно сделать это отдельным таском. Я зааппрувил таск, который закрывал багу, мне было важно это. Если хочешь следующие аппрувы будут на тебе?
$ rpmquery --qf 'Name: %{name}\nSummary: %{summary}\n%{description}\n\n' -p mpdecimal-2.5.1-alt2.x86_64.rpm libmpdec3-2.5.1-alt2.x86_64.rpm libmpdecxx3-2.5.1-alt2.x86_64.rpm Name: mpdecimal Summary: Library for general decimal arithmetic The package contains a library limpdec implementing General Decimal Arithmetic Specification. The specification, written by Mike Cowlishaw from IBM, defines a general purpose arbitrary precision data type together with rigorously specified functions and rounding behavior. Name: libmpdec3 Summary: Library for general decimal arithmetic The package contains mpdecimal 2.5.1 libs. Name: libmpdecxx3 Summary: Library for general decimal arithmetic The package contains mpdecimal 2.5.1 libs. Возможно, вам кажется, что Summary и %description никто не читает, но я бы такое не заапрувил бы. Ну и переименование подпакета mpdecimal-devel в libmpdec-devel тоже сделано неаккуратно: Provides без Obsoletes приведёт к тому, что dist-upgrade просто удалит пакет mpdecimal-devel вместо того, чтобы заменить его на libmpdec-devel. У нас же где-то было описано, как правильно переименовывать пакеты?
Spec refactoring. [#314490] TESTED mpdecimal.git=2.5.1-alt3
@toni было бы неплохо исправить замечания ldv
[#313559] TESTED (try 13) blosc2.git=2.6.1-alt1 Blosc2 подходит под это описание? https://www.altlinux.org/Shared_Libs_Policy "В случае, если существует несколько поддерживаемых веток одной библиотеки, %soversion может соответствовать major-версии библиотеки (libqt3, libqt4) или иметь вид major.minor (libdb4.0, libdb4.1). Можно также использовать часть soname’а библиотеки (напр., libcurl4, libflac8)." или что-нибудь нужно подправить чтобы добавить ее в сизиф?
в blosc2 тесты не включены, есть какая-то проблема с ними ?
добавил тесты [#313559] TESTED (try 16) blosc2.git=2.6.1-alt1
(Ответ для Anton Vyatkin на комментарий #46) > добавил тесты > [#313559] TESTED (try 16) blosc2.git=2.6.1-alt1 Спасибо, у меня замечаний нет. Можно коммитить.
Description поправил, Obsoletes добавлен. [#314490] TESTED (try 3) mpdecimal.git=2.5.1-alt3
Там, где добавлен Provides и Obsoletes вместо %version надо использовать %EVR (что превратиться в epoch:version-release) В текущем виде это ошибка. Ну и непонятно, какой смысл несёт пакет mpdecimal без файлов ?
(In reply to Anton Farygin from comment #49) > Ну и непонятно, какой смысл несёт пакет mpdecimal без файлов ? Это был мой совет, чтобы обновляемость не осложнять, это же не просто переименование, а переименование с раздвоением. Когда пакет сохраняется и по зависимостям вытягивает прежние soname provides, у apt'а не должно возникать желания поставить пакет на hold. (In reply to Dmitry V. Levin from comment #35) > Оставьте в основном пакете только зависимости на эти 2 новых подпакета. > > Со временем, скажем, после p11, старый подпакет-пустышку можно будет > упразднить.
Да, понял. Спасибо. Осталось поправить EVR
прошу прощения, не несёт никакой проблемы в данном случае, но вообще лучше делать Obsoletes не <= EVR а < EVR %EVR обсолетить не нужно, вы же его тут выше и провайдите.
[#314490] TESTED (try 4) mpdecimal.git=2.5.1-alt3 Насчет, <= EVR а < EVR, понял. А по поводу Obsoletes. (In reply to Dmitry V. Levin from comment #41) > Provides без Obsoletes приведёт к тому, что dist-upgrade просто удалит пакет > mpdecimal-devel вместо того, чтобы заменить его на libmpdec-devel. Или это было сказано когда было Оbsoletes: mpdecimal-devel, а если < %EVR то обсолетес не нужен?
Obsoletes нужен для того, что бы сказать apt'у, что данный пакет заменяет тот, который описан в obsoletes
На чём мы там остановились?
(In reply to Grigory Ustinov from comment #55) > На чём мы там остановились? На вот этом. [#314490] TESTED (try 4) mpdecimal.git=2.5.1-alt3
Мелочи добейте, про которые я выше писал. и про codelite надо бы всё-таки схему сборки описать, я не смог без описания нормально сделать review проделанной работе.
(In reply to Anton Farygin from comment #57) > Мелочи добейте, про которые я выше писал. > и про codelite надо бы всё-таки схему сборки описать, я не смог без описания > нормально сделать review проделанной работе. Про codelite. Создавал отдельные бранчи для сабмодулей и мерджил их в в ветку upstream потом ее в sisyphus.
[#314490] TESTED (try 5) mpdecimal.git=2.5.1-alt3
(Ответ для Anton Vyatkin на комментарий #58) > (In reply to Anton Farygin from comment #57) > > Мелочи добейте, про которые я выше писал. > > и про codelite надо бы всё-таки схему сборки описать, я не смог без описания > > нормально сделать review проделанной работе. > > Про codelite. Создавал отдельные бранчи для сабмодулей и мерджил их в в > ветку upstream потом ее в sisyphus. а как merge был ? в виде subtree ?
(In reply to Anton Farygin from comment #60) > (Ответ для Anton Vyatkin на комментарий #58) > > (In reply to Anton Farygin from comment #57) > > > Мелочи добейте, про которые я выше писал. > > > и про codelite надо бы всё-таки схему сборки описать, я не смог без описания > > > нормально сделать review проделанной работе. > > > > Про codelite. Создавал отдельные бранчи для сабмодулей и мерджил их в в > > ветку upstream потом ее в sisyphus. > > а как merge был ? в виде subtree ? Нет обычный merge.
а как выполнился обычный merge для двух не связанных историй ? Вот это выглядит ошибкой: https://git.altlinux.org/gears/c/codelite.git?p=codelite.git;a=commitdiff;h=76e6622b48bc4351a11337e4be6962276d535385
(In reply to Anton Farygin from comment #62) > а как выполнился обычный merge для двух не связанных историй ? > > Вот это выглядит ошибкой: > https://git.altlinux.org/gears/c/codelite.git?p=codelite.git;a=commitdiff; > h=76e6622b48bc4351a11337e4be6962276d535385 Делал с --allow-unrelated-histories
Надо было просто подшить историю с ours.
(Ответ для Anton Farygin на комментарий #64) > Надо было просто подшить историю с ours. Антон, в этой схеме идёт не просто подшив истории для тэгов, а полноценное воссоздание каталога исходников. Другой Антон, ну то есть кандидат, сделал это по моей указке. Поэтому слова о том, что это неправильно, я принимаю на свой счёт. Подобная схема реализована во многих других пакетах. kdiskmark, fritzing, purple-telegram - это как минимум.
А как в этой схеме выглядит процесс обновления ? вы же перемещаете все исходники в подкаталог, по идее merge должно быть или очень сложным, или просто с ошибками. Ну и git log на подкаталог тоже будет странно работать. в общем да, я бы считал эту схему за ошибку, но прошу посмотреть на неё Диму ldv@
(Ответ для Anton Farygin на комментарий #66) > А как в этой схеме выглядит процесс обновления ? вы же перемещаете все > исходники в подкаталог, по идее merge должно быть или очень сложным, или > просто с ошибками. > > Ну и git log на подкаталог тоже будет странно работать. > > в общем да, я бы считал эту схему за ошибку, но прошу посмотреть на неё Диму > ldv@ Мердж будет очень сложным. Есть бранч сизиф - это вот результат всех-всех мерджей, там у нас спек и вот это всё. Есть бранчи wxdap и ctags. В них мы мерджим хэши коммитов, которые нужны для новой версии. Есть бранч апстрим - это то куда мы мерджим тэг новой версии и вот эти два бранча. А апстрим мерджится в сизиф. При хорошем понимании гита, это становится не так уж сложно. Если посмотришь в историю пакета purple-telegram, там сабмодуль tgl имел свой сабмодуль tl-parser. И всё обновлялось по этой схеме. Может быть эта схема выглядит сложновато на первый взгляд, но она не становится от этого неправильной. Я Антону по видеоконференции показал обновление пакета kdiskmark с одним сабмодулем и в качестве задания дал codelite с двумя сабмодулями и Антон довольно правильно с моей точки зрения всё воспроизвёл. Я думаю, что то что кандидат освоил такую схему - это должно говорить в его пользу.
(Ответ для Grigory Ustinov на комментарий #67) > (Ответ для Anton Farygin на комментарий #66) > > А как в этой схеме выглядит процесс обновления ? [#314699] TESTED (try 2) codelite.git=17.0.0-alt1 Вот так.
(Ответ для Grigory Ustinov на комментарий #68) > (Ответ для Grigory Ustinov на комментарий #67) > > (Ответ для Anton Farygin на комментарий #66) > > > А как в этой схеме выглядит процесс обновления ? > > [#314699] TESTED (try 2) codelite.git=17.0.0-alt1 > > Вот так. УжОс :( А не проще сделать бранчи на эти submodules, и merge -s ours эти бранчи в sisyphus, можно вместе с upstream? См. как сделан crun, там 4 сабмодуля и upstream сливаются, при пустой основной ветке.
(Ответ для Grigory Ustinov на комментарий #68) > (Ответ для Grigory Ustinov на комментарий #67) > > (Ответ для Anton Farygin на комментарий #66) > > > А как в этой схеме выглядит процесс обновления ? > > [#314699] TESTED (try 2) codelite.git=17.0.0-alt1 > > Вот так. Да, я как раз про то, что это тяжело подждерживается и делаются лишние не нужные движения. Предлагаю пока не прижилось перейти на более простую схему с подшивкой истории через -s ours, как предлагает выше Андрей.
(Ответ для Anton Farygin на комментарий #70) > (Ответ для Grigory Ustinov на комментарий #68) > > (Ответ для Grigory Ustinov на комментарий #67) > > > (Ответ для Anton Farygin на комментарий #66) > > > > А как в этой схеме выглядит процесс обновления ? > > > > [#314699] TESTED (try 2) codelite.git=17.0.0-alt1 > > > > Вот так. > > Да, я как раз про то, что это тяжело подждерживается и делаются лишние не > нужные движения. > > Предлагаю пока не прижилось перейти на более простую схему с подшивкой > истории через -s ours, как предлагает выше Андрей. Предлагаю прочитать, что на этот счёт скажет Дима или Глеб:3
(Ответ для Grigory Ustinov на комментарий #71) > (Ответ для Anton Farygin на комментарий #70) > > (Ответ для Grigory Ustinov на комментарий #68) > > > (Ответ для Grigory Ustinov на комментарий #67) > > > > (Ответ для Anton Farygin на комментарий #66) > > > > > А как в этой схеме выглядит процесс обновления ? > > > > > > [#314699] TESTED (try 2) codelite.git=17.0.0-alt1 > > > > > > Вот так. > > > > Да, я как раз про то, что это тяжело подждерживается и делаются лишние не > > нужные движения. > > > > Предлагаю пока не прижилось перейти на более простую схему с подшивкой > > истории через -s ours, как предлагает выше Андрей. > > Предлагаю прочитать, что на этот счёт скажет Дима или Глеб:3 Что скажет Глеб по этому поводу?
У меня к кандидату нет никаких замечаний, за исключением схемы сборки пакета с submodules.
(Ответ для Anton Farygin на комментарий #73) > У меня к кандидату нет никаких замечаний, за исключением схемы сборки пакета > с submodules. Антон, я задолбался аппрувить таски Антона. Прошу прощения за тавтологию. Ну вы поняли... https://packages.altlinux.org/ru/sisyphus/maintainers/toni/ Пожалуйста, одобри кандидата. Из-за одного грёбаного пакета с сабмодулем, из-за того, что схема не такая как у тебя, приходится вот страдать двум людям.
нет, проблема не в том, что схема не такая как у меня, а в том, что она выглядит ошибкой и с считаю на 100% что плохому учить не надо. Ты же пригласил glebfm и ldv, ну давай дождёмся их реакции на этот вопрос.
(Ответ для Anton Farygin на комментарий #75) > нет, проблема не в том, что схема не такая как у меня, а в том, что она > выглядит ошибкой и с считаю на 100% что плохому учить не надо. > > Ты же пригласил glebfm и ldv, ну давай дождёмся их реакции на этот вопрос. У нас есть регламент ответа приглашённых? А то больше месяца прошло с момента приглашения Глеба.
(In reply to Anton Farygin from comment #62) > Вот это выглядит ошибкой: > https://git.altlinux.org/gears/c/codelite.git?p=codelite.git;a=commitdiff; > h=76e6622b48bc4351a11337e4be6962276d535385 Ручное перемещение файлов выглядит как плохая идея потому что такие вещи гораздо лучше делать штатными средствами git. Было бы гораздо лучше, если бы был использован подход из git howto (using-merge-subtree), настоятельно рекомендую прочитать эту инструкцию (см. пакет git-doc). С этим замечанием, я бы сказал, что этот подход к submodules не хуже других подходов. Выглядит всё так, будто результат получился идентичным натуральному^Wожидаемому в этой схеме, то я не вижу смысла переделывать, но иметь в виду на будущее стоит. Ещё я хочу попросить кандидата запушить и в будущем не забывать пушить бранчи, которые используются для подготовки пакета (для codelite не хватает как минимум бранчей upstream, wxdap и ctags).
Исходя из вышесказанного кандидат готов к самостоятельной работе в Team
Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
(Ответ для Gleb F-Malinovskiy на комментарий #79) > Адрес подписан на devel@. > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Ура! Спасибо.
Благодарю всех за разъяснения и наставления.
