Created attachment 9159 [details]
Публичная часть SSH-ключа

Created attachment 9160 [details]
Публичная часть GPG-ключа

Ментор подтверждает менторство

Там есть готовый к отправке в сизиф пакет, можно сразу права на сборку в сборочнице дать, т.к. кандидат умеет собирать локально, теперь нужно в сборочнице.

(Ответ для mikhailnov на комментарий #3)
> Ментор подтверждает менторство
(Ответ для neurofreak-alt@yandex.ru на комментарий #1)
> Создано вложение 9159 [details] [подробности]
> Публичная часть SSH-ключа
(Ответ для neurofreak-alt@yandex.ru на комментарий #2)
> Создано вложение 9160 [details] [подробности]
> Публичная часть GPG-ключа

Ok.

А 1.2 означает какой пункт из https://www.altlinux.org/Team/Join/Secretary ?

(Ответ для mikhailnov на комментарий #6)
> А 1.2 означает какой пункт из https://www.altlinux.org/Team/Join/Secretary ?

Было бы странно, если бы 1.2 значило какой-то другой пункт кроме 1.2.

> Ожидать решения ментора о готовности кандидата.

Кандидат готов к тестовым сборкам в сборочнице без прав коммита в сизиф, о чем писал выше, поэтому уточнил.

ssh ключ на gitery.alt зарегистрирован.
ssh ключ на gyle.alt зарегистрирован.
Адрес для пересылки создан.

T/J/S -> 2.4.

(Ответ для Gleb F-Malinovskiy на комментарий #9)
> ssh ключ на gitery.alt зарегистрирован.
> ssh ключ на gyle.alt зарегистрирован.
> Адрес для пересылки создан.
> 
> T/J/S -> 2.4.

Благодарю.

Кандидат подготовил пакет,подписал тег, прошу перевести на следующий этапи добавить GPG-ключ в сборочницу.

Гриш, можешь глянуть с прищуром на предмет .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.

> Евгений, по
> 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 ;)

Пакет alt-gpgkeys обновлён.

T/J/S -> 3.4.

Кандидат на данный момент собрал уже 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.

Собственно, пора в team; предлагаю переходить к п.5.

Благодарю всех за оказанное доверие!)

И спасибо за науку!

Попробую позвать ещё одного человека (bircoph@) для независимой оценки готовности кандидата.

Посмотрел 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

А какой в Альте штатный способ произвести byte-компиляцию кода внутри /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в уведомительном порядке видеть в логе сборки?

(Ответ для Andrew Savchenko на комментарий #20)
> 
> По-видимому, автор не проверял ни работоспособность для формата mobi (что
> действительно не обязательно, т.к. сложно все форматы проверить), ни
> корректность работы питоновского кода, после добавленного им «исправления»
> для питона, что уже безответственно.
> 
> Пока что не могу подтвердить готовность кандидата — это весьма грубая ошибка.

Автор был предупрежден о возможной неработоспособности кода после просто смены шебанга, но автор проверил работу программы, видимо, не очень тщательно.

Думаю, не стоит считать проявление безответственности, просто недостаточно тщательная проверка и отсутствие должного опыта работы с питонопакетами, чтобы в должностей степени опасаться подобных исправлений шебангов.

А сборочница могла бы в email прислать кусок лога сборки с ошибками байткомпиляции, такого не было, насколько я знаю.

(In reply to mikhailnov from comment #21)
> А какой в Альте штатный способ произвести byte-компиляцию кода внутри
> /usr/share, где этот лежит, чтобы подобное отлавливать и как минимум в
> уведомительном порядке видеть в логе сборки?

Я бы предложил не класть байткомпилируемый код в /usr/share, а использовать для этого стандартный питоньий путь: /usr/lib/python3/site-packages/$name.

Приложение дёргает mobi в одном-единственном месте, так что не сложно поправить всё.

(In reply to mikhailnov from comment #22)
> Автор был предупрежден о возможной неработоспособности кода после просто
> смены шебанга, но автор проверил работу программы, видимо, не очень
> тщательно.

Возможной? Кроме отдельных уникальных случаев и очень простых участков кода она гарантирована. Там py2 скриптов на 150 КБ.
 
> Думаю, не стоит считать проявление безответственности, просто недостаточно
> тщательная проверка и отсутствие должного опыта работы с питонопакетами,
> чтобы в должностей степени опасаться подобных исправлений шебангов.

Их не то, что опасаться, их никогда не следует делать, кроме нескольких уникальных ситуаций.

> А сборочница могла бы в email прислать кусок лога сборки с ошибками
> байткомпиляции, такого не было, насколько я знаю.

Конечно не было, потому что байткомпиляции не было. Скрипты лежат там, где не должны быть, поэтому прошли мимо и компиляции, и проверок.

(Ответ для Andrew Savchenko на комментарий #20)
> И там заведомо есть конструкции, которые не будут работать в python3 без
> модификации, например, mobi_unpack.py:1089:
>         print 'Unpacking Book...'
> 
> В python3 это заведомо нерабочий код.

2to3 бы такое поправил?

(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 код без лишних хлопот.

(Ответ для 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_*, чтобы результат байткомпилирования не попадал в пакет, если он там не нужен, но чтобы выдавало ошибку при необходимости.

(Ответ для 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 будет исправлена.

В общем здесь вопрос в целом общий и не про конкретно этот пакет, пакетов  с подобными проблемами, я уверен, воз и маленькая тележка, было бы неплохо выработать методику контроля такого в пакетной (сборочной) системе автоматически. Например, байт-компилировать весь питонокод, возможно, без добавления результата компиляции в пакет, а ошибки считать фатальными, если не задано что-то типа %_fatal_py_bytecompile_error 0 осознанно внутри спека.

Также neurogreak@ собрал вариант пакета вообще без правок шебанга и в Requires автоматически получил /usr/bin/env, что было создано автоматически из "#!/usr/bin/env python", то есть RPM нормально относится к тому, что в пакет закладывается мина замедленного действия, которая сработает, когда поменяется назначение симлинка /usr/bin/python, не говоря о пропуске нужной зависимости от /usr/bin/python2.

(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 даёт быстрый ответ на этот и подобные вопросы.

(In reply to mikhailnov from comment #29)
> В общем здесь вопрос в целом общий и не про конкретно этот пакет, пакетов  с
> подобными проблемами, я уверен, воз и маленькая тележка, было бы неплохо
> выработать методику контроля такого в пакетной (сборочной) системе
> автоматически. Например, байт-компилировать весь питонокод, возможно, без
> добавления результата компиляции в пакет, а ошибки считать фатальными, если
> не задано что-то типа %_fatal_py_bytecompile_error 0 осознанно внутри спека.

Я не мейнтенер питона или сборочницы в Альте. Если Вы считаете, что нужно байт-компилировать весь код, поднимите этот вопрос в списке рассылки в devel — там Вам ответят ответственные лица и все им сочувствующие. Я не могу решать за всё сообщество как лучше сделать.

В рамках данного бага моя претензия была не в отсутствии байт-компиляции, а в том, что портирование кода не выполнялось вовсе, а просто был запатчен shebang. Так нельзя. Мейнтенер пакета меня услышал, так что ждём доработки.

(Ответ для 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 сходу не нашел за пару минут.

(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 — пусть решает мейнтейнер, это его право, я не знаю, как ему будет удобнее.

(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"

(Ответ для 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 — он ни на что другое не влияет.

Согласен, разумно.

(Ответ для Andrew Savchenko на комментарий #32)
Дядь, забирай камень обратно! Молодец. Тебе говорят, что человек всё знает и понимает, а ты придираешься. Почувствуй себя злым ментором тоже=))

2neurofreak: FYI: https://github.com/babluboy/bookworm/pull/346

(Ответ для 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-кода были не напрасны.

(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 тоже нужно забрать.

(In reply to Grigory Ustinov from comment #37)
> (Ответ для Andrew Savchenko на комментарий #32)
> Дядь, забирай камень обратно! Молодец. Тебе говорят, что человек всё знает и
> понимает, а ты придираешься. Почувствуй себя злым ментором тоже=))

Ну к мелочам я стараюсь не придираться, но тут на самом деле серьёзная проблема вылезла. Если бы новый член team такое закоммитил, ты бы крик в devel и поднял.

Евгений, по minigalaxy:

1) Некорректно указана лицензия: вместо CC-BY нужно CC-BY-3.0
См. THIRD-PARTY-LICENSES.md в исходниках и /usr/share/licenses для списка допустимых обозначений лицензий.

2) Мне непонятно, зачем:
%add_python3_req_skip gi.repository.GdkPixbuf

Я не утверждаю, что это некорректно, но причина мне не ясна и данная строка вызывает подозрения.

(Ответ для 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 посылать на сборку в репозиторий, но спасибо за то, что нашли время посмотреть и оценить.

Замечания принял к сведению.

(Ответ для Andrew Savchenko на комментарий #32)
> Мейнтенер пакета меня услышал, так что ждём доработки.

Пакет исправлен с учётом всех замечаний, что тут прозвучали. Спасибо за советы.

(In reply to neurofreak-alt@yandex.ru from comment #44)
> (Ответ для Andrew Savchenko на комментарий #32)
> > Мейнтенер пакета меня услышал, так что ждём доработки.
> 
> Пакет исправлен с учётом всех замечаний, что тут прозвучали. Спасибо за
> советы.

Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно.

Проблема решается не сложно.

(Ответ для Andrew Savchenko на комментарий #45)
> Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите
> *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно.
> Проблема решается несложно.
Так подскажи, как решается или куда читать, раз знаешь :-)

(Ответ для 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. Попробую.

(In reply to Michael Shigorin from comment #46)
> (Ответ для Andrew Savchenko на комментарий #45)
> > Уже лучше, но байт-компиляция питоновского кода не осуществляется. Удалите
> > *.pyc из репозитория и посмотрите на результат. Да и по логам сборки видно.
> > Проблема решается несложно.
> Так подскажи, как решается или куда читать, раз знаешь :-)

По-моему, я и так слишком многое рассказал по связанным с питоном вопросам. Всё же для самостоятельной работы в Сизифе важно посмотреть на самостоятельную работу кандидата.

Я проверил, что проблема решается. Начало её решения описал, но это не всё решение.

Прошу прощения за долгое отсутствие. Пришлось основательно перелопатить информации,
да и работа навалилась. Добился я в итоге байткомпиляции скриптов.
Прошу оценить результат:

[1] http://git.altlinux.org/people/neurofreak/packages/bookworm.git
[2] http://git.altlinux.org/tasks/271250/

Добрый день!

(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 будут не нужны.

Но Ваше решение тоже вполне жизнеспособно. Просто многие проблемы можно решить по-разному.


Товарищ секретарь, за сим считаю, что кандидат действительно готов к самостоятельной работе в Сизифе.

А тем временем 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/

А без ментора в сизиф не могу послать :(

(Ответ для Andrew Savchenko на комментарий #50)
> Товарищ секретарь, за сим считаю, что кандидат действительно готов к
> самостоятельной работе в Сизифе.

Адрес подписан на devel@.
Пользователь добавлен в группу мейнтейнеров.

Желаю удачного мейнтейнерства!

Поздравляю! Багу, наверное, нужно сделать RESOLVED FIXED?

Закрыто.