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'а!