46137 2023-05-13 16:55:22 +0300 [done] join srebrov@ 2024-03-26 22:44:03 +0300 1 1 4 Development Team Accounts join unspecified x86_64 Linux CLOSED FIXED https://altlinux.org/Team/Join P5 normal --- 1 kurachenko.urup glebfm ancieg arseny dutyrok glebfm grenka grenka ldv rider sin cas oldest_to_newest 225785 0 13173 kurachenko.urup 2023-05-13 16:55:22 +0300 Created attachment 13173 GPGkey Псевдоним: srebrov email: kurachenko.urup@ya.ru Ментор: Григорий Устинов Цель вступления: Научиться собирать пакеты, стать мейнтейнером 225786 1 13174 kurachenko.urup 2023-05-13 16:56:10 +0300 Created attachment 13174 SSHkey 225788 2 grenka 2023-05-13 17:54:44 +0300 Менторство подтверждаю. 225878 3 grenka 2023-05-15 19:47:09 +0300 Прошу выдать кандидату гитовницу. 226522 4 glebfm 2023-05-26 12:20:36 +0300 (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. 227332 5 glebfm 2023-06-08 18:17:59 +0300 ssh ключ на gitery.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.3. 227423 6 grenka 2023-06-11 18:56:38 +0300 Кандидат подготовил несколько пакетов. Нам нужна сборочница. 227467 7 glebfm 2023-06-13 14:36:41 +0300 ssh ключ на gyle.alt зарегистрирован. Пакет alt-gpgkeys обновлён. T/J/S -> 3.5. 228986 8 grenka 2023-07-05 12:27:48 +0300 На мой взгляд кандидат усвоил некоторые базовые представления о сборке в альт. Были собраны следующие пакеты: [#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 Предлагаю вызвать рецензента. 229501 9 glebfm 2023-07-11 22:37:54 +0300 Эта переписка попала в devel@ (я думаю, что по ошибке), хотя она напрямую касается работы кандидата: https://lore.altlinux.org/devel/32a0b563-55ef-e166-7559-4128e59f9585@basealt.ru/T/#u 230304 10 kurachenko.urup 2023-07-24 23:03:45 +0300 Собраны также: [#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 234529 11 grenka 2023-10-09 09:59:47 +0300 Кандидат упорно продолжает собирать пакеты, мне надоело аппрувить. Настойчиво прошу назначить рецензента! 237380 12 kurachenko.urup 2023-11-17 09:14:46 +0300 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 238449 13 glebfm 2023-12-05 19:21:06 +0300 Адрес подписан на devel@, теперь это делается раньше -- в пункте 3.6. 240412 14 grenka 2024-01-21 23:34:22 +0300 Прошу! Назначить! Рецензента! 240496 15 glebfm 2024-01-23 17:59:40 +0300 Призван рецензент (rider@) для независимой оценки готовности кандидата. T/J/S -> 4.2. 240513 16 rider 2024-01-23 21:10:33 +0300 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 240514 17 rider 2024-01-23 21:17:51 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/opentabletdriver/specfiles/3031623525162032010#line-55 Удалялять загруженные модули в post-скриптах пакета очень плохая идея. Во первых это ничего не даёт, только на этапе установки пакета и до первой перезагрузки. во вторых в самих скриптах есть куча ошибок, банально заэкранированных игнорами кода возврата. И в третьих вообще не ясно - зачем это делается, какая цель такой операции ? С сервисами там тоже что-то странное делается. Возможно это лучше делать как-то по другому или не делать вовсе, оставив решение о включении сервиса на выбор администратора системы. Просьба ментору помочь привести это в порядок. 240517 18 rider 2024-01-23 21:21:03 +0300 У проекта openryzer в библиотеке python тоже есть тесты, было бы неплохо попробовать их запустить. https://packages.altlinux.org/ru/sisyphus/srpms/openrazer 240518 19 rider 2024-01-23 21:23:13 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/openxray/specfiles/2982601312294120293#line-46 у cmake есть макросы в альте, их вполне должно хватать для сборки. почему не получилось ими воспользоваться в этом проекте ? 240519 20 rider 2024-01-23 21:26:22 +0300 Из этого спека вообще непонятно, откуда брались исходники и где настоящий homepage проекта. https://packages.altlinux.org/ru/sisyphus/srpms/kde5-kronometer/specfiles/2963381156396431418 вообще его, скорее всего, тоже неплохо бы собрать из git: https://invent.kde.org/utilities/kronometer 240520 21 rider 2024-01-23 21:28:21 +0300 grub-btrfs отлично приведён в порядок, вопросов нет. 240521 22 rider 2024-01-23 21:31:54 +0300 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 и из-за её отсутствия, возможно, какой то функционал пакета не работает. 240522 23 rider 2024-01-23 21:36:25 +0300 https://packages.altlinux.org/ru/sisyphus/srpms/cpu-checker/specfiles/2958034891713744966#line-29 в секции files лучше включать man страницы как %_man1dir/check-bios-nx.1.*, т.к. алгоритм сжатия может быть изменён без участия ментейнера. Остальное вопросов не вызвало, за исключением того, что собран какой-то очень древний проект, ну и репология показывает что в других дистрибутивах есть версия 0.7 240922 24 kurachenko.urup 2024-01-30 21:28:04 +0300 (Ответ для 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-сервиса, соглашусь, что лучше действительно оставить его включение на усмотрение конечного пользователя. Эту часть я удалил из спека. К тому же оно, честно говоря, не работало так, как задумывалось изначально. 240935 25 rider 2024-01-31 09:53:57 +0300 А что за тарболл с common файлами лежит в .gear в запакованном виде размеров в 400 мегабайт ? Это ошибка, так не надо делать. Я не заметил этого при предыдущем просмотре пакета. Запакованный тарболл при любом изменении будет есть заметно больше места в гите, чем его содержимое в распакованном виде. 240936 26 rider 2024-01-31 09:55:01 +0300 Удаление драйверов post скриптах я по прежнему считаю ошибкой, тем более в таком виде. Лучше этот код вообще убрать и вывести сообщение о том, что после установки пакета требуется перезагрузка. 241113 27 kurachenko.urup 2024-02-04 20:55:50 +0300 (Ответ для Anton Farygin на комментарий #25) > А что за тарболл с common файлами лежит в .gear в запакованном виде размеров > в 400 мегабайт ? Nuget-packages необходимые для сборки. > Запакованный тарболл при любом изменении будет есть заметно больше места в > гите, чем его содержимое в распакованном виде. Не подумал об этом. Спасибо. 241114 28 kurachenko.urup 2024-02-04 20:58:21 +0300 (Ответ для Anton Farygin на комментарий #26) > Удаление драйверов post скриптах я по прежнему считаю ошибкой, тем более в > таком виде. Лучше этот код вообще убрать и вывести сообщение о том, что > после установки пакета требуется перезагрузка. Хорошо. Переделал. https://git.altlinux.org/tasks/339328/ 241115 29 kurachenko.urup 2024-02-04 21:01:19 +0300 (Ответ для 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/ 241143 30 rider 2024-02-05 08:59:26 +0300 Теперь то, что в этом тарболле лежат не исходники а куча бинарных блобов, неизвестно кем собранных, а часто собранных ещё и не для нашей системы - стало видно невооружённым взглядом. Надо или научить вендорить и собирать исходники, или по максимуму научиться собирать с внешними библиотеками. 241173 31 kurachenko.urup 2024-02-05 20:11:22 +0300 (Ответ для Anton Farygin на комментарий #30) > Теперь то, что в этом тарболле лежат не исходники а куча бинарных блобов, > неизвестно кем собранных, а часто собранных ещё и не для нашей системы - > стало видно невооружённым взглядом. > > Надо или научить вендорить и собирать исходники, или по максимуму научиться > собирать с внешними библиотеками. У меня нету больше идей, как это собрать. Если и в таком виде пакет не подходит для отправки, предлагаю удалить его и забыть. 241187 32 rider 2024-02-06 07:41:02 +0300 В таком случае лучше удалить и забыть. 241214 33 kurachenko.urup 2024-02-06 17:16:25 +0300 (Ответ для Anton Farygin на комментарий #32) > В таком случае лучше удалить и забыть. https://git.altlinux.org/tasks/339941 241259 34 kurachenko.urup 2024-02-07 19:20:48 +0300 (Ответ для 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/ 241271 35 rider 2024-02-08 08:55:56 +0300 (Ответ для 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 репозиторий апстрима. 241425 36 kurachenko.urup 2024-02-11 22:13:46 +0300 (Ответ для Anton Farygin на комментарий #35) > Тэг VCS ещё добавьте, пожалуйста: > VCS: https://invent.kde.org/utilities/kronometer.git > > В него очень удобно помещать ссылку на git репозиторий апстрима. Fixed https://git.altlinux.org/tasks/340031/ 241426 37 kurachenko.urup 2024-02-11 22:19:33 +0300 (Ответ для Anton Farygin на комментарий #19) > https://packages.altlinux.org/ru/sisyphus/srpms/openxray/specfiles/ > 2982601312294120293#line-46 > > у cmake есть макросы в альте, их вполне должно хватать для сборки. > почему не получилось ими воспользоваться в этом проекте ? Можно и с макросами. Заодно обновил версию.https://git.altlinux.org/tasks/340403/ 241427 38 kurachenko.urup 2024-02-11 22:22:13 +0300 (Ответ для 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/ 241437 39 rider 2024-02-12 08:46:05 +0300 (Ответ для Anton Kurachenko на комментарий #36) > (Ответ для Anton Farygin на комментарий #35) > > Тэг VCS ещё добавьте, пожалуйста: > > VCS: https://invent.kde.org/utilities/kronometer.git > > > > В него очень удобно помещать ссылку на git репозиторий апстрима. > > Fixed https://git.altlinux.org/tasks/340031/ Спасибо. 241438 40 rider 2024-02-12 08:48:30 +0300 (Ответ для 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/ Неплохо получилось, спасибо. 241439 41 rider 2024-02-12 08:53:08 +0300 (Ответ для 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 ? Спросите, пожалуйста, у ментора - может быть есть какие-то другие варианты определить ограничения среды ? 241441 42 kurachenko.urup 2024-02-12 09:24:23 +0300 (Ответ для 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, то это никак не скажется на работе пакета. 241446 43 grenka 2024-02-12 09:41:46 +0300 Ментору категорически не нравится коммит: https://git.altlinux.org/tasks/340425/gears/100/git?p=git;a=commitdiff;h=dd790c120ece82c81080eb703f70fb91a714841e Здесь приезжают исходники openrazer 3.7.0, а что будет, когда openrazer обновится? Я бы подумал об упаковке чего-то вроде openrazer-tests и чтобы в polychromatic оно подтягивалось по buildrequires. 241447 44 grenka 2024-02-12 09:45:26 +0300 (Ответ для Anton Farygin на комментарий #41) > А не допускаете ситуации, когда пользователь решит себя назвать builder ? Такой пользователь сам себе злобный буратино. Мы не можем ограничить всех желающих выстрелить себе в ногу=) 241470 45 arseny 2024-02-12 12:16:39 +0300 (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. 241471 46 arseny 2024-02-12 12:18:28 +0300 (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 241519 47 kurachenko.urup 2024-02-12 17:55:02 +0300 (Ответ для 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. Понял. Буду паковать. 241709 48 kurachenko.urup 2024-02-16 09:37:51 +0300 (Ответ для 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/ 241767 49 rider 2024-02-18 18:32:12 +0300 (Ответ для 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 нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие тарболла необходимо. 241768 50 kurachenko.urup 2024-02-18 19:57:24 +0300 (Ответ для Anton Farygin на комментарий #49) > И ещё заметил - сжимать тарболл: > https://git.altlinux.org/tasks/340770/gears/200/git?p=git;a=blob;f=.gear/ > rules;h=74e7988dc66ee0d4f62ea7c7cf6fb53e9cea9f4b; > hb=ce0d18b75b6a591c2e863e514381d83c3681a630 > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > тарболла необходимо. Где можно узнать об этом подробнее? 241780 51 grenka 2024-02-19 09:52:25 +0300 (Ответ для 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. 241792 52 kurachenko.urup 2024-02-19 11:44:01 +0300 (Ответ для 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/ 241793 53 kurachenko.urup 2024-02-19 12:14:06 +0300 Также, внес небольшие коррективы в kde5-kcm-wacomtablet https://git.altlinux.org/tasks/339717/ 241805 54 rider 2024-02-19 18:32:14 +0300 (Ответ для Grigory Ustinov на комментарий #51) > (Ответ для Anton Kurachenko на комментарий #50) > > (Ответ для Anton Farygin на комментарий #49) > > > нужно в крайне редких случаях и ваш случай явно не похож на те, когда сжатие > > > тарболла необходимо. > > > > Где можно узнать об этом подробнее? > > Вопрос хороший! > > Ну вообще сжатие было актуально раньше, когда информационные накопители > стоили дорого, а торопиться было некуда. Сейчас приоритет поменялся и нам > важнее разгрузить сборочные узлы и не забивать их ненужными действиями. > Понятное дело, что это не критичная ошибка, но по возможности, лучше делать > просто tar. Всё ещё проще - наш rpm жмёт сам неплохим алгоритмом и смысла от двойного пережатия не много. 241806 55 rider 2024-02-19 18:35:14 +0300 (Ответ для 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) 241807 56 rider 2024-02-19 18:38:11 +0300 (Ответ для 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'ом, но в целом это считается плохой практикой. Лучше сделать обычный патч. 241809 57 kurachenko.urup 2024-02-19 19:50:03 +0300 (Ответ для 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 241810 58 rider 2024-02-19 19:52:54 +0300 Заапрувил, можно запускать. 241819 59 kurachenko.urup 2024-02-20 08:49:09 +0300 (Ответ для Anton Farygin на комментарий #58) > Заапрувил, можно запускать. Спасибо! 241820 60 kurachenko.urup 2024-02-20 08:50:19 +0300 (Ответ для 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 241827 61 rider 2024-02-20 10:40:23 +0300 (Ответ для Anton Kurachenko на комментарий #60) > Ок. Переделал с использованием патч-файла [#339717] TESTED (try 4) > kde5-kcm-wacomtablet.git=3.2.0-alt2 Спасибо. Заапрувил, можно коммитить. 241962 62 kurachenko.urup 2024-02-22 18:07:35 +0300 (Ответ для 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/ 241989 63 rider 2024-02-23 12:05:28 +0300 Не стало сильно лучше. +# fix plugdev validation +sed -i '192 s/\(.*\)'\''root'\''\(.*\)/\1'\''builder'\''\2/' daemon/%{name}_daemon/daemon.py 1) редактирование sed'ом исходников в секции check не даёт возможности отлаживать запуск и сборку через rpmbuild --short-circuit 2) принципиально ничего не изменилось - пользователь имеет право собрать пакет в обычной системе без hasher и сборка в такой системе работать не будет. 242009 64 kurachenko.urup 2024-02-23 18:35:44 +0300 (Ответ для 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 242014 65 rider 2024-02-23 23:10:52 +0300 Мне, как и Арсению - не нравится этот вариант. Я бы сделал ещё проще - добавил проверку переменной окружения (имя надо придумать такое, что бы нормальному человеку в голову не пришло его использовать в своей системе). а в секции check сделал бы экспорт этой переменной. Ну, например SKIP_PLUGDEV_GROUP_FOR_TESTS=1 242016 66 grenka 2024-02-24 01:33:09 +0300 (Ответ для Anton Farygin на комментарий #65) > что бы нормальному человеку в голову не пришло его > использовать в своей системе). Нормальному человеку в голову и не придёт назвать себя builder:) 242034 67 kurachenko.urup 2024-02-24 12:21:05 +0300 (Ответ для 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 242053 68 rider 2024-02-24 23:28:59 +0300 (Ответ для Grigory Ustinov на комментарий #66) > (Ответ для Anton Farygin на комментарий #65) > > что бы нормальному человеку в голову не пришло его > > использовать в своей системе). > > Нормальному человеку в голову и не придёт назвать себя builder:) А что ты имеешь против строителей ? 242255 69 kurachenko.urup 2024-02-28 08:45:10 +0300 Внес небольшие косметические изменения:[#341223] TESTED (try 6) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2 242258 70 rider 2024-02-28 09:05:32 +0300 (Ответ для 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. 242455 71 kurachenko.urup 2024-03-02 16:54:09 +0300 (Ответ для Anton Farygin на комментарий #70) > Но намного лучше в процессе тестирования не использовать отдельно > упакованные исходники в /usr/src, а проверять работу polychromatic с > установленными в систему пакетами openrazer - питоновским модулем и сервисом. > > так вы заодно проверите качество упаковки и интеграции в систему openrazer. Получилось вот так [#341223] TESTED (try 9) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2 242461 72 kurachenko.urup 2024-03-02 19:51:59 +0300 Более правильный вариант: [#341223] TESTED (try 11) openrazer.git=3.7.0-alt2 polychromatic.git=0.8.3-alt2 242485 73 rider 2024-03-03 10:53:42 +0300 (Ответ для Anton Kurachenko на комментарий #72) > Более правильный вариант: [#341223] TESTED (try 11) openrazer.git=3.7.0-alt2 > polychromatic.git=0.8.3-alt2 Спасибо. Теперь выглядит нормально. Выдал аппрув, закоммитите пожалуйста в репозиторий. 242487 74 kurachenko.urup 2024-03-03 11:26:21 +0300 (Ответ для 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 242587 75 kurachenko.urup 2024-03-05 18:21:27 +0300 Обновление для puddletag [#342094] TESTED (try 2) puddletag.git=2.3.0-alt1 242604 76 rider 2024-03-05 19:54:34 +0300 (Ответ для 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 242606 77 kurachenko.urup 2024-03-05 20:16:37 +0300 (Ответ для 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 Спасибо. Попробую перевести. 242611 78 grenka 2024-03-05 23:49:31 +0300 (Ответ для 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 > > Спасибо. Попробую перевести. Я категорически против изучения моим подопечным этого метода сборки. Изучение больных фантазий одного человека не является обязательным для вступления в тим. Популярность этот метод набирает только в одном городе. Пусть он там и остаётся. 242613 79 grenka 2024-03-05 23:57:09 +0300 (Ответ для 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 > > > > Спасибо. Попробую перевести. Давайте будем учить кандидатов проверенными и одобренными сообществом схемами сборки? Предложенный выше механизм не был принят и даже не был широко обсуждён. Попытки протолкнуть его через массовое насильное приучение кандидатов крайне неэтичны. 242617 80 rider 2024-03-06 08:38:03 +0300 398 пакетов на данный момент в репозитории используют эту схему сборки (почти 20% от всех python пакетов) и их количество растёт. Кандидату придётся с ней столкнуться при сборке python пакетов и других вариантов не будет. Если есть конкретные замечания к этой схеме формирования списка сборочных зависимостей, то их надо опубликовать и обсудить в devel. 242637 81 grenka 2024-03-06 11:37:18 +0300 (Ответ для Anton Farygin на комментарий #80) > 398 пакетов на данный момент в репозитории используют эту схему сборки > (почти 20% от всех python пакетов) и их количество растёт. Кандидату > придётся с ней столкнуться при сборке python пакетов и других вариантов не > будет. > > Если есть конкретные замечания к этой схеме формирования списка сборочных > зависимостей, то их надо опубликовать и обсудить в devel. Именно такого подхода я и опасаюсь. Агрессивное замещение. Их было бы намного меньше, если бы некоторые менторы и рецензенты не включали её в обязательный курс джойна. Почти 20% - это выглядит уже как порог. Я не против, чтобы "разработчик схемы" использовал её в своих пакетах, но обучать и принуждать к этому остальных считаю неправильным. В ближайшее время подготовлю письмо для обсуждения в сообществе, а пока что предлагаю избегать провокаций и сосредоточиться на изучении кандидатом общепринятых схем. 242642 82 rider 2024-03-06 12:09:15 +0300 Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её применить я проанализировал статистику её использования, и если бы она не была такой как есть - от меня такой просьбы явно бы не последовало. Поэтому так же прошу посмотреть и попробовать применить новую схему работы с зависимостями в python пакетах, уж коль она стала такой распространённой. 242643 83 rider 2024-03-06 12:12:01 +0300 ну и второе - как мне кажется ментор не должен навязывать своё личное предубеждение против тех или иных способов упаковки. Его задача - научить разным вариантам и схемам, объяснить отличия, преимущества и недостатки каждой из них. Дать и проверить знания. Ровно этим я в данной задаче и занимаюсь. 242646 84 grenka 2024-03-06 12:56:07 +0300 (Ответ для Anton Farygin на комментарий #83) > ну и второе - как мне кажется ментор не должен навязывать своё личное > предубеждение против тех или иных способов упаковки. Его задача - научить > разным вариантам и схемам, объяснить отличия, преимущества и недостатки > каждой из них. Дать и проверить знания. > > Ровно этим я в данной задаче и занимаюсь. Именно этим и должен заниматься ментор: показывать правильные подходы и исправлять ошибочные. В частности, некоторое время назад благодаря некоторым людям, я уж честно и не могу показать пальцем с кого, обрела популярность схема сборки, где сборка идёт из тэга, который мерджится по стратегии ours и фактически в основной ветке отсутствуют исходники, есть только спек, рульс и патчи. Это было модно, но потом большая часть мейнтейнеров осознала всю неудобность прыганья по веткам во время отладки сборки и от этой схемы пришлось отказаться. Я в свою очередь когда-то продвигал идеи спексабст схемы, в которой из шаблона генерировались одновременно 2, а то и 4 пакета для разных питонов. Ещё один пример неудачной и неудобной схемы, она до сих пор используется в некоторых пакетах не связанных с питоном, где её использование оправдано, но благодаря отказу от второго питона в массовое использование она слава богу не пошла. Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов кандидат и сам может нахвататься:) 242651 85 ancieg 2024-03-06 15:24:16 +0300 (In reply to Grigory Ustinov from comment #84) > Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов > кандидат и сам может нахвататься:) Раз уж пошло на то дело, то может тогда объясните чем плох подход к сборке Python-пакетов с альтернативным способом управления источниками завимостей? (In reply to Grigory Ustinov from comment #81) > Именно такого подхода я и опасаюсь. Агрессивное замещение. Их было бы > намного меньше, если бы некоторые менторы и рецензенты не включали её в > обязательный курс джойна. Почти 20% - это выглядит уже как порог. Я не > против, чтобы "разработчик схемы" использовал её в своих пакетах, но обучать > и принуждать к этому остальных считаю неправильным. Вы говорите неправду. Эту схему никто насильно не проталкивает и агрессивным замещением предыдущих ("общепринятых") не занимается. > В ближайшее время подготовлю письмо для обсуждения в сообществе, а пока > что предлагаю избегать провокаций и сосредоточиться на изучении кандидатом > общепринятых схем. Отлично, ждем письмо. Надеюсь, там аргументы какие-нибудь появятся. 242663 86 rider 2024-03-06 18:15:47 +0300 (Ответ для Grigory Ustinov на комментарий #84) > > Я считаю, что ментор должен учить "хорошим вещам", а плохих подходов > кандидат и сам может нахвататься:) Да конечно, но лично у меня нет серьёзных предубеждений против новой схемы сборки с автогенерацией зависимостей. Там немного хромает юзабилити, которое надо доработать. Но на низком уровне она (после того, как понять схему работы) - отлично справляется. 242713 87 kurachenko.urup 2024-03-07 16:33:07 +0300 (Ответ для Anton Farygin на комментарий #82) > Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её > применить я проанализировал статистику её использования, и если бы она не > была такой как есть - от меня такой просьбы явно бы не последовало. > > Поэтому так же прошу посмотреть и попробовать применить новую схему работы с > зависимостями в python пакетах, уж коль она стала такой распространённой. [#342094] TESTED (try 5) puddletag.git=2.3.0-alt1 242715 88 rider 2024-03-07 16:38:44 +0300 (Ответ для Anton Kurachenko на комментарий #87) > (Ответ для Anton Farygin на комментарий #82) > > Конечно, прежде чем просить посмотреть на эту новую схему и попробовать её > > применить я проанализировал статистику её использования, и если бы она не > > была такой как есть - от меня такой просьбы явно бы не последовало. > > > > Поэтому так же прошу посмотреть и попробовать применить новую схему работы с > > зависимостями в python пакетах, уж коль она стала такой распространённой. > > [#342094] TESTED (try 5) puddletag.git=2.3.0-alt1 Выглядит круто, спасибо. Заапрувил. Свои впечатления про эту систему сборки, если не сложно, опишите пожалуйста в devel когда будет письмо от Гриши. В целом я считаю что кандидат освоил сборку пакетов, в целом уже понимает требования. Не видел сборку по SharedLibsPolicy, но думаю что он почитает и попросит поревьювить старших коллег. Так что он готов к самостоятельной работе. К кандидату просьба отправлять мне на ревью первое время (в личке) пакеты, что бы не допускать явных ошибок, при проблемах не стесняться консультироваться. Спасибо. 242716 89 kurachenko.urup 2024-03-07 16:59:59 +0300 (Ответ для Anton Farygin на комментарий #88) > Выглядит круто, спасибо. Заапрувил. Благодарю. > Свои впечатления про эту систему сборки, если не сложно, опишите пожалуйста > в devel когда будет письмо от Гриши. Ок. > К кандидату просьба отправлять мне на ревью первое время (в личке) пакеты, > что бы не допускать явных ошибок, при проблемах не стесняться > консультироваться. Хорошо. Спасибо большое! 243539 90 glebfm 2024-03-26 22:04:50 +0300 Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 243555 91 kurachenko.urup 2024-03-26 22:44:03 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #90) > Пользователь добавлен в группу мейнтейнеров. > > Желаю удачного мейнтейнерства! Спасибо! Это был долгий путь, но я реально многому научился. Хочу выразить свою благодарность всем, кто учавствовал в моем процессе JOIN'а! 13173 2023-05-13 16:55:22 +0300 2023-05-13 16:55:22 +0300 GPGkey file_46137.txt text/plain 3129 kurachenko.urup LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tDQoNCm1RSU5CR1JmZzE4QkVBREpu ZVlza1J3ViswczVxL2RyZUJNU3pPUjE0U3RVUzU0WFh1SU9mQjU1S0g4b1VXdHANCjhXcEtsSVVm a0VESEgwTlFYbHNBVloxWVVydmsxd21hcDQ3MTlrMmZGazRyNnE0bzdhbWpLNVFMemRqbW95TUwN CnVpejdOK1c2d2pDaW1LUnVMYWFrYXFCU0QveWYvbEdrNWJFTEhZbmtvUWRTdkROM285Sjc0ZVpC OE5uN3FhY0sNCldRenRxRXBvN1RxNGNqWTd5ZlUxTVlMV01KK3QvRjlDbXF6UDBuQWNxR1FvOUFD UnY2bUo5MkVsRGFzTW5xdVgNClhQL2VUQVlvN3BUYmpsZXc0OUtnZEJEVHVqaFRPWUE2ekUwYmox WDhoUVBzMlVaM1V4anFrTU0wZHdHVy9GdWYNCkhaeUJqV3ljdWFaWXVvUzJmeHJyYU5DeEk0dWtk Y2tEVVJTa2Z4S01qMCtKTUVWcDNBcURiS0RzRHVrd01zb1oNCmlOQVBuUFI1VFpwaFpyV0JIU2ZC Z1VNaGhrdy9TdDRMbEU1RTNWakdJYTBXL2w4VzVPZTNoNnVGcjB3UGZURVQNCndqZFZadXErZHJ3 dVExUllFRCtFcUsxcFFmc3NoTnNpVUxscHdCck9tV1ZYZkhXUmN6dG9XaFlBS05aMjhoZm8NCktz S0JsZGVjcFp0eG1VQ1BUTjBWelFaSFduQy9uKzhmYTJla1hGZFl6UGRUb1U3M1BGdmNyWVdlc3JO S1pHeVANCnpCT1d1UmxhRld5RG1tcDFCejl4ekZwS2YxTEwrUWEycXJIcmZ5elROQjhsSUZRbTZs NC9NQ3NRUW5FUWw3U3gNCmtPM1o1SGtMdHdKaVJOcy9sZE5yVGxKK2trWWJUOTRBZWcrQWc3V0tO UWl2MWxEVUQwYlB2Q3VET1FBUkFRQUINCnRDZEJiblJ2YmlCTGRYSmhZMmhsYm10dklEeHpjbVZp Y205MlFHRnNkR3hwYm5WNExtOXlaejZKQWpnRUV3RUkNCkFDSUZBbVJmZzE4Q0d3TUdDd2tJQndN Q0JoVUlBZ2tLQ3dRV0FnTUJBaDRCQWhlQUFBb0pFT2Q5RVQvR0xubjgNCkZLZ1FBSUNoUmlPWE4w RFNuZmNmL1FwWjBaYVBuY2hINXg1Y00yK0ZwK0NQVjg1Ti92Z2FDUm5EV1ZGOG9UaDYNClNYZVNM c0Y5bnJJMVBsQkIwQitEUng0NllBbUFKNGkzWlZoczVsUFBiQ0Y2Ukp1UzYyUkU1WGt2RU1nZmlo cjcNCk9kQzNDdE1DZml2bWo3UDcyYkZnSDNBR0FnbWM0TUNkUzVJV0luNGdxT216SEJkUkhxMDAw aEFLdWs0Zlp2UnMNCllXU05ITVhoQlNWeWwrUXBQTkxmTk9TaWhvN0JsenpoSkdQck4xY3RqZTZo VGRzVjRBL2Y0Y01RN1dOZHg3U1INClV6RDEyQXUzU3NvemFRbVF2Rm8zdWNqUk82ZzErUzNIMjA0 MFhxVDB3ZmVCNHg5TXRhMlRiN1drWFdFNXVHckkNCjFJY1lSQkRCYitMejJaMHY2bjVUVHVDYUNx Z25Mb0YzaGFXczdIejFtN3VXaFdUYUJOVEdPNUpEUmhIOHptYzYNCllSWlNQRlh0b0k4OHNZTTBC d1JKMm9FR2c3VHljTzByOTlZMmQ4TnR1cjNWb0RNMVp0N1gyK09USjBlWjQ2dW0NClo2UFBYZDMz dGVIL3RWOWN0QXRQa3NqS0JiN3liOXVySjNrbUVDeElpdUNWUFRQdUFFdTE1ZFBSeWdKQm1vaG4N ClRYNDdpbG5GYUZSVDhXQTE1azJSSjZCTTdRRXpFVlpjOFEwQ3dLU0J5OU1wanZKS29kaSthU3Zy OGxJNEREZ3INCmdqSEdaNFZ4b0JxZG5idTUrMDRaa0pmSVB1NmVTRE9zSXQzM0RkVEdvMno4b3pT RFZmT09rN0pGbTB3MVV1L2YNCkQ4RDF1cnNvd0dSR1VWMTBzbDBqbmlTVnh0N0FIaGtPWE85aTh6 amNScERidXZkZnVRSU5CR1JmZzE4QkVBRE4NCmJGYkpZYnRLUTdVd0ZaaUJ2OGxGak1ScTFrK0ZE elRmdWQranZHMnJ5dko1dXBEM25ZZ1B5cmJWQ0hXWmNiYUkNCjNEOFRmUlVTTG8vZTNybmFhVXpR L1djdnRBTnk4RVMvS0s5MC9RNFZYZjhscjNNK2dsR0JreHVkbTdwWTREQVANCmxrNy9nbHB1dTFN eHRQNFZRWi9WNVc5Ulc5K0hzQTdEWU03KzZLZml6dmJqbHZZWjhuc2t1bHhlR2FYR0pEeVkNCkVM Qy9pVStpWjJMQ3BpeDhQVllnMmVEWG9EcTJMbmExUUJ3aWJFdTBpZ2dzNWY2bm5zanhhK1JvcW5j RUIzMGMNCkR6SmdkdEptcUd5VlZDOStvY2NCaFczQmE2Q2FBcENaN2YvZ1JmbENhVTlHV0RIS0h5 RDEyQnBvbExEdXhYeTcNCkJRRFdwZVBUbit0NTVZRllsZWxoaDZlcUV5UDh4RWI0WVEvOS9EOGE3 OXRMODEvcmY5OVVvS0l3cnBJL2NkWHgNCk1RNFM0cGJyRWZCbUlid0lxTmhUTWM2ZE4wK29LSlpD WC9jNmNRSUFRcGtZZ0w2dE1tVDZwaThOdEdaTklJVFoNCjhPVTN1N2F6dVNQRkcrNldWdDJKUkRD bkZKc3h5UTFZV2xmWmtKaGQ0NC9SR2ZpYzBYeUdlcm1QSzY1NnNJWUUNCmExYjNQRms5bDFpZmpl RHErVlR6NkdwMStzd21YZ2F6Tmh3MUFkejdRTzgyRDRJekF1YlRCaUNrVmtWakd4S1ANCkdpZEFt d1NGcUUzNDV0dGpwVk1wQVdZQlJpcGlNeTkyM2JjaFJaa1IyTE5PQ2UvS25yTm9WcmNvMFA2aFRh MmgNCnlBUkhaUVVtaXdROGk5MlRMQlh2QzJRYVR2Yy9OM0ZSTUNFcklVMGNhd0FSQVFBQmlRSWZC QmdCQ0FBSkJRSmsNClg0TmZBaHNNQUFvSkVPZDlFVC9HTG5uOHZNZ1AvamRsbEJ6WldTeUtmQnhu L3NyaGtsdUo3dkpxZDVDWjZWZmgNClMxbTZjZUlBdHR2cTZWT1pBQUp6UmtWa05qVE5lVmF4V3Ux a1Q0U0lyQjVnYU1xRUNVYVVvbmlyeXMyMmRqM3YNCkV3VmxGUHY3LzVVaVl0TllWRDNqNWE3dFNC eGFJcS84cTNqVnBSb1I5S1gzd1k0ZlNsWVNNbkg2QjA0TGRrak4NCllER1NYTDA4RUtVaG9wL3Z2 N3BJNCtWdk51bk1LbGdRdjl6VXBBeGdpK1BxczRkVndZcHdhMit1WUJVL0xGaWMNCnFxUy9Wd04v YmRFQkh3bWF5N0g0Wkpqem1jS2xYaDVKNlFDZWJMUmY2NzI4NWtrMFFua0dvcTFTZlBkZ2dPSzgN ClVvdTNEaGE0NlNFYkFMbGNuaVZaRTBRbytwbmptYkRqZUxVZjAxSDhjWVRMc3FJeFh3bzZ0MVR2 SXJCNXJoenUNClhGM3FTeXV2aWZwaEJiZ3pJbDJIT0hhQ2tBTHdzcWNNNE5USVVDak5yQWhoS2Vz QnlTZnZjRWkwSzhUSzY5eXQNCjhJcnhxZzI0VzBkSmYyK2VmNkM5VVBoSkRyMER5NnN3NVBVWml1 TU9XT1A1dlpNNDh0amRmWmJDVnk3dU56cDANCmpqRFRhMmFxZGRzTXdWRHh2dzJPclliU0RPQzda ZGZDZTBLUjJhUzZhRDdIUzZjeHZXSWxLNzk3bXlqelphcEUNCldtKzdNUmpFVG5uc0MydGVhblNR aC83NjV6TUx0OGlOVi9qS25zNUZ1cG5PRjlQVlF0T2ZRNERkSG1idkEzam0NCklyVmpMcHd2QTF0 UVpEMGE1Q0N5NTVFVDVBLzJRQWx0QVkvc0lIUVdMSXpLaXdqaVRXZVkySDVOaHFmMnlUekMNCmZB aE81N3BPDQo9ZnFReA0KLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxPQ0stLS0tLQ0K 13174 2023-05-13 16:56:10 +0300 2023-05-13 16:56:10 +0300 SSHkey id_rsa.pub application/vnd.ms-publisher 743 kurachenko.urup c3NoLXJzYSBBQUFBQjNOemFDMXljMkVBQUFBREFRQUJBQUFDQVFEV3RIR0Z6QkpXMWdTZkxCdkts ejlySDdqMWdjUE10TU8zWEcvdkQ5VUc1T3BmZmRVRVlCSHoweDFXU0crUUsvUUlmZi9QY0FCQ3hl dUk0SGRwSngxWGFPZExrRWE4RTU0NE1wRXR0bW5xME43MWU3K1dXdXFRQ0xPekpVZ1hOYWRMSzQw OURUT1E5V1hMZnQzTDVCRUhodTVncVVqWHpUTXlZK3pyaXpzVm0vWkd4MkxtME1vTnhyQS9vakVi aThMNFFCVGNYaDlaeGJJQm8zd3ZES3BWSnVNMHFzeXhNd0FzQWh5L09xOVJ2V3pzKzZhQVUxVWJ6 aVY3SUZWaFJhcTZGNTYybWNvbEFHelVlSkNiZmhrL1NNSzJiK3BpVEh2TXg5OUo2cHNaeklwRnZU RzVEWkhKblE3cUY5L3pZc1Vhd1I0TlNEK0llUUd3aE0xZjkxZEQvdGhVR09RcDZldUZyL0RDa2dK R1M2S0RjZkpIQTFtNjFZTXFDblNsSkthWlJ0YSttZkhYQThlRVhaalkwbnVOQXVIT1lOdjErRzJG bVY5S2NRd2JKR0lsUGY1c3pnMzcxVTRoekd0RnJoT3gwOW1Qck1ZQ2tZMWFLZE5kTTlrejdjMVBm REZsWFc1cTBHL2cyVnZPckxyRlNUUGNkSHhTZkVBUkZWRGxJN3JLRG1DSlFzRWZpc2JvUGxzRklX czVrbkgyMURMSWUyK0VsdjN6YVVrZTZqNG9mRVRjRU9VZmdhWkcvY2tMNjRwdGRjWkJOdWN0TEtB SlJEVE9XdExid0JlS1oxSEoxU0dNK1d0ZmI5ZDgxczlNeHVlTTBjY05Ed0NBaU9RQW8rUDJqRnY1 c0JSRkJyKzhvZFpDaER0NWY1ZW9hVEtWNmdYR3JDNmFwL0dhU3c9PSBhbnRvbkBub3RlYm9vay1n Ngo=