Created attachment 13173 [details] GPGkey Псевдоним: srebrov email: kurachenko.urup@ya.ru Ментор: Григорий Устинов Цель вступления: Научиться собирать пакеты, стать мейнтейнером
Created attachment 13174 [details] SSHkey
Менторство подтверждаю.
Прошу выдать кандидату гитовницу.
(In reply to Anton Kurachenko from comment #0) > Created attachment 13173 [details] > GPGkey Ok. (In reply to Anton Kurachenko from comment #1) > Created attachment 13174 [details] > SSHkey Ok.
ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3.
Кандидат подготовил несколько пакетов. Нам нужна сборочница.
ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5.
На мой взгляд кандидат усвоил некоторые базовые представления о сборке в альт. Были собраны следующие пакеты: [#323285] DONE (try 2) gestures.git=0.3.1-alt2 libinput-gestures.git=2.74-alt2 [#323119] DONE (try 2) cpu-checker.git=0.6-alt1 [#323714] DONE (try 4) openxray.git=1.6.02_1747-alt1 [#324280] DONE (try 2) grub-btrfs.git=4.13-alt1 [#324067] DONE (try 3) polychromatic.git=0.8.1-alt1 openrazer.git=3.6.1-alt1 Предлагаю вызвать рецензента.
Эта переписка попала в devel@ (я думаю, что по ошибке), хотя она напрямую касается работы кандидата: https://lore.altlinux.org/devel/32a0b563-55ef-e166-7559-4128e59f9585@basealt.ru/T/#u
Собраны также: [#325003] DONE (try 3) kde5-kcm-wacomtablet.git=3.2.0-alt1 [#325038] DONE (try 5) puddletag.git=2.2.0-alt1 [#325320] DONE (try 2) kde5-kronometer.git=2.3.0-alt1 И сделано небольшое обновление: [#324414] DONE (try 2) cpu-checker.git=0.6-alt2 [#324563] DONE (try 2) grub-btrfs.git=4.13-alt2
Кандидат упорно продолжает собирать пакеты, мне надоело аппрувить. Настойчиво прошу назначить рецензента!
Cобран: [#329588] DONE (try 7) opentabletdriver.git=0.6.3.0-alt1 И были обновлены: [#331262] DONE (try 3) polychromatic.git=0.8.2-alt1 [#326563] DONE (try 7) openxray.git=1.6.02_2088-alt1 [#334402] DONE (try 2) openrazer.git=3.7.0-alt1
Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6.
Прошу! Назначить! Рецензента!
Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2.
polychromatic - spec написан хорошо, но непонятно почему у пакета не включены интеграционные тесты при их наличии у апстрима. В случае с python тесты крайне желательно включать, т.к. перекладывание скриптов из одного места в другое совсем не гарантирует нормальную работу. Как апстрим запускает тесты можно посмотреть в workflow: https://git.altlinux.org/tasks/archive/done/_326/334788/gears/100/git?p=git;a=blob;f=.github/workflows/main.yml;h=bdddcb5bc8ff92f0a3ba6c0911a0216415092b30;hb=8dcdd80eeace020902299a7cc7ccb722a22d8e5c
https://packages.altlinux.org/ru/sisyphus/srpms/opentabletdriver/specfiles/3031623525162032010#line-55 Удалялять загруженные модули в post-скриптах пакета очень плохая идея. Во первых это ничего не даёт, только на этапе установки пакета и до первой перезагрузки. во вторых в самих скриптах есть куча ошибок, банально заэкранированных игнорами кода возврата. И в третьих вообще не ясно - зачем это делается, какая цель такой операции ? С сервисами там тоже что-то странное делается. Возможно это лучше делать как-то по другому или не делать вовсе, оставив решение о включении сервиса на выбор администратора системы. Просьба ментору помочь привести это в порядок.
У проекта openryzer в библиотеке python тоже есть тесты, было бы неплохо попробовать их запустить. https://packages.altlinux.org/ru/sisyphus/srpms/openrazer
https://packages.altlinux.org/ru/sisyphus/srpms/openxray/specfiles/2982601312294120293#line-46 у cmake есть макросы в альте, их вполне должно хватать для сборки. почему не получилось ими воспользоваться в этом проекте ?
Из этого спека вообще непонятно, откуда брались исходники и где настоящий homepage проекта. https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kronometer/specfiles/2963381156396431418 вообще его, скорее всего, тоже неплохо бы собрать из git: https://invent.kde.org/utilities/kronometer
grub-btrfs отлично приведён в порядок, вопросов нет.
https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kcm-wacomtablet/2961351604776495622 В логах сборки https://git.altlinux.org/tasks/archive/done/_317/325003/build/200/x86_64/log Ошибки поиска gudev-1.0 и из-за её отсутствия, возможно, какой то функционал пакета не работает.
https://packages.altlinux.org/ru/sisyphus/srpms/cpu-checker/specfiles/2958034891713744966#line-29 в секции files лучше включать man страницы как %_man1dir/check-bios-nx.1.*, т.к. алгоритм сжатия может быть изменён без участия ментейнера. Остальное вопросов не вызвало, за исключением того, что собран какой-то очень древний проект, ну и репология показывает что в других дистрибутивах есть версия 0.7
(Ответ для Anton Farygin на комментарий #17) > https://packages.altlinux.org/ru/sisyphus/srpms/opentabletdriver/specfiles/ > 3031623525162032010#line-55 > Удалялять загруженные модули в post-скриптах пакета очень плохая идея. Во > первых это ничего не даёт, только на этапе установки пакета и до первой > перезагрузки. > во вторых в самих скриптах есть куча ошибок, банально заэкранированных > игнорами кода возврата. > И в третьих вообще не ясно - зачем это делается, какая цель такой операции ? > С сервисами там тоже что-то странное делается. Возможно это лучше делать > как-то по другому или не делать вовсе, оставив решение о включении сервиса > на выбор администратора системы. > > Просьба ментору помочь привести это в порядок. Приняв Ваши замечания, переписал спек для opentabletdriver https://git.altlinux.org/tasks/339328 Пакет приведен, практически, к виду rpm из официального гита проекта. По поводу удаления загруженных модулей в post-скриптах. В релизе 0.6.4.0-alt1, и более ранних, удаление модулей, действительно, было практически лишено смысла, потому что после перезагрузки все, по сути, возвращалось обратно. Но в релизе 0.6.4.0-alt2 эта ситуация теперь исправлена соответствующими conf-файлами в modules-load.d и modprobe.d. После рестарта системы все, что должно удалиться - будет удаляться, что должно добавиться - добавляться. А использование post-скрипта позволит пользоваться программой сразу же после установки, что сильно повысит удобство. По поводу systemd-сервиса, соглашусь, что лучше действительно оставить его включение на усмотрение конечного пользователя. Эту часть я удалил из спека. К тому же оно, честно говоря, не работало так, как задумывалось изначально.
А что за тарболл с common файлами лежит в .gear в запакованном виде размеров в 400 мегабайт ? Это ошибка, так не надо делать. Я не заметил этого при предыдущем просмотре пакета. Запакованный тарболл при любом изменении будет есть заметно больше места в гите, чем его содержимое в распакованном виде.
Удаление драйверов post скриптах я по прежнему считаю ошибкой, тем более в таком виде. Лучше этот код вообще убрать и вывести сообщение о том, что после установки пакета требуется перезагрузка.
(Ответ для Anton Farygin на комментарий #25) > А что за тарболл с common файлами лежит в .gear в запакованном виде размеров > в 400 мегабайт ? Nuget-packages необходимые для сборки. > Запакованный тарболл при любом изменении будет есть заметно больше места в > гите, чем его содержимое в распакованном виде. Не подумал об этом. Спасибо.
(Ответ для Anton Farygin на комментарий #26) > Удаление драйверов post скриптах я по прежнему считаю ошибкой, тем более в > таком виде. Лучше этот код вообще убрать и вывести сообщение о том, что > после установки пакета требуется перезагрузка. Хорошо. Переделал. https://git.altlinux.org/tasks/339328/
(Ответ для Anton Farygin на комментарий #22) > https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kcm-wacomtablet/ > 2961351604776495622 > В логах сборки > https://git.altlinux.org/tasks/archive/done/_317/325003/build/200/x86_64/log > Ошибки поиска gudev-1.0 и из-за её отсутствия, возможно, какой то функционал > пакета не работает. Исправил BuildRequires. https://git.altlinux.org/tasks/339717/
Теперь то, что в этом тарболле лежат не исходники а куча бинарных блобов, неизвестно кем собранных, а часто собранных ещё и не для нашей системы - стало видно невооружённым взглядом. Надо или научить вендорить и собирать исходники, или по максимуму научиться собирать с внешними библиотеками.
(Ответ для Anton Farygin на комментарий #30) > Теперь то, что в этом тарболле лежат не исходники а куча бинарных блобов, > неизвестно кем собранных, а часто собранных ещё и не для нашей системы - > стало видно невооружённым взглядом. > > Надо или научить вендорить и собирать исходники, или по максимуму научиться > собирать с внешними библиотеками. У меня нету больше идей, как это собрать. Если и в таком виде пакет не подходит для отправки, предлагаю удалить его и забыть.
В таком случае лучше удалить и забыть.
(Ответ для Anton Farygin на комментарий #32) > В таком случае лучше удалить и забыть. https://git.altlinux.org/tasks/339941
(Ответ для Anton Farygin на комментарий #20) > Из этого спека вообще непонятно, откуда брались исходники и где настоящий > homepage проекта. > https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kronometer/specfiles/ > 2963381156396431418 > > вообще его, скорее всего, тоже неплохо бы собрать из git: > https://invent.kde.org/utilities/kronometer Ок. https://git.altlinux.org/tasks/340031/
(Ответ для Anton Kurachenko на комментарий #34) > (Ответ для Anton Farygin на комментарий #20) > > Из этого спека вообще непонятно, откуда брались исходники и где настоящий > > homepage проекта. > > https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kronometer/specfiles/ > > 2963381156396431418 > > > > вообще его, скорее всего, тоже неплохо бы собрать из git: > > https://invent.kde.org/utilities/kronometer > > Ок. https://git.altlinux.org/tasks/340031/ Тэг VCS ещё добавьте, пожалуйста: VCS: https://invent.kde.org/utilities/kronometer.git В него очень удобно помещать ссылку на git репозиторий апстрима.
(Ответ для Anton Farygin на комментарий #35) > Тэг VCS ещё добавьте, пожалуйста: > VCS: https://invent.kde.org/utilities/kronometer.git > > В него очень удобно помещать ссылку на git репозиторий апстрима. Fixed https://git.altlinux.org/tasks/340031/
(Ответ для Anton Farygin на комментарий #19) > https://packages.altlinux.org/ru/sisyphus/srpms/openxray/specfiles/ > 2982601312294120293#line-46 > > у cmake есть макросы в альте, их вполне должно хватать для сборки. > почему не получилось ими воспользоваться в этом проекте ? Можно и с макросами. Заодно обновил версию.https://git.altlinux.org/tasks/340403/
(Ответ для Anton Farygin на комментарий #16) > polychromatic - spec написан хорошо, но непонятно почему у пакета не > включены интеграционные тесты при их наличии у апстрима. В случае с python > тесты крайне желательно включать, т.к. перекладывание скриптов из одного > места в другое совсем не гарантирует нормальную работу. > > Как апстрим запускает тесты можно посмотреть в workflow: > https://git.altlinux.org/tasks/archive/done/_326/334788/gears/100/git?p=git; > a=blob;f=.github/workflows/main.yml; > h=bdddcb5bc8ff92f0a3ba6c0911a0216415092b30; > hb=8dcdd80eeace020902299a7cc7ccb722a22d8e5c Добавил интегнарционные тесты. Получилось как-то так. https://git.altlinux.org/tasks/340425/
(Ответ для Anton Kurachenko на комментарий #36) > (Ответ для Anton Farygin на комментарий #35) > > Тэг VCS ещё добавьте, пожалуйста: > > VCS: https://invent.kde.org/utilities/kronometer.git > > > > В него очень удобно помещать ссылку на git репозиторий апстрима. > > Fixed https://git.altlinux.org/tasks/340031/ Спасибо.
(Ответ для Anton Kurachenko на комментарий #37) > (Ответ для Anton Farygin на комментарий #19) > > https://packages.altlinux.org/ru/sisyphus/srpms/openxray/specfiles/ > > 2982601312294120293#line-46 > > > > у cmake есть макросы в альте, их вполне должно хватать для сборки. > > почему не получилось ими воспользоваться в этом проекте ? > > Можно и с макросами. Заодно обновил > версию.https://git.altlinux.org/tasks/340403/ Неплохо получилось, спасибо.
(Ответ для Anton Kurachenko на комментарий #38) > (Ответ для Anton Farygin на комментарий #16) > > polychromatic - spec написан хорошо, но непонятно почему у пакета не > > включены интеграционные тесты при их наличии у апстрима. В случае с python > > тесты крайне желательно включать, т.к. перекладывание скриптов из одного > > места в другое совсем не гарантирует нормальную работу. > > > > Как апстрим запускает тесты можно посмотреть в workflow: > > https://git.altlinux.org/tasks/archive/done/_326/334788/gears/100/git?p=git; > > a=blob;f=.github/workflows/main.yml; > > h=bdddcb5bc8ff92f0a3ba6c0911a0216415092b30; > > hb=8dcdd80eeace020902299a7cc7ccb722a22d8e5c > > Добавил интегнарционные тесты. Получилось как-то так. > https://git.altlinux.org/tasks/340425/ 11 + if getpass.getuser() == 'builder': 12 + return True 13 + А не допускаете ситуации, когда пользователь решит себя назвать builder ? Спросите, пожалуйста, у ментора - может быть есть какие-то другие варианты определить ограничения среды ?
(Ответ для Anton Farygin на комментарий #41) > (Ответ для Anton Kurachenko на комментарий #38) > > (Ответ для Anton Farygin на комментарий #16) > > > polychromatic - spec написан хорошо, но непонятно почему у пакета не > > > включены интеграционные тесты при их наличии у апстрима. В случае с python > > > тесты крайне желательно включать, т.к. перекладывание скриптов из одного > > > места в другое совсем не гарантирует нормальную работу. > > > > > > Как апстрим запускает тесты можно посмотреть в workflow: > > > https://git.altlinux.org/tasks/archive/done/_326/334788/gears/100/git?p=git; > > > a=blob;f=.github/workflows/main.yml; > > > h=bdddcb5bc8ff92f0a3ba6c0911a0216415092b30; > > > hb=8dcdd80eeace020902299a7cc7ccb722a22d8e5c > > > > Добавил интегнарционные тесты. Получилось как-то так. > > https://git.altlinux.org/tasks/340425/ > > 11 + if getpass.getuser() == 'builder': > 12 + return True > 13 + > > А не допускаете ситуации, когда пользователь решит себя назвать builder ? > > Спросите, пожалуйста, у ментора - может быть есть какие-то другие варианты > определить ограничения среды ? Ок, я поинтересуюсь у ментора по данному вопросу. Но, замечу, что этот патч применяется к исходному коду openrazer, который нужен тут исключительно для проведения интеграционного теста и дальше в пакет не пакуется. Если пользователь назовет себя builder, то это никак не скажется на работе пакета.
Ментору категорически не нравится коммит: https://git.altlinux.org/tasks/340425/gears/100/git?p=git;a=commitdiff;h=dd790c120ece82c81080eb703f70fb91a714841e Здесь приезжают исходники openrazer 3.7.0, а что будет, когда openrazer обновится? Я бы подумал об упаковке чего-то вроде openrazer-tests и чтобы в polychromatic оно подтягивалось по buildrequires.
(Ответ для Anton Farygin на комментарий #41) > А не допускаете ситуации, когда пользователь решит себя назвать builder ? Такой пользователь сам себе злобный буратино. Мы не можем ограничить всех желающих выстрелить себе в ногу=)
(In reply to Anton Farygin from comment #41) > (Ответ для Anton Kurachenko на комментарий #38) > 11 + if getpass.getuser() == 'builder': > 12 + return True > 13 + > > А не допускаете ситуации, когда пользователь решит себя назвать builder ? > > Спросите, пожалуйста, у ментора - может быть есть какие-то другие варианты > определить ограничения среды ? Я не ментор, но набросить (FWIW) могу. Когда-то был такой макрос "__BTE" и, вроде, ещё остался. Его смысл в том, что он определён в изолированном окружении без сети, предоставляемом hasher, в котором ряд тестов (например, требующих сеть) работать не будет. Может быть, это изменение можно накладывать при наличии этого __BTE. (Заворачивать туда %patch0 и Patch0:, конечно же, не имеет смысла) Пусть, если что, меня поправит кто-то, кто этим занимался 20 лет назад. :) Ещё некоторые любят детектить конкретно hasher вот так: /bin/sh -c '[ -d /.host -a -d /.in -a -d /.out ]' Но лично я не уверен, что эти каталоги стоит делать частью интерфейса hasher.
(In reply to Grigory Ustinov from comment #43) > Ментору категорически не нравится коммит: > https://git.altlinux.org/tasks/340425/gears/100/git?p=git;a=commitdiff; > h=dd790c120ece82c81080eb703f70fb91a714841e > Здесь приезжают исходники openrazer 3.7.0, а что будет, когда openrazer > обновится? > > Я бы подумал об упаковке чего-то вроде openrazer-tests и чтобы в > polychromatic оно подтягивалось по buildrequires. +1
(Ответ для Grigory Ustinov на комментарий #43) > Ментору категорически не нравится коммит: > https://git.altlinux.org/tasks/340425/gears/100/git?p=git;a=commitdiff; > h=dd790c120ece82c81080eb703f70fb91a714841e > Здесь приезжают исходники openrazer 3.7.0, а что будет, когда openrazer > обновится? > > Я бы подумал об упаковке чего-то вроде openrazer-tests и чтобы в > polychromatic оно подтягивалось по buildrequires. Понял. Буду паковать.
(Ответ для Anton Farygin на комментарий #23) > https://packages.altlinux.org/ru/sisyphus/srpms/cpu-checker/specfiles/ > 2958034891713744966#line-29 > > в секции files лучше включать man страницы как %_man1dir/check-bios-nx.1.*, > т.к. алгоритм сжатия может быть изменён без участия ментейнера. > > Остальное вопросов не вызвало, за исключением того, что собран какой-то > очень древний проект, ну и репология показывает что в других дистрибутивах > есть версия 0.7 Проект древний, но работает и присутствует в достаточном количестве дистрибутивов. Собрал версию 0.7 https://git.altlinux.org/tasks/340770/
(Ответ для Anton Kurachenko на комментарий #48) > (Ответ для Anton Farygin на комментарий #23) > > https://packages.altlinux.org/ru/sisyphus/srpms/cpu-checker/specfiles/ > > 2958034891713744966#line-29 > > > > в секции files лучше включать man страницы как %_man1dir/check-bios-nx.1.*, > > т.к. алгоритм сжатия может быть изменён без участия ментейнера. > > > > Остальное вопросов не вызвало, за исключением того, что собран какой-то > > очень древний проект, ну и репология показывает что в других дистрибутивах > > есть версия 0.7 > > Проект древний, но работает и присутствует в достаточном количестве > дистрибутивов. Собрал версию 0.7 https://git.altlinux.org/tasks/340770/ Имена патчей надо привести в соответствие с рекомендациями: https://www.altlinux.org/ALT_Packaging_HOWTO#%D0%9D%D0%B0%D0%B8%D0%BC%D0%B5%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5_%D0%BF%D0%B0%D1%82%D1%87%D0%B5%D0%B9 И ещё заметил - сжимать тарболл: https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b;hb=ce0d18b75b6a591c2e863e514381d83c3681a630 нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие тарболла необходимо.
(Ответ для Anton Farygin на комментарий #49) > И ещё заметил - сжимать тарболл: > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > тарболла необходимо. Где можно узнать об этом подробнее?
(Ответ для Anton Kurachenko на комментарий #50) > (Ответ для Anton Farygin на комментарий #49) > > И ещё заметил - сжимать тарболл: > > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > тарболла необходимо. > > Где можно узнать об этом подробнее? Вопрос хороший! Ну вообще сжатие было актуально раньше, когда информационные накопители стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам важнее разгрузить сборочные узлы и не забивать их ненужными действиями. Понятное дело, что это не критичная ошибка, но по возможности, лучше делать просто tar.
(Ответ для Grigory Ustinov на комментарий #51) > (Ответ для Anton Kurachenko на комментарий #50) > > (Ответ для Anton Farygin на комментарий #49) > > > И ещё заметил - сжимать тарболл: > > > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > > > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > > > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > > > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > > тарболла необходимо. > > > > Где можно узнать об этом подробнее? > > Вопрос хороший! > > Ну вообще сжатие было актуально раньше, когда информационные накопители > стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам > важнее разгрузить сборочные узлы и не забивать их ненужными действиями. > Понятное дело, что это не критичная ошибка, но по возможности, лучше делать > просто tar. Хорошо. Переделал https://git.altlinux.org/tasks/340770/
Также, внес небольшие коррективы в kde5-kcm-wacomtablet https://git.altlinux.org/tasks/339717/
(Ответ для Grigory Ustinov на комментарий #51) > (Ответ для Anton Kurachenko на комментарий #50) > > (Ответ для Anton Farygin на комментарий #49) > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > > тарболла необходимо. > > > > Где можно узнать об этом подробнее? > > Вопрос хороший! > > Ну вообще сжатие было актуально раньше, когда информационные накопители > стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам > важнее разгрузить сборочные узлы и не забивать их ненужными действиями. > Понятное дело, что это не критичная ошибка, но по возможности, лучше делать > просто tar. Всё ещё проще - наш rpm жмёт сам неплохим алгоритмом и смысла от двойного пережатия не много.
(Ответ для Anton Kurachenko на комментарий #52) > (Ответ для Grigory Ustinov на комментарий #51) > > (Ответ для Anton Kurachenko на комментарий #50) > > > (Ответ для Anton Farygin на комментарий #49) > > > > И ещё заметил - сжимать тарболл: > > > > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > > > > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > > > > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > > > > > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > > > тарболла необходимо. > > > > > > Где можно узнать об этом подробнее? > > > > Вопрос хороший! > > > > Ну вообще сжатие было актуально раньше, когда информационные накопители > > стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам > > важнее разгрузить сборочные узлы и не забивать их ненужными действиями. > > Понятное дело, что это не критичная ошибка, но по возможности, лучше делать > > просто tar. > > Хорошо. Переделал https://git.altlinux.org/tasks/340770/ Спасибо. Но мне показалось странным то, что в секции %build make_build передаётся DESTDIR и я пошёл посмотреть в Makefile. А в нём нет никакого build: 7 install: 8 for i in $(SCRIPTS); do \ 9 install -D -m 755 $$i $(DESTDIR)/usr/sbin/$$i; \ 10 install -D -m 644 $$i.1 $(DESTDIR)/usr/share/man/man1/$$i.1; \ 11 done 12 13 tarball: 14 mkdir cpu-checker-$(VERSION) 15 for i in $(SCRIPTS); do \ 16 cp -a $$i cpu-checker-$(VERSION)/; \ 17 cp -a $$i.1 cpu-checker-$(VERSION)/; \ 18 done 19 cp -a Makefile test old update-notifier cpu-checker-$(VERSION)/ 20 tar --exclude test --exclude old --exclude update-notifier -czf ../cpu-checker-$(VERSION).tar.gz cpu-checker-$(VERSION) 21 rm -rf cpu-checker-$(VERSION)
(Ответ для Anton Kurachenko на комментарий #53) > Также, внес небольшие коррективы в kde5-kcm-wacomtablet > https://git.altlinux.org/tasks/339717/ 56 #Fix build with Qt 5.15 57 sed -i '24a #include <QPainterPath>' src/kcmodule/pressurecurvewidget.cpp Я иногда тоже правлю файлы в спеке sed'ом, но в целом это считается плохой практикой. Лучше сделать обычный патч.
(Ответ для Anton Farygin на комментарий #55) > (Ответ для Anton Kurachenko на комментарий #52) > > (Ответ для Grigory Ustinov на комментарий #51) > > > (Ответ для Anton Kurachenko на комментарий #50) > > > > (Ответ для Anton Farygin на комментарий #49) > > > > > И ещё заметил - сжимать тарболл: > > > > > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > > > > > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > > > > > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > > > > > > > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > > > > тарболла необходимо. > > > > > > > > Где можно узнать об этом подробнее? > > > > > > Вопрос хороший! > > > > > > Ну вообще сжатие было актуально раньше, когда информационные накопители > > > стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам > > > важнее разгрузить сборочные узлы и не забивать их ненужными действиями. > > > Понятное дело, что это не критичная ошибка, но по возможности, лучше делать > > > просто tar. > > > > Хорошо. Переделал https://git.altlinux.org/tasks/340770/ > > Спасибо. Но мне показалось странным то, что в секции %build make_build > передаётся DESTDIR и я пошёл посмотреть в Makefile. > > А в нём нет никакого build: > 7 install: > 8 for i in $(SCRIPTS); do \ > 9 install -D -m 755 $$i $(DESTDIR)/usr/sbin/$$i; \ > 10 install -D -m 644 $$i.1 > $(DESTDIR)/usr/share/man/man1/$$i.1; \ > 11 done > 12 > 13 tarball: > 14 mkdir cpu-checker-$(VERSION) > 15 for i in $(SCRIPTS); do \ > 16 cp -a $$i cpu-checker-$(VERSION)/; \ > 17 cp -a $$i.1 cpu-checker-$(VERSION)/; \ > 18 done > 19 cp -a Makefile test old update-notifier cpu-checker-$(VERSION)/ > 20 tar --exclude test --exclude old --exclude update-notifier -czf > ../cpu-checker-$(VERSION).tar.gz cpu-checker-$(VERSION) > 21 rm -rf cpu-checker-$(VERSION) Fixed [#340770] TESTED (try 4) cpu-checker.git=0.7-alt1
Заапрувил, можно запускать.
(Ответ для Anton Farygin на комментарий #58) > Заапрувил, можно запускать. Спасибо!
(Ответ для Anton Farygin на комментарий #56) > (Ответ для Anton Kurachenko на комментарий #53) > > Также, внес небольшие коррективы в kde5-kcm-wacomtablet > > https://git.altlinux.org/tasks/339717/ > > 56 #Fix build with Qt 5.15 > 57 sed -i '24a #include <QPainterPath>' > src/kcmodule/pressurecurvewidget.cpp > > Я иногда тоже правлю файлы в спеке sed'ом, но в целом это считается плохой > практикой. Лучше сделать обычный патч. Ок. Переделал с использованием патч-файла [#339717] TESTED (try 4) kde5-kcm-wacomtablet.git=3.2.0-alt2
(Ответ для Anton Kurachenko на комментарий #60) > Ок. Переделал с использованием патч-файла [#339717] TESTED (try 4) > kde5-kcm-wacomtablet.git=3.2.0-alt2 Спасибо. Заапрувил, можно коммитить.
(Ответ для Anton Farygin на комментарий #41) > (Ответ для Anton Kurachenko на комментарий #38) > > (Ответ для Anton Farygin на комментарий #16) > > > polychromatic - spec написан хорошо, но непонятно почему у пакета не > > > включены интеграционные тесты при их наличии у апстрима. В случае с python > > > тесты крайне желательно включать, т.к. перекладывание скриптов из одного > > > места в другое совсем не гарантирует нормальную работу. > > > > > > Как апстрим запускает тесты можно посмотреть в workflow: > > > https://git.altlinux.org/tasks/archive/done/_326/334788/gears/100/git?p=git; > > > a=blob;f=.github/workflows/main.yml; > > > h=bdddcb5bc8ff92f0a3ba6c0911a0216415092b30; > > > hb=8dcdd80eeace020902299a7cc7ccb722a22d8e5c > > > > Добавил интегнарционные тесты. Получилось как-то так. > > https://git.altlinux.org/tasks/340425/ > > 11 + if getpass.getuser() == 'builder': > 12 + return True > 13 + > > А не допускаете ситуации, когда пользователь решит себя назвать builder ? > > Спросите, пожалуйста, у ментора - может быть есть какие-то другие варианты > определить ограничения среды ? Чтобы не расстраивать системных пользователей с именем builder, предлагаю такой вариант: https://git.altlinux.org/tasks/341223/
Не стало сильно лучше. +# fix plugdev validation +sed -i '192 s/\(.*\)'\''root'\''\(.*\)/\1'\''builder'\''\2/' daemon/%{name}_daemon/daemon.py 1) редактирование sed'ом исходников в секции check не даёт возможности отлаживать запуск и сборку через rpmbuild --short-circuit 2) принципиально ничего не изменилось - пользователь имеет право собрать пакет в обычной системе без hasher и сборка в такой системе работать не будет.
(Ответ для Anton Farygin на комментарий #63) > Не стало сильно лучше. > > +# fix plugdev validation > +sed -i '192 s/\(.*\)'\''root'\''\(.*\)/\1'\''builder'\''\2/' > daemon/%{name}_daemon/daemon.py > > 1) редактирование sed'ом исходников в секции check не даёт возможности > отлаживать запуск и сборку через rpmbuild --short-circuit > 2) принципиально ничего не изменилось - пользователь имеет право собрать > пакет в обычной системе без hasher и сборка в такой системе работать не > будет. Воспользовавшись информацией из комметария #43 переделал патч [#341223] TESTED (try 4) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2
Мне, как и Арсению - не нравится этот вариант. Я бы сделал ещё проще - добавил проверку переменной окружения (имя надо придумать такое, что бы нормальному человеку в голову не пришло его использовать в своей системе). а в секции check сделал бы экспорт этой переменной. Ну, например SKIP_PLUGDEV_GROUP_FOR_TESTS=1
(Ответ для Anton Farygin на комментарий #65) > что бы нормальному человеку в голову не пришло его > использовать в своей системе). Нормальному человеку в голову и не придёт назвать себя builder:)
(Ответ для Anton Farygin на комментарий #65) > Мне, как и Арсению - не нравится этот вариант. > Я бы сделал ещё проще - добавил проверку переменной окружения (имя надо > придумать такое, что бы нормальному человеку в голову не пришло его > использовать в своей системе). > > а в секции check сделал бы экспорт этой переменной. > > Ну, например SKIP_PLUGDEV_GROUP_FOR_TESTS=1 Ок. [#341223] TESTED (try 5) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2
(Ответ для Grigory Ustinov на комментарий #66) > (Ответ для Anton Farygin на комментарий #65) > > что бы нормальному человеку в голову не пришло его > > использовать в своей системе). > > Нормальному человеку в голову и не придёт назвать себя builder:) А что ты имеешь против строителей ?
Внес небольшие косметические изменения:[#341223] TESTED (try 6) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2
(Ответ для Anton Kurachenko на комментарий #69) > Внес небольшие косметические изменения:[#341223] TESTED (try 6) > openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2 Спасибо. Добавьте ещё (уж коль жёстко завязываетесь) в пакете polychromatic версию openrazer-test-sources в зависимости. +BuildRequires: openrazer-test-sources Но намного лучше в процессе тестирования не использовать отдельно упакованные исходники в /usr/src, а проверять работу polychromatic с установленными в систему пакетами openrazer - питоновским модулем и сервисом. так вы заодно проверите качество упаковки и интеграции в систему openrazer.
(Ответ для Anton Farygin на комментарий #70) > Но намного лучше в процессе тестирования не использовать отдельно > упакованные исходники в /usr/src, а проверять работу polychromatic с > установленными в систему пакетами openrazer - питоновским модулем и сервисом. > > так вы заодно проверите качество упаковки и интеграции в систему openrazer. Получилось вот так [#341223] TESTED (try 9) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2
Более правильный вариант: [#341223] TESTED (try 11) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2
(Ответ для Anton Kurachenko на комментарий #72) > Более правильный вариант: [#341223] TESTED (try 11) openrazer.git=3.7.0-alt2 > polychromatic.git=0.8.3-alt2 Спасибо. Теперь выглядит нормально. Выдал аппрув, закоммитите пожалуйста в репозиторий.
(Ответ для Anton Farygin на комментарий #73) > (Ответ для Anton Kurachenko на комментарий #72) > > Более правильный вариант: [#341223] TESTED (try 11) openrazer.git=3.7.0-alt2 > > polychromatic.git=0.8.3-alt2 > > Спасибо. Теперь выглядит нормально. > > Выдал аппрув, закоммитите пожалуйста в репозиторий. [#341223] DONE (try 12) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2 [#339717] DONE (try 5) kde5-kcm-wacomtablet.git=3.2.0-alt2 [#340770] DONE (try 5) cpu-checker.git=0.7-alt1 [#340031] DONE (try 3) kde5-kronometer.git=2.3.0-alt2 [#340403] DONE (try 2) openxray.git=1.6.02_2188-alt1 [#339941] DONE (try 2) del=opentabletdriver
Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1
(Ответ для Anton Kurachenko на комментарий #75) > Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1 В лицензии, указанной в пакете есть ошибка. при переходе от одного стиля к другому ведения репозитория можно было пропустить этап переноса исходников в root. Ну и я бы предложил заодно освоить ещё один вариант сборки python пакетов (а именно отслеживания зависимостей), который сейчас набирает популярность. Попробуйте перевести на него свой пакет: https://www.altlinux.org/Management_of_Python_dependencies_sources
(Ответ для Anton Farygin на комментарий #76) > (Ответ для Anton Kurachenko на комментарий #75) > > Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1 > > В лицензии, указанной в пакете есть ошибка. > > при переходе от одного стиля к другому ведения репозитория можно было > пропустить этап переноса исходников в root. > > Ну и я бы предложил заодно освоить ещё один вариант сборки python пакетов (а > именно отслеживания зависимостей), который сейчас набирает популярность. > Попробуйте перевести на него свой пакет: > > https://www.altlinux.org/Management_of_Python_dependencies_sources Спасибо. Попробую перевести.
(Ответ для Anton Kurachenko на комментарий #77) > (Ответ для Anton Farygin на комментарий #76) > > (Ответ для Anton Kurachenko на комментарий #75) > > > Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1 > > > > В лицензии, указанной в пакете есть ошибка. > > > > при переходе от одного стиля к другому ведения репозитория можно было > > пропустить этап переноса исходников в root. > > > > Ну и я бы предложил заодно освоить ещё один вариант сборки python пакетов (а > > именно отслеживания зависимостей), который сейчас набирает популярность. > > Попробуйте перевести на него свой пакет: > > > > https://www.altlinux.org/Management_of_Python_dependencies_sources > > Спасибо. Попробую перевести. Я категорически против изучения моим подопечным этого метода сборки. Изучение больных фантазий одного человека не является обязательным для вступления в тим. Популярность этот метод набирает только в одном городе. Пусть он там и остаётся.
(Ответ для Grigory Ustinov на комментарий #78) > (Ответ для Anton Kurachenko на комментарий #77) > > (Ответ для Anton Farygin на комментарий #76) > > > (Ответ для Anton Kurachenko на комментарий #75) > > > > Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1 > > > > > > В лицензии, указанной в пакете есть ошибка. > > > > > > при переходе от одного стиля к другому ведения репозитория можно было > > > пропустить этап переноса исходников в root. > > > > > > Ну и я бы предложил заодно освоить ещё один вариант сборки python пакетов (а > > > именно отслеживания зависимостей), который сейчас набирает популярность. > > > Попробуйте перевести на него свой пакет: > > > > > > https://www.altlinux.org/Management_of_Python_dependencies_sources > > > > Спасибо. Попробую перевести. Давайте будем учить кандидатов проверенными и одобренными сообществом схемами сборки? Предложенный выше механизм не был принят и даже не был широко обсуждён. Попытки протолкнуть его через массовое насильное приучение кандидатов крайне неэтичны.
398 пакетов на данный момент в репозитории используют эту схему сборки (почти 20% от всех python пакетов) и их количество растёт. Кандидату придётся с ней столкнуться при сборке python пакетов и других вариантов не будет. Если есть конкретные замечания к этой схеме формирования списка сборочных зависимостей, то их надо опубликовать и обсудить в devel.
(Ответ для Anton Farygin на комментарий #80) > 398 пакетов на данный момент в репозитории используют эту схему сборки > (почти 20% от всех python пакетов) и их количество растёт. Кандидату > придётся с ней столкнуться при сборке python пакетов и других вариантов не > будет. > > Если есть конкретные замечания к этой схеме формирования списка сборочных > зависимостей, то их надо опубликовать и обсудить в devel. Именно такого подхода я и опасаюсь. Агрессивное замещение. Их было бы намного меньше, если бы некоторые менторы и рецензенты не включали её в обязательный курс джойна. Почти 20% - это выглядит уже как порог. Я не против, чтобы "разработчик схемы" использовал её в своих пакетах, но обучать и принуждать к этому остальных считаю неправильным. В ближайшее время подготовлю письмо для обсуждения в сообществе, а пока что предлагаю избегать провокаций и сосредоточиться на изучении кандидатом общепринятых схем.
Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её применить я проанализировал статистику её использования, и если бы она не была такой как есть - от меня такой просьбы явно бы не последовало. Поэтому так же прошу посмотреть и попробовать применить новую схему работы с зависимостями в python пакетах, уж коль она стала такой распространённой.
ну и второе - как мне кажется ментор не должен навязывать своё личное предубеждение против тех или иных способов упаковки. Его задача - научить разным вариантам и схемам, объяснить отличия, преимущества и недостатки каждой из них. Дать и проверить знания. Ровно этим я в данной задаче и занимаюсь.
(Ответ для Anton Farygin на комментарий #83) > ну и второе - как мне кажется ментор не должен навязывать своё личное > предубеждение против тех или иных способов упаковки. Его задача - научить > разным вариантам и схемам, объяснить отличия, преимущества и недостатки > каждой из них. Дать и проверить знания. > > Ровно этим я в данной задаче и занимаюсь. Именно этим и должен заниматься ментор: показывать правильные подходы и исправлять ошибочные. В частности, некоторое время назад благодаря некоторым людям, я уж честно и не могу показать пальцем с кого, обрела популярность схема сборки, где сборка идёт из тэга, который мерджится по стратегии ours и фактически в основной ветке отсутствуют исходники, есть только спек, рульс и патчи. Это было модно, но потом большая часть мейнтейнеров осознала всю неудобность прыганья по веткам во время отладки сборки и от этой схемы пришлось отказаться. Я в свою очередь когда-то продвигал идеи спексабст схемы, в которой из шаблона генерировались одновременно 2, а то и 4 пакета для разных питонов. Ещё один пример неудачной и неудобной схемы, она до сих пор используется в некоторых пакетах не связанных с питоном, где её использование оправдано, но благодаря отказу от второго питона в массовое использование она слава богу не пошла. Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов кандидат и сам может нахвататься:)
(In reply to Grigory Ustinov from comment #84) > Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов > кандидат и сам может нахвататься:) Раз уж пошло на то дело, то может тогда объясните чем плох подход к сборке Python-пакетов с альтернативным способом управления источниками завимостей? (In reply to Grigory Ustinov from comment #81) > Именно такого подхода я и опасаюсь. Агрессивное замещение. Их было бы > намного меньше, если бы некоторые менторы и рецензенты не включали её в > обязательный курс джойна. Почти 20% - это выглядит уже как порог. Я не > против, чтобы "разработчик схемы" использовал её в своих пакетах, но обучать > и принуждать к этому остальных считаю неправильным. Вы говорите неправду. Эту схему никто насильно не проталкивает и агрессивным замещением предыдущих ("общепринятых") не занимается. > В ближайшее время подготовлю письмо для обсуждения в сообществе, а пока > что предлагаю избегать провокаций и сосредоточиться на изучении кандидатом > общепринятых схем. Отлично, ждем письмо. Надеюсь, там аргументы какие-нибудь появятся.
(Ответ для Grigory Ustinov на комментарий #84) > > Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов > кандидат и сам может нахвататься:) Да конечно, но лично у меня нет серьёзных предубеждений против новой схемы сборки с автогенерацией зависимостей. Там немного хромает юзабилити, которое надо доработать. Но на низком уровне она (после того, как понять схему работы) - отлично справляется.
(Ответ для Anton Farygin на комментарий #82) > Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её > применить я проанализировал статистику её использования, и если бы она не > была такой как есть - от меня такой просьбы явно бы не последовало. > > Поэтому так же прошу посмотреть и попробовать применить новую схему работы с > зависимостями в python пакетах, уж коль она стала такой распространённой. [#342094] TESTED (try 5) puddletag.git=2.3.0-alt1
(Ответ для Anton Kurachenko на комментарий #87) > (Ответ для Anton Farygin на комментарий #82) > > Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её > > применить я проанализировал статистику её использования, и если бы она не > > была такой как есть - от меня такой просьбы явно бы не последовало. > > > > Поэтому так же прошу посмотреть и попробовать применить новую схему работы с > > зависимостями в python пакетах, уж коль она стала такой распространённой. > > [#342094] TESTED (try 5) puddletag.git=2.3.0-alt1 Выглядит круто, спасибо. Заапрувил. Свои впечатления про эту систему сборки, если не сложно, опишите пожалуйста в devel когда будет письмо от Гриши. В целом я считаю что кандидат освоил сборку пакетов, в целом уже понимает требования. Не видел сборку по SharedLibsPolicy, но думаю что он почитает и попросит поревьювить старших коллег. Так что он готов к самостоятельной работе. К кандидату просьба отправлять мне на ревью первое время (в личке) пакеты, что бы не допускать явных ошибок, при проблемах не стесняться консультироваться. Спасибо.
(Ответ для Anton Farygin на комментарий #88) > Выглядит круто, спасибо. Заапрувил. Благодарю. > Свои впечатления про эту систему сборки, если не сложно, опишите пожалуйста > в devel когда будет письмо от Гриши. Ок. > К кандидату просьба отправлять мне на ревью первое время (в личке) пакеты, > что бы не допускать явных ошибок, при проблемах не стесняться > консультироваться. Хорошо. Спасибо большое!
Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства!
(Ответ для Gleb F-Malinovskiy на комментарий #90) > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Спасибо! Это был долгий путь, но я реально многому научился. Хочу выразить свою благодарность всем, кто учавствовал в моем процессе JOIN'а!
