39613 2021-01-27 12:12:14 +0300 [5.0] join neurofreak@ 2021-07-11 10:31:35 +0300 1 1 4 Development Team Accounts join unspecified all Linux CLOSED FIXED P3 normal --- 1 neurofreak-alt glebfm antohami bircoph glebfm grenka ldv m mike cas oldest_to_newest 195772 0 neurofreak-alt 2021-01-27 12:12:14 +0300 Псевдоним участника: neurofreak Адрес почты: neurofreak-alt@yandex.ru Имя ментора: Mikhail Novosyolov <mikhailnov@altlinux.org> Цель: Освоить git.alt на примере сборки пакета bookworm, есть мысли по сборке других пакетов. 195773 1 9159 neurofreak-alt 2021-01-27 12:15:49 +0300 Created attachment 9159 Публичная часть SSH-ключа 195774 2 9160 neurofreak-alt 2021-01-27 12:16:40 +0300 Created attachment 9160 Публичная часть GPG-ключа 195775 3 m 2021-01-27 12:21:30 +0300 Ментор подтверждает менторство 195776 4 m 2021-01-27 12:29:38 +0300 Там есть готовый к отправке в сизиф пакет, можно сразу права на сборку в сборочнице дать, т.к. кандидат умеет собирать локально, теперь нужно в сборочнице. 195906 5 glebfm 2021-02-01 14:40:45 +0300 (Ответ для mikhailnov на комментарий #3) > Ментор подтверждает менторство (Ответ для neurofreak-alt@yandex.ru на комментарий #1) > Создано вложение 9159 [подробности] > Публичная часть SSH-ключа (Ответ для neurofreak-alt@yandex.ru на комментарий #2) > Создано вложение 9160 [подробности] > Публичная часть GPG-ключа Ok. 195912 6 m 2021-02-01 15:13:11 +0300 А 1.2 означает какой пункт из https://www.altlinux.org/Team/Join/Secretary ? 195931 7 glebfm 2021-02-01 18:43:31 +0300 (Ответ для mikhailnov на комментарий #6) > А 1.2 означает какой пункт из https://www.altlinux.org/Team/Join/Secretary ? Было бы странно, если бы 1.2 значило какой-то другой пункт кроме 1.2. 195934 8 m 2021-02-01 18:48:33 +0300 > Ожидать решения ментора о готовности кандидата. Кандидат готов к тестовым сборкам в сборочнице без прав коммита в сизиф, о чем писал выше, поэтому уточнил. 195936 9 glebfm 2021-02-01 19:14:02 +0300 ssh ключ на gitery.alt зарегистрирован. ssh ключ на gyle.alt зарегистрирован. Адрес для пересылки создан. T/J/S -> 2.4. 195938 10 neurofreak-alt 2021-02-02 06:46:42 +0300 (Ответ для Gleb F-Malinovskiy на комментарий #9) > ssh ключ на gitery.alt зарегистрирован. > ssh ключ на gyle.alt зарегистрирован. > Адрес для пересылки создан. > > T/J/S -> 2.4. Благодарю. 196582 11 m 2021-02-28 11:02:05 +0300 Кандидат подготовил пакет,подписал тег, прошу перевести на следующий этапи добавить GPG-ключ в сборочницу. 196705 12 mike 2021-03-04 20:41:34 +0300 Гриш, можешь глянуть с прищуром на предмет .gear/rules? http://git.altlinux.org/people/neurofreak/packages/bookworm.git http://git.altlinux.org/people/neurofreak/packages/minigalaxy.git Евгений, по http://git.altlinux.org/people/neurofreak/packages/minigalaxy.git?p=minigalaxy.git;a=commitdiff;h=adad54a387b5f55dc1e36d66d2d94455ca6c940e отмечу, что сам стараюсь создание/правки .gear/rules коммитить отдельно, чтобы не усложнять cherry-pick при необходимости впоследствии; исключение -- когда обрисовал создание патча или копирование исходника и в правилах, и в спеке (но не меняя в спеке что-либо ещё, особенно Version/Release -- опять же ради cherry-pick'ов, мало ли, понадобится что). В целом в minigalaxy.spec я бы какие-то строчки поменял местами или чуть иначе написал, но это по большей части вкусовщина уже. Мне тоже кажется, что можно переходить к п. 3. 196709 13 neurofreak-alt 2021-03-05 03:56:05 +0300 > Евгений, по > http://git.altlinux.org/people/neurofreak/packages/minigalaxy. > git?p=minigalaxy.git;a=commitdiff;h=adad54a387b5f55dc1e36d66d2d94455ca6c940e > отмечу, что сам стараюсь создание/правки .gear/rules коммитить отдельно, > чтобы не усложнять cherry-pick при необходимости впоследствии; исключение -- > когда обрисовал создание патча или копирование исходника и в правилах, и в > спеке (но не меняя в спеке что-либо ещё, особенно Version/Release -- опять > же ради cherry-pick'ов, мало ли, понадобится что). Спасибо, Миш, учту на будущее. Правда по поводу сборки minigalaxy сомнения - надо ли такое в репозиторий? Склоняюсь к мысли, что оставлю это у себя в packages/... Авось кому пригодится. Будем считать это тренировкой оформления git-репозитория в alt.git ;) 196723 14 glebfm 2021-03-05 14:06:09 +0300 Пакет alt-gpgkeys обновлён. T/J/S -> 3.4. 197190 15 m 2021-03-23 20:47:07 +0300 Кандидат на данный момент собрал уже 2 пакета, оба из которых уже не только в сизифе, но и в p9: 1) bookworm (https://packages.altlinux.org/ru/sisyphus/srpms/bookworm) 2) ksnip (https://packages.altlinux.org/ru/sisyphus/srpms/ksnip) Освоил сборку с применением gear, наследованием апстримного git, git cherry-pick необходимых изменений из апстрима и кумулятивным патчем. При работе над пакетами тщательно вникает в тему, старается глубоко изучить используемые механизмы. Хорошо относится к получаемым замечаниям. Кандидат изучил основы механизма компиляции и основы работы RPM, в т.ч. ознакомлен с особенностями правильного указания владельца каталогов и подкаталогов (%dir в ksnip) для предотвращения наличия ничейных каталогов, понимает назначения флагов компилятора -I и -L, основы работы компилятора и линковщика. Имеет хорошее представление о принципах организации работы в сообществе свободного программного обеспечения, готов конструктивно взаимодействовать с апстримами сопровождаемых пакетов и уже начал эту работу, пока в виде сообщение об ошибках, в будущем планирует самостоятельно делать патчи и доводить их до апстрима. Также понимает основы организации работы ALT Linux Team. Кандидату разъяснена необходимость тщательно следить за Provides собираемых им пакетов для предотвращения случайного разлома репозитория. Пакеты с разделяемыми библиотеками пока что не собирал, т.е. строго соблюдать политику упаковку библиотек еще не обучен, но при необходимости ознакомится с ней и обратится за помощью. ------ Считаю кандидата готовым к самостоятельному сопровождению пакетов и переходу к пп. 4-5. 197203 16 mike 2021-03-24 11:23:44 +0300 Собственно, пора в team; предлагаю переходить к п.5. 197204 17 neurofreak-alt 2021-03-24 11:36:08 +0300 Благодарю всех за оказанное доверие!) 197205 18 neurofreak-alt 2021-03-24 11:38:25 +0300 И спасибо за науку! 197289 19 ldv 2021-03-26 17:32:34 +0300 Попробую позвать ещё одного человека (bircoph@) для независимой оценки готовности кандидата. 197293 20 bircoph 2021-03-26 19:36:12 +0300 Посмотрел ksnip — там всё хорошо, работа аккуратная. Посмотрел bookworm — пришёл в ужас: # add python3 support fix sed -i 's|#!.*python2$|#!/usr/bin/python3|' $(grep -Rl '#!.*python2$' *) python2 там используется для работы с *.mobi форматом: data/scripts/mobi_lib/mobi_*.py И там заведомо есть конструкции, которые не будут работать в python3 без модификации, например, mobi_unpack.py:1089: print 'Unpacking Book...' В python3 это заведомо нерабочий код. По-видимому, автор не проверял ни работоспособность для формата mobi (что действительно не обязательно, т.к. сложно все форматы проверить), ни корректность работы питоновского кода, после добавленного им «исправления» для питона, что уже безответственно. Пока что не могу подтвердить готовность кандидата — это весьма грубая ошибка. Мало того, это безобразие попало в p9, что поднимает вопрос о качестве тестирования и проверки пакетов для p9. Евгений, пожалуйста, исправьте эту проблему надлежащим образом. У апстрима в гите уже есть поддержка python3 и если Вы туда посмотрите, там очень нетривиальные изменения: https://github.com/babluboy/bookworm/tree/master/data/scripts/mobi_lib https://github.com/babluboy/bookworm/commit/c7c3643760caea4bd26b1d56ed033a52f6e34124#diff-529fdbb170eb21629749b3e8ef4f58a151520b6b79be2295fc6f4dd759471682 197294 21 m 2021-03-26 21:34:33 +0300 А какой в Альте штатный способ произвести byte-компиляцию кода внутри /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в уведомительном порядке видеть в логе сборки? 197295 22 m 2021-03-26 21:39:50 +0300 (Ответ для Andrew Savchenko на комментарий #20) > > По-видимому, автор не проверял ни работоспособность для формата mobi (что > действительно не обязательно, т.к. сложно все форматы проверить), ни > корректность работы питоновского кода, после добавленного им «исправления» > для питона, что уже безответственно. > > Пока что не могу подтвердить готовность кандидата — это весьма грубая ошибка. Автор был предупрежден о возможной неработоспособности кода после просто смены шебанга, но автор проверил работу программы, видимо, не очень тщательно. Думаю, не стоит считать проявление безответственности, просто недостаточно тщательная проверка и отсутствие должного опыта работы с питонопакетами, чтобы в должностей степени опасаться подобных исправлений шебангов. А сборочница могла бы в email прислать кусок лога сборки с ошибками байткомпиляции, такого не было, насколько я знаю. 197296 23 bircoph 2021-03-26 22:54:47 +0300 (In reply to mikhailnov from comment #21) > А какой в Альте штатный способ произвести byte-компиляцию кода внутри > /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в > уведомительном порядке видеть в логе сборки? Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name. Приложение дёргает mobi в одном-единственном месте, так что не сложно поправить всё. 197297 24 bircoph 2021-03-26 23:02:01 +0300 (In reply to mikhailnov from comment #22) > Автор был предупрежден о возможной неработоспособности кода после просто > смены шебанга, но автор проверил работу программы, видимо, не очень > тщательно. Возможной? Кроме отдельных уникальных случаев и очень простых участков кода она гарантирована. Там py2 скриптов на 150 КБ. > Думаю, не стоит считать проявление безответственности, просто недостаточно > тщательная проверка и отсутствие должного опыта работы с питонопакетами, > чтобы в должностей степени опасаться подобных исправлений шебангов. Их не то, что опасаться, их никогда не следует делать, кроме нескольких уникальных ситуаций. > А сборочница могла бы в email прислать кусок лога сборки с ошибками > байткомпиляции, такого не было, насколько я знаю. Конечно не было, потому что байткомпиляции не было. Скрипты лежат там, где не должны быть, поэтому прошли мимо и компиляции, и проверок. 197298 25 mike 2021-03-26 23:10:27 +0300 (Ответ для Andrew Savchenko на комментарий #20) > И там заведомо есть конструкции, которые не будут работать в python3 без > модификации, например, mobi_unpack.py:1089: > print 'Unpacking Book...' > > В python3 это заведомо нерабочий код. 2to3 бы такое поправил? 197299 26 bircoph 2021-03-26 23:29:54 +0300 (In reply to Michael Shigorin from comment #25) > (Ответ для Andrew Savchenko на комментарий #20) > > И там заведомо есть конструкции, которые не будут работать в python3 без > > модификации, например, mobi_unpack.py:1089: > > print 'Unpacking Book...' > > > > В python3 это заведомо нерабочий код. > > 2to3 бы такое поправил? Именно процитированный пример — да. Весь имеющийся код — нет. Апстрим уже проделал всю работу, я дал выше ссылку на патч, можешь посмотреть, что там и сколько там работы. 2to3 — это всего лишь вспомогательный инструмент для облегчения портирования с py2 на py3. Но, к сожалению, некоторые люди его воспринимают как средство сделать из py2 py3 код без лишних хлопот. 197300 27 m 2021-03-26 23:30:23 +0300 (Ответ для Andrew Savchenko на комментарий #23) > (In reply to mikhailnov from comment #21) > > А какой в Альте штатный способ произвести byte-компиляцию кода внутри > > /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в > > уведомительном порядке видеть в логе сборки? > > Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать > для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name. > > Приложение дёргает mobi в одном-единственном месте, так что не сложно > поправить всё. Это будет, конечно, правильнее, но потребует серьезной переработки приложения, что чревато ошибки, и желательно при взаимодействии с апстримом. Питонокод в /usr/share встречается весьма часто, думаю, байткод в /usr/share поставлять премлемо, т.к. байткод не зависит от архитектуры процессора. Но вопрос был, каков аналог в Альте %py_compile %{buildroot}%{_datadir} ? В rosa2019.1 это раскрывается так: [user@rosa2019 ~]$ rpm -E '%py_compile %{buildroot}%{_datadir}' find /home/user/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/share -name '*.pyc' -exec rm -f {} \; echo '' -c "import sys, os, compileall; br='/home/user/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64'; compileall.compile_dir(sys.argv[1], ddir=br and (sys.argv[1][len(os.path.abspath(br)):]+'/') or None)" /home/user/rpmbuild/BUILDROOT/%{NAME}-%{VERSION}-%{RELEASE}.x86_64/usr/share Это можно делать и вне %install / %__spec_install_*, чтобы результат байткомпилирования не попадал в пакет, если он там не нужен, но чтобы выдавало ошибку при необходимости. 197301 28 neurofreak-alt 2021-03-26 23:37:26 +0300 (Ответ для Andrew Savchenko на комментарий #20) > Посмотрел ksnip — там всё хорошо, работа аккуратная. Спасибо за оценку ksnip, для начинающего сборщика rpm-пакетов приятно слышать. > Посмотрел bookworm — пришёл в ужас: > > # add python3 support fix > sed -i 's|#!.*python2$|#!/usr/bin/python3|' $(grep -Rl '#!.*python2$' *) > > python2 там используется для работы с *.mobi форматом: > data/scripts/mobi_lib/mobi_*.py > > И там заведомо есть конструкции, которые не будут работать в python3 без > модификации, например, mobi_unpack.py:1089: > print 'Unpacking Book...' > > В python3 это заведомо нерабочий код. По поводу bookworm, признаю, допустил оплошность по причине незнания специфики python-пакетов. Опыт мне на будущее. > Евгений, пожалуйста, исправьте эту проблему надлежащим образом. Работа bookworm будет исправлена. 197302 29 m 2021-03-26 23:39:16 +0300 В общем здесь вопрос в целом общий и не про конкретно этот пакет, пакетов с подобными проблемами, я уверен, воз и маленькая тележка, было бы неплохо выработать методику контроля такого в пакетной (сборочной) системе автоматически. Например, байт-компилировать весь питонокод, возможно, без добавления результата компиляции в пакет, а ошибки считать фатальными, если не задано что-то типа %_fatal_py_bytecompile_error 0 осознанно внутри спека. 197303 30 m 2021-03-26 23:44:02 +0300 Также neurogreak@ собрал вариант пакета вообще без правок шебанга и в Requires автоматически получил /usr/bin/env, что было создано автоматически из "#!/usr/bin/env python", то есть RPM нормально относится к тому, что в пакет закладывается мина замедленного действия, которая сработает, когда поменяется назначение симлинка /usr/bin/python, не говоря о пропуске нужной зависимости от /usr/bin/python2. 197304 31 bircoph 2021-03-26 23:52:33 +0300 (In reply to mikhailnov from comment #27) > (Ответ для Andrew Savchenko на комментарий #23) > > (In reply to mikhailnov from comment #21) > > > А какой в Альте штатный способ произвести byte-компиляцию кода внутри > > > /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в > > > уведомительном порядке видеть в логе сборки? > > > > Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать > > для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name. > > > > Приложение дёргает mobi в одном-единственном месте, так что не сложно > > поправить всё. > > Это будет, конечно, правильнее, но потребует серьезной переработки > приложения, что чревато ошибки, и желательно при взаимодействии с апстримом. На первый взгляд там в одном месте изменить строку в vala и поправить meson по установке файлов. Но детально не изучал — я не мейнтенер этого пакета :) > Питонокод в /usr/share встречается весьма часто, думаю, байткод в /usr/share > поставлять премлемо, т.к. байткод не зависит от архитектуры процессора. > > Но вопрос был, каков аналог в Альте > %py_compile %{buildroot}%{_datadir} ? %add_python3_compile_include %_datadir Вообще, настоятельно рекомендую использовать в качестве справочника "как NNN делается в Альте" http://git.altlinux.org/people/specbot/public/specs.git — это единый git со всеми спеками всех пакетов. Простой git grep даёт быстрый ответ на этот и подобные вопросы. 197305 32 bircoph 2021-03-26 23:59:09 +0300 (In reply to mikhailnov from comment #29) > В общем здесь вопрос в целом общий и не про конкретно этот пакет, пакетов с > подобными проблемами, я уверен, воз и маленькая тележка, было бы неплохо > выработать методику контроля такого в пакетной (сборочной) системе > автоматически. Например, байт-компилировать весь питонокод, возможно, без > добавления результата компиляции в пакет, а ошибки считать фатальными, если > не задано что-то типа %_fatal_py_bytecompile_error 0 осознанно внутри спека. Я не мейнтенер питона или сборочницы в Альте. Если Вы считаете, что нужно байт-компилировать весь код, поднимите этот вопрос в списке рассылки в devel — там Вам ответят ответственные лица и все им сочувствующие. Я не могу решать за всё сообщество как лучше сделать. В рамках данного бага моя претензия была не в отсутствии байт-компиляции, а в том, что портирование кода не выполнялось вовсе, а просто был запатчен shebang. Так нельзя. Мейнтенер пакета меня услышал, так что ждём доработки. 197306 33 m 2021-03-27 00:00:13 +0300 (Ответ для Andrew Savchenko на комментарий #31) > (In reply to mikhailnov from comment #27) > > (Ответ для Andrew Savchenko на комментарий #23) > > > (In reply to mikhailnov from comment #21) > > > > А какой в Альте штатный способ произвести byte-компиляцию кода внутри > > > > /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в > > > > уведомительном порядке видеть в логе сборки? > > > > > > Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать > > > для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name. > > > > > > Приложение дёргает mobi в одном-единственном месте, так что не сложно > > > поправить всё. > > > > Это будет, конечно, правильнее, но потребует серьезной переработки > > приложения, что чревато ошибки, и желательно при взаимодействии с апстримом. > > На первый взгляд там в одном месте изменить строку в vala и поправить meson > по установке файлов. Но детально не изучал — я не мейнтенер этого пакета :) Мейнтейнер распереживался, у него глубокая ночь, пусть спит пока, а потом вдумчиво правит пакет )) Там GUI не на python, значит, думаю, пока что вполне нормально оставить python-часть на python2, не наткнувшись на проблемы выкидывания поддержки py2 из апстримом многих связанных с GUI апстримов. Пока в апстриме bookworm не сделали релиз с py3, лучше проверенный код на py2 без внешних зависимостей (я внимательно не смотрел, но вроде бы их там нет), чем непроверенный на py3. > > > Питонокод в /usr/share встречается весьма часто, думаю, байткод в /usr/share > > поставлять премлемо, т.к. байткод не зависит от архитектуры процессора. > > > > Но вопрос был, каков аналог в Альте > > %py_compile %{buildroot}%{_datadir} ? > > %add_python3_compile_include %_datadir > > Вообще, настоятельно рекомендую использовать в качестве справочника "как NNN > делается в Альте" http://git.altlinux.org/people/specbot/public/specs.git — > это единый git со всеми спеками всех пакетов. Простой git grep даёт быстрый > ответ на этот и подобные вопросы. Спасибо. У меня есть локальное зеркало https://github.com/vt-alt/specs.git , но тут не очень очевидно было, что грепать, а в rpm-build-python3 сходу не нашел за пару минут. 197307 34 bircoph 2021-03-27 00:10:12 +0300 (In reply to mikhailnov from comment #30) > Также neurogreak@ собрал вариант пакета вообще без правок шебанга и в > Requires автоматически получил /usr/bin/env, что было создано автоматически > из "#!/usr/bin/env python", Я не понимаю о чём речь, т.к. в апстримных исходниках (по состоянию на commit 01f5c7dc04741a8e3a0893d6ec373e23cd25741d, что последний для mobi_lib) указано: #!/usr/bin/env python2 и никаких python без номера там нет Если считаете, что в rpm или python в Альте есть ошибка, откройте баг или напишите на devel. Замечу, что на мой взгляд как таковой rpm здесь вообще ни при чём, т.к. скрипты (и байткомпиляции, и всех проверок) идут из отдельных пакетов: rpm-build-python и python[23]-base. Но, по-моему, в контексте данного бага нужно обновить bookworm до python3. Как это лучше сделать — утащить отдельный коммит (или коммиты) или обновиться до git HEAD — пусть решает мейнтейнер, это его право, я не знаю, как ему будет удобнее. 197308 35 bircoph 2021-03-27 00:18:03 +0300 (In reply to mikhailnov from comment #33) > (Ответ для Andrew Savchenko на комментарий #31) > > (In reply to mikhailnov from comment #27) > > > (Ответ для Andrew Savchenko на комментарий #23) > > > > (In reply to mikhailnov from comment #21) > > > > > А какой в Альте штатный способ произвести byte-компиляцию кода внутри > > > > > /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в > > > > > уведомительном порядке видеть в логе сборки? > > > > > > > > Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать > > > > для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name. > > > > > > > > Приложение дёргает mobi в одном-единственном месте, так что не сложно > > > > поправить всё. > > > > > > Это будет, конечно, правильнее, но потребует серьезной переработки > > > приложения, что чревато ошибки, и желательно при взаимодействии с апстримом. > > > > На первый взгляд там в одном месте изменить строку в vala и поправить meson > > по установке файлов. Но детально не изучал — я не мейнтенер этого пакета :) > > Мейнтейнер распереживался, Не стоит, я же не со зла. Просто есть проблемы, которые нужно решить и вопросы, которым следует научиться. > у него глубокая ночь, пусть спит пока, а потом > вдумчиво правит пакет )) Там GUI не на python, значит, думаю, пока что > вполне нормально оставить python-часть на python2, не наткнувшись на > проблемы выкидывания поддержки py2 из апстримом многих связанных с GUI > апстримов. Там py2 нужен только для одного вызова mobi_unpack.py для чтения mobi файлов. По идее, этот mobi вообще можно в отдельный подпакет вынести — но это уже дело вкуса, я не настаиваю. > Пока в апстриме bookworm не сделали релиз с py3, лучше > проверенный код на py2 без внешних зависимостей (я внимательно не смотрел, > но вроде бы их там нет), чем непроверенный на py3. py2 не поддерживается апстримом и там никто не исследует и не исправляет уязвимости, поэтому его отовсюду и выкидывают. Я бы предпочёл утащить mobi_lib на py3, т.к. кроме самого mobi — который сейчас по факту и так поломан и в Сизифе, и в p9 — он ни на что другое не влияет. > > > Питонокод в /usr/share встречается весьма часто, думаю, байткод в /usr/share > > > поставлять премлемо, т.к. байткод не зависит от архитектуры процессора. > > > > > > Но вопрос был, каков аналог в Альте > > > %py_compile %{buildroot}%{_datadir} ? > > > > %add_python3_compile_include %_datadir > > > > Вообще, настоятельно рекомендую использовать в качестве справочника "как NNN > > делается в Альте" http://git.altlinux.org/people/specbot/public/specs.git — > > это единый git со всеми спеками всех пакетов. Простой git grep даёт быстрый > > ответ на этот и подобные вопросы. > > Спасибо. У меня есть локальное зеркало https://github.com/vt-alt/specs.git , > но тут не очень очевидно было, что грепать, а в rpm-build-python3 сходу не > нашел за пару минут. Ну я сделал первое, что пришло в голову: git grep -i "python.*compile" 197309 36 m 2021-03-27 00:31:14 +0300 (Ответ для Andrew Savchenko на комментарий #35) > Там py2 нужен только для одного вызова mobi_unpack.py для чтения mobi > файлов. По идее, этот mobi вообще можно в отдельный подпакет вынести — но > это уже дело вкуса, я не настаиваю. Если перенести из /usr/share в %python3_sitelibdir_noarch и оформить как именно python-модуль, то смысл вынести в отдельный пакет будет. Внутри /usr/share, думаю, не стоит делать отдельный пакет. т.к. его нельзя будет использовать как python-модуль без как минимум манипуляций с $PYTHONPATH или аналогом. > > > Пока в апстриме bookworm не сделали релиз с py3, лучше > > проверенный код на py2 без внешних зависимостей (я внимательно не смотрел, > > но вроде бы их там нет), чем непроверенный на py3. > > py2 не поддерживается апстримом и там никто не исследует и не исправляет > уязвимости, поэтому его отовсюду и выкидывают. Я бы предпочёл утащить > mobi_lib на py3, т.к. кроме самого mobi — который сейчас по факту и так > поломан и в Сизифе, и в p9 — он ни на что другое не влияет. Согласен, разумно. 197310 37 grenka 2021-03-27 02:02:32 +0300 (Ответ для Andrew Savchenko на комментарий #32) Дядь, забирай камень обратно! Молодец. Тебе говорят, что человек всё знает и понимает, а ты придираешься. Почувствуй себя злым ментором тоже=)) 2neurofreak: FYI: https://github.com/babluboy/bookworm/pull/346 197311 38 m 2021-03-27 02:08:08 +0300 (Ответ для Grigory Ustinov на комментарий #37) > 2neurofreak: FYI: https://github.com/babluboy/bookworm/pull/346 -print " - fixed by injecting empty start tag ", tname +print(' - fixed by injecting empty start tag ', tname) Значит мои опасения о непротестированности py3-кода были не напрасны. 197312 39 bircoph 2021-03-27 02:13:39 +0300 (In reply to mikhailnov from comment #38) > (Ответ для Grigory Ustinov на комментарий #37) > > > 2neurofreak: FYI: https://github.com/babluboy/bookworm/pull/346 > > -print " - fixed by injecting empty start tag ", tname > +print(' - fixed by injecting empty start tag ', tname) > > Значит мои опасения о непротестированности py3-кода были не напрасны. Это в коде обработки ошибок. Видимо, только на битых файлах проявляется. Разумеется, этот PR тоже нужно забрать. 197313 40 bircoph 2021-03-27 02:15:46 +0300 (In reply to Grigory Ustinov from comment #37) > (Ответ для Andrew Savchenko на комментарий #32) > Дядь, забирай камень обратно! Молодец. Тебе говорят, что человек всё знает и > понимает, а ты придираешься. Почувствуй себя злым ментором тоже=)) Ну к мелочам я стараюсь не придираться, но тут на самом деле серьёзная проблема вылезла. Если бы новый член team такое закоммитил, ты бы крик в devel и поднял. 197314 41 bircoph 2021-03-27 10:50:11 +0300 Евгений, по minigalaxy: 1) Некорректно указана лицензия: вместо CC-BY нужно CC-BY-3.0 См. THIRD-PARTY-LICENSES.md в исходниках и /usr/share/licenses для списка допустимых обозначений лицензий. 2) Мне непонятно, зачем: %add_python3_req_skip gi.repository.GdkPixbuf Я не утверждаю, что это некорректно, но причина мне не ясна и данная строка вызывает подозрения. 197315 42 neurofreak-alt 2021-03-27 12:06:50 +0300 (Ответ для Andrew Savchenko на комментарий #41) > Евгений, по minigalaxy: > > 1) Некорректно указана лицензия: вместо CC-BY нужно CC-BY-3.0 > См. THIRD-PARTY-LICENSES.md в исходниках и /usr/share/licenses для списка > допустимых обозначений лицензий. > > 2) Мне непонятно, зачем: > %add_python3_req_skip gi.repository.GdkPixbuf > > Я не утверждаю, что это некорректно, но причина мне не ясна и данная строка > вызывает подозрения. Андрей, добрый день. Я не планирую minigalaxy и notepadqq посылать на сборку в репозиторий, но спасибо за то, что нашли время посмотреть и оценить. 197316 43 neurofreak-alt 2021-03-27 12:16:15 +0300 Замечания принял к сведению. 197763 44 neurofreak-alt 2021-04-10 05:53:17 +0300 (Ответ для Andrew Savchenko на комментарий #32) > Мейнтенер пакета меня услышал, так что ждём доработки. Пакет исправлен с учётом всех замечаний, что тут прозвучали. Спасибо за советы. 197771 45 bircoph 2021-04-10 14:52:56 +0300 (In reply to neurofreak-alt@yandex.ru from comment #44) > (Ответ для Andrew Savchenko на комментарий #32) > > Мейнтенер пакета меня услышал, так что ждём доработки. > > Пакет исправлен с учётом всех замечаний, что тут прозвучали. Спасибо за > советы. Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно. Проблема решается не сложно. 197773 46 mike 2021-04-10 18:30:24 +0300 (Ответ для Andrew Savchenko на комментарий #45) > Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите > *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно. > Проблема решается несложно. Так подскажи, как решается или куда читать, раз знаешь :-) 197774 47 neurofreak-alt 2021-04-10 18:41:04 +0300 (Ответ для Andrew Savchenko на комментарий #41) > Евгений, по minigalaxy: > > 1) Некорректно указана лицензия: вместо CC-BY нужно CC-BY-3.0 > См. THIRD-PARTY-LICENSES.md в исходниках и /usr/share/licenses для списка > допустимых обозначений лицензий. > > 2) Мне непонятно, зачем: > %add_python3_req_skip gi.repository.GdkPixbuf > > Я не утверждаю, что это некорректно, но причина мне не ясна и данная строка > вызывает подозрения. Андрей, добрый день. Я не планирую minigalaxy и notepadqq посылать на сборку в репозиторий, но спасибо за то, что нашли время посмотреть и оценить.(Ответ для Michael Shigorin на комментарий #46) > (Ответ для Andrew Savchenko на комментарий #45) > > Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите > > *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно. > > Проблема решается несложно. > Так подскажи, как решается или куда читать, раз знаешь :-) Андрей написал. Удалить файлы .pyc из исходников в секции %prep. Попробую. 197776 48 bircoph 2021-04-10 18:55:50 +0300 (In reply to Michael Shigorin from comment #46) > (Ответ для Andrew Savchenko на комментарий #45) > > Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите > > *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно. > > Проблема решается несложно. > Так подскажи, как решается или куда читать, раз знаешь :-) По-моему, я и так слишком многое рассказал по связанным с питоном вопросам. Всё же для самостоятельной работы в Сизифе важно посмотреть на самостоятельную работу кандидата. Я проверил, что проблема решается. Начало её решения описал, но это не всё решение. 198367 49 neurofreak-alt 2021-05-06 05:00:11 +0300 Прошу прощения за долгое отсутствие. Пришлось основательно перелопатить информации, да и работа навалилась. Добился я в итоге байткомпиляции скриптов. Прошу оценить результат: [1] http://git.altlinux.org/people/neurofreak/packages/bookworm.git [2] http://git.altlinux.org/tasks/271250/ 198378 50 bircoph 2021-05-07 13:33:25 +0300 Добрый день! (In reply to neurofreak-alt@yandex.ru from comment #49) > Прошу прощения за долгое отсутствие. Это не страшно. У нас мейнтенеры обычно работают в комфортом для них темпе, что может очень сильно различаться у разных людей. > Пришлось основательно перелопатить информации, > да и работа навалилась. Добился я в итоге байткомпиляции скриптов. > Прошу оценить результат: > > [1] http://git.altlinux.org/people/neurofreak/packages/bookworm.git > [2] http://git.altlinux.org/tasks/271250/ Байт-компиляция так действительно работает. Я бы решил проблему чуть иначе, т.к. все манипуляции с +x на *.py нужны из-за того, что по-умолчанию у нас /usr/lib/rpm/python3.compileall.py запускается с --skip-x (см. /usr/lib/rpm/macros.d/python3), что отключает байт-компиляцию исполняемых файлов. Такое поведение можно инвертировать с помощью макроса rpm, так что достаточно сделать так: +%add_python3_compile_include %_datadir +%undefine _python3_compile_skip_x И тогда ни изменения прав доступа, ни ручной запуск python3 -m compileall будут не нужны. Но Ваше решение тоже вполне жизнеспособно. Просто многие проблемы можно решить по-разному. Товарищ секретарь, за сим считаю, что кандидат действительно готов к самостоятельной работе в Сизифе. 198485 51 neurofreak-alt 2021-05-14 16:30:54 +0300 А тем временем ksnip-1.8.2-alt1 готов: [1] http://git.altlinux.org/people/neurofreak/packages/?p=ksnip.git;a=tag;h=5311dccb2411f2a56cd4111fc6d0eea044cabc2a [2] http://git.altlinux.org/tasks/271830/ А без ментора в сизиф не могу послать :( 198559 52 glebfm 2021-05-18 15:57:26 +0300 (Ответ для Andrew Savchenko на комментарий #50) > Товарищ секретарь, за сим считаю, что кандидат действительно готов к > самостоятельной работе в Сизифе. 198560 53 glebfm 2021-05-18 16:01:31 +0300 Адрес подписан на devel@. Пользователь добавлен в группу мейнтейнеров. Желаю удачного мейнтейнерства! 198568 54 m 2021-05-18 22:01:06 +0300 Поздравляю! Багу, наверное, нужно сделать RESOLVED FIXED? 200252 55 cas 2021-07-11 10:31:35 +0300 Закрыто. 9159 2021-01-27 12:15:49 +0300 2021-01-27 12:15:49 +0300 Публичная часть SSH-ключа id_ed25519.pub application/vnd.ms-publisher 119 neurofreak-alt c3NoLWVkMjU1MTkgQUFBQUMzTnphQzFsWkRJMU5URTVBQUFBSUIzbkYwMXVSbTdtdWMxU1lFWG1R YUZIR2NNOVhEb1I1QUh2emY3aEU2YW4gbmV1cm9mcmVha0Bjb21wLWNvcmUtaTctMzYxMHFtLTQ3 M2RjOQo= 9160 2021-01-27 12:16:40 +0300 2021-01-27 12:16:40 +0300 Публичная часть GPG-ключа gpgpublic.txt text/plain 3086 neurofreak-alt LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgptUUlOQkdBUklTc0JFQURPdnVz UkR3dTRvaWtOcjVZRzBCRHY5MWxJeHl2bTc2OWdzWEVPQzQ3OEZxQktlS2NqCjFzSzdTd3RGa0dv ZWh0bVFFdEFNQVZmRlpZTzJ1TmNPblhiL1ptY0RiNW9sTXp3RTRkbmJBWjEwZU05dUIreFYKOWM1 MHNkNmJBQUVTOU9va2ZHWHhxbkZRN3dBbW1hWHh1WXVKNUM1VFkxRWtSUTlDYW03bU55QjY4U1hx cjZMbQpnbEpJckI4Y3c3MXVwTmlHSXYxck1MRHRQZ2ttNXdwRjJ0MG5USkIycm9lSmdpWW9VSllT cXNQb1A0RDVVUG8vCmxGWS8vajFacVJBZTQrbUFXT1l4cUxaQnQ2cUZVTG1xZjVwVHdCMzhqMVlZ TFEvUVNiMWQ4MFp1dmYrU0RqeFEKYXVQVE0yQXl2My9lWVRqUkFVT1YxeUNwMjl4MTdsTjFHdTBM cDFGUVFRS3REUjV5RDFvUE9HUitHZy9QLytlZgpCb0pEaEc2ZHhzTFh3eE9kOGIrZHBLL3NlVUZE YWVmb1pRV0tISjNmUlJYWkhOYUU5a3U5SFVpNWd1TW5KU2JUClRBS21Jd1ZKMjUwbm5wdEZubkpS Ni9JR1ZkT3NjdnpnNERMRHBZa0c1NUFLR3pxd1haOGVTTnYzN3Brd2I1WTIKR1VLMWNZMFg0Z3hp VmcxUDRRL1pIY2dBd0ZSV0lUcXBGemYyNGN5OC9XVXk4Vi9SZ2F6M3FCN2NjRlpSZVVwWQpPV0kw RUhDRzJKSHlCNTZjWTQvWTdzVnQ4a2VnNGxzZ1dVWWZEOHZ1N3l3aGg4ekh1R29SNFZjWFZiaEtU dmVNCk8xNWpCaVZ2b3NhQkt5Q0M3YUdQR2JOZGJ3cGw4aklXZTZxenlhclF4cURYSHFFZFU1WVNL aUQyUVFBUkFRQUIKdEN0RmRtZGxibWw1SUV0MWEyaDBhVzV2ZGlBOGJtVjFjbTltY21WaGEwQmhi SFJzYVc1MWVDNXZjbWMraVFJNApCQk1CQWdBaUJRSmdFU0VyQWhzREJnc0pDQWNEQWdZVkNBSUpD Z3NFRmdJREFRSWVBUUlYZ0FBS0NSQW9LRnNQCkxLYkcvWTJQRC80OXo2M2lxTjdKYlkzNE1PVmZQ ZDl1OWcxMmxNUk5iS2k2ZTZYcVo0a0VUMDVKRnU2K3FLVGoKdWFqU0JaNVg3eXZJZ3AwUlJGc2hC b1FrTWZvSFE3aEE5cmI1dVN2UWluczRpWHBBT0EzTEhUa2NTWGFJMlR6ago3MnN3UW5Gc1pyeVNK RnV0YkNjY1JGbzlhdnNrellpQVl5bUtVUVp3SkN6VVdsalRtNktvN3JpWDZZb0tOWGFSClU1RmVZ NUJqUkVBM3hnY3k2aVNpNzVKY0dPUUZlZ3Y4UkhrNDNnUDdSc0dFZ1dkdWtpTFRHL3ZmM2dIK3JV aTMKL0JuL01EYnRCdE8xTm8rWUF6ZCtKMGpxMmZiejRhd2hGQnZHOHF4MEtPQlN3SWNtQUlZYnV6 QzhYZ2dqTlJOSgpXL2FuK3pWVVNQK2tmTXQ1ZGpSQjJuTi9sZXU5T0Fqa1pWSVZnWkdlMkxNc08z SVJGaHRRNkxJQk9XOVpHM0gyCmd4MXRTOG8rS00yeUtLZ05zSlFyeElQdjNYMlBZUGNQdkcydVZY UE4rT2pqaEIzRU5FczVZdUVPclhZL01XdWUKa3V2ek5SbGRZb09BMnljSm9XYi8vTDNpcVhpRmts WUhjUU9OT3RiOEhpTi9raWdXTk9VNlZ0MGxsS2w3ODVMTgpxOC9TOG9qd2JOanZscUxYeU1DMEM4 MjI2V1ZRNU41MWg1OTNLRmFGRHlheHNYc0NRSlRYeHUxU25Gb2RqTlBuCmh4VGlNeHEwWnR6YXNs aXNtc0ZaQlJpcWZnYTFFMG83Zklaek1oNmV0eENabnp1SVZtZHF2ZzhUa2VaRWZzVzAKK1NXWlhj NU9EcUlWS25zdWVMOTZ4dDdmcXU3RVVqZ1dMaEk2Y2pLWksxN05zNXRuRzhia3Vya0NEUVJnRVNF cgpBUkFBc0tMaWw5NFlPR3BTVXJ3OWRkSkozWjVZbW1KQXBzZWp6T2dMRXhoMGxuM21vRHFMbnhE T21IWVJiNzRMCmxMTTR0aHFYd0UzbCtUMkt2SDJLNzZDU2xNem9zRmk4Sk1BUDBxUEE0UXE2V2Y2 SEY2NjFOYWY4cm1aUDQvaVUKY0JTOEplVVRWNEo1b1d1WXVKb2VmOTRzSmFMT002NVR1anRWZStP T3ZzdEw0TnBuTDhodXdPb2ZHNTBvNUZrcwpBRDNJR1hFWUNRbmxRcUVIWDhyZmRIK3E5UDBYQ21R T3h3dUFBelFZbFYxUk5mVjhWMCsvQzdlMW5MYTFnZzhxCjc0eVQreHprVWJGejNZSkdIQ2MxdlRr aXZtSW5XTGxqQTFQQndHL0lqTGNlYTBIaS9xOFhGdDNqeE9XQmlhaEgKUWpESU9vWVprWVdzRmc1 dlVndnFiaGJ1YnlkL20zdzF4RkxocFlISVZyeW4xUmZ5eTM2V2VqWTJzNSt1U09GbwpiWEl1NTQw a1RiTFFnQ08zQzlNd0pOK0M4cEVxRlhEc3FBN1NRb0tOVUtiOWpvUmFDNk00ZFJ0ZlhZSjhIb1A2 ClEwV2QraFg0cy81dkIzb0JxZUxIQ1gyVXFrSGR4Tk5Da2lXZTF1UTV5YUpiRXhLdXN2Qkpaclcr aWZpV3pwU3YKREpKcWlKR21OZXhHSlpYME1YQ0hZWDVCZ3l0Rm9QY0ZTQ2ZyYStScnl2ZEt6dU9w dnRWcWxoTXdJQzN0bmsxTgpQRTBrd2pPZSt2clJsRmQvWVdVd3k3WkVLbWJQcFNoeEw4VFdLQlNS WXBRb0d2b0lvVVFuYjRkSTNUd1FsQUduClFqeXRmTFhtN3UzaXFpMFNJaC84MCswOVRWeWpOUmNU aTdUcjhYRzBsYjJnRnQ4QUVRRUFBWWtDSHdRWUFRSUEKQ1FVQ1lCRWhLd0liREFBS0NSQW9LRnNQ TEtiRy9WMGZELzkxdXJIaFlNK3FRT05lZ3VZbjJ4YzhoL3N5MTNLdwpPRyt2bmhrRnVaaHpDRXFE Ukx5WUJtK296Q1dHR3pVZmhVU3JWbG5OOHIwUkJCRUZrazlHZDRrRjFKTmFOTUNNClBhRFFBSkd2 SDN2WUY5dk42eG5KN0p6R2ZURmNNamVIS1lTUnlPZFVPdmNJVlVwQ29nTSsrS2FxOTV3aEgrVWYK ZS9KOFNETys4VllQcWtSUVh4YXZzcjBUMlAzQnFmNkdFK0t2RllMQ1VLNzlmOWxNeGZqUks5WEt1 b0lFVithUQpTdmlWUEdWNTUzTEY2eUQzbWdreUlONnZqVmFqU0trb3FJb2lUb0I3ZWxXZmw3WFNs TUg3aVZyOWhhZjFFaVFKCmhsZWlZTEo0TDNGb05rSnBkVlRRZHVFSWJJdSszWFJyT3lKcGxJbGpk Wk5icVgvUCtjeXYxMDVRSnh0c3hqSk4KR1ZCSTF5YUIzYlJma3kvOHVsQy85alFvOHpvOFk1TG94 bEtQVXdjeDZrUXFyTVVvaUd5cWpuT0JMUUVHYUx1bApLNEVWSHNBTmhNL1BkY0I2Q2pvaUJtMncx VWs2c2IyNmJVTmhxWEdFVFlabHlzYUE3U3RKdGM5QjkycFhDOU5PCmVKZlc1Y29Qd0FzV0xPK1dk Vitpb0dXY0dnbWpkL05jeDFRS1MxK2RhQjFtekJFaDlseXVTVWI5eWJnOFBuV04KTWQ4QTJkY0Vy b3ZzSGtLa1BJRURIejNBVWwrTG42T1ZONElsLzMvWW1uZkt3aklYclZFTCtNeVdJMFVsMU9peQox T0pJSFkvQmhsRHpLM1VXSWQweVM1bStmQ3hteG9MK2V1U0licmlhU2pHYzZFaVBOa2Q4bEs1TytP LzV2dGpRCjh6WmxNQ3VZOGd5bk5nPT0KPWM5eGcKLS0tLS1FTkQgUEdQIFBVQkxJQyBLRVkgQkxP Q0stLS0tLQo=