[devel] Перевод пакетов на python3-module-

[devel] Перевод пакетов на python3-module-

[Vitaly Lipatov]

У меня большая просьба к переводящим пакеты на python3: делать это не 
как попало (т.е. как вам кажется правильным), а единообразно (т.е. как 
мне кажется правильным).

В качестве примера предлагаю посмотреть на спек
https://packages.altlinux.org/ru/sisyphus/specfiles/python3-module-incremental

К сожалению, полная статья на эту тему у меня временно пропала из-за 
того, что многие программы (в том числе gnote и thunderbird) уничтожают 
данные при превышении дисковой квоты (невозможности записи в файл).

Но я хотел бы подчеркнуть, что для автоматизированного обновления 
пакетов python3 важно, чтобы чтобы они собирались из опубликованных на 
pypi тарболов, а не секретного места на github, которое при желании 
можно найти, просто gear-remotes-save не является обязательным.

Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из 
srpm является ложной: пакеты из тарбола легко и удобно собираются в git.

У нас тут не сильно творческая деятельность, а упаковка релизов pypi в 
rpm-пакеты, поэтому важно стремиться не к проявлению индивидуальности, а 
к однообразию, скудности наполнения спека и возможности автоматической 
сборки.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Перевод пакетов на python3-module-

[Anton Farygin]

Было бы здорово ещё обязательно включать секцию %check в python пакетах, 
т.к. то, что у вас что-то запаковалось - не означает что это что-то хоть 
как-то работает.



On 10.11.2020 15:41, Vitaly Lipatov wrote:
> У меня большая просьба к переводящим пакеты на python3: делать это не 
> как попало (т.е. как вам кажется правильным), а единообразно (т.е. как 
> мне кажется правильным).
>
> В качестве примера предлагаю посмотреть на спек
> https://packages.altlinux.org/ru/sisyphus/specfiles/python3-module-incremental 
>
>
> К сожалению, полная статья на эту тему у меня временно пропала из-за 
> того, что многие программы (в том числе gnote и thunderbird) 
> уничтожают данные при превышении дисковой квоты (невозможности записи 
> в файл).
>
> Но я хотел бы подчеркнуть, что для автоматизированного обновления 
> пакетов python3 важно, чтобы чтобы они собирались из опубликованных на 
> pypi тарболов, а не секретного места на github, которое при желании 
> можно найти, просто gear-remotes-save не является обязательным.
>
> Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из 
> srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
>
> У нас тут не сильно творческая деятельность, а упаковка релизов pypi в 
> rpm-пакеты, поэтому важно стремиться не к проявлению индивидуальности, 
> а к однообразию, скудности наполнения спека и возможности 
> автоматической сборки.
>

Re: [devel] Перевод пакетов на python3-module-

[Vitaly Lipatov]

Anton Farygin писал 10.11.20 15:52:
> Было бы здорово ещё обязательно включать секцию %check в python
> пакетах, т.к. то, что у вас что-то запаковалось - не означает что это
> что-то хоть как-то работает.
+1
внесу в policy

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

[devel] пакеты из тарбола легко и удобно собираются в git

[Sergey V Turchin]

On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:

[...]
> Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
т.к. мне стало так удобнее.

[...]

-- 
Regards, Sergey.

Re: [devel] пакеты из тарбола легко и удобно собираются в git

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 908 bytes --]

On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> 
> [...]
> > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
> т.к. мне стало так удобнее.

Это удобнее пока отладку делать не нужно, а как возникает серьёзная
проблема и нужен git bisect, то внезапно оказывается, что идея
с тарболами не такая уж и хорошая.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] пакеты из тарбола легко и удобно собираются в git

[Sergey V Turchin]

On Tuesday, 10 November 2020 17:27:37 MSK Andrey Savchenko wrote:
> On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> 
> > On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> > 
> > [...]
> > 
> > > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > > srpm является ложной: пакеты из тарбола легко и удобно собираются в
> > > git.
> > 
> > Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в
> > git", 
 т.к. мне стало так удобнее.
> 
> 
> Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> проблема и нужен git bisect, то внезапно оказывается, что идея
> с тарболами не такая уж и хорошая.
Немного мимо, т.к. с .src.rpm git bisect работает ещё хуже.

-- 
Regards, Sergey.

Re: [devel] ***UNCHECKED*** Re: пакеты из тарбола легко и удобно собираются в git

[Vitaly Lipatov]

Andrey Savchenko писал 10.11.20 17:27:
> On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
>> On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
>> 
>> [...]
>> > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
>> > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
>> Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола 
>> в git",
>> т.к. мне стало так удобнее.
> 
> Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> проблема и нужен git bisect, то внезапно оказывается, что идея
> с тарболами не такая уж и хорошая.
Вы правы, но
1) bisect по релизам позволит собирать гарантированно собиравшиеся 
версии.
2) если речь о бисекте в апстриме (какой коммит сломал что-то к новой 
версии) — это легко делается в отдельном git-репозитории, 
синхронизированном с апстримом.
3) у нас задача — собирать пакеты, а не вести разработку, то есть 
приоритетно удобство сборки

Немного про исключения:
Идея делать бисект в репозитории, в котором только релизные коммиты, не 
очень хороша, потому что нужно смотреть на HEAD. А если обновлять 
upstream до HEAD, так не всё ли равно, в каком каталоге это делать, 
можно и в отдельном.

Безусловно, если вы активно разрабатываете, бисектите, то есть вся 
разработка (или багфикс апстрима) у вас в этом репозитории, то никто же 
не запрещает вести такой репозиторий.
НО не нужно ради гипотетической возможности отлаживать то, что никто 
отлаживать не будет, вести всё в таком виде.

Говоря короче, внесение апстримной разработки в процесс сборки пакета 
— это скорее исключение, чем правило. Особенно для тысяч пакетов, 
собираемых из репозиториев npmjs, pypi, java, gems и т.п.

Возможно, у нас просто разные подопытные.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] пакеты из тарбола легко и удобно собираются в git

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 5243 bytes --]

On Tue, 10 Nov 2020 18:19:09 +0300 Vitaly Lipatov wrote:
> Andrey Savchenko писал 10.11.20 17:27:
> > On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> >> On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> >> 
> >> [...]
> >> > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> >> > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> >> Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола 
> >> в git",
> >> т.к. мне стало так удобнее.
> > 
> > Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> > проблема и нужен git bisect, то внезапно оказывается, что идея
> > с тарболами не такая уж и хорошая.
> Вы правы, но
> 1) bisect по релизам позволит собирать гарантированно собиравшиеся 
> версии.

Ошибка может быть не только в том, что не собирается, а и в том,
что не работает или работает не так как нужно. Вот пожаловался
пользователь: такая-то проблема возникла, а когда-то давно работало.
Без git bisect по полному дереву можно или пойти за верёвкой
и мылом, или послать пользователя. Оба варианта мне не нравятся.

> 2) если речь о бисекте в апстриме (какой коммит сломал что-то к новой 
> версии) — это легко делается в отдельном git-репозитории, 
> синхронизированном с апстримом.

А если в Альте накладываются патчи и бисектить нужно всё сразу,
т.к. не очевидно, кто виноват, а методом тыка поиск займёт
неприемлемое время? Собственно говоря, я не просто так пишу: у меня
подобные случаи регулярно возникают.

> 3) у нас задача — собирать пакеты, а не вести разработку, то есть 
> приоритетно удобство сборки

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

> Немного про исключения:
> Идея делать бисект в репозитории, в котором только релизные коммиты, не 
> очень хороша, потому что нужно смотреть на HEAD. А если обновлять 
> upstream до HEAD, так не всё ли равно, в каком каталоге это делать, 
> можно и в отдельном.

Бисектить нужно не только апстрим, а апстрим + много слоёв патчей.
Посмотрите, например, как glibc у нас устроен.
 
> Безусловно, если вы активно разрабатываете, бисектите, то есть вся 
> разработка (или багфикс апстрима) у вас в этом репозитории, то никто же 
> не запрещает вести такой репозиторий.
> НО не нужно ради гипотетической возможности отлаживать то, что никто 
> отлаживать не будет, вести всё в таком виде.

Согласен, заставлять не нужно.
 
> Говоря короче, внесение апстримной разработки в процесс сборки пакета 
> — это скорее исключение, чем правило. Особенно для тысяч пакетов, 
> собираемых из репозиториев npmjs, pypi, java, gems и т.п.

Мне подобные семейства пакетов представляются важным, но
специфическим частным случаем. Конечно, для них нужны свои средства
автоматизации. Однако, даже там не всё так просто, например, numpy
требует серьёзных патчей на новых архитектурах.

> Возможно, у нас просто разные подопытные.

Да, думаю, что в этом дело. 

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

[devel] git bisect

[Sergey V Turchin]

On Tuesday, 10 November 2020 19:00:57 MSK Andrey Savchenko wrote:

[...]
> git bisect
Да вы хоть тему читайте! Я писал совершенно о другом и bisec там ну вообще не 
в кассу. Там бы git освоить хоть как-то, чтобы понять то, о чем было написано 
в теме письма.

[...]

-- 
Regards, Sergey.

Re: [devel] git bisect

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1386 bytes --]

On Wed, 11 Nov 2020 11:02:36 +0300 Sergey V Turchin wrote:
> On Tuesday, 10 November 2020 19:00:57 MSK Andrey Savchenko wrote:
> 
> [...]
> > git bisect
> Да вы хоть тему читайте! Я писал совершенно о другом и bisec там ну вообще не 
> в кассу. Там бы git освоить хоть как-то, чтобы понять то, о чем было написано 
> в теме письма.

Что не в тему? Какой другой bisect? git bisect только один есть.

Вы написали в исходном письме:
> Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из
> тарбола в git",

Что я понял как «вместо импорта апстримного git в альтовый git
пакета стал импортировать апстримный тарбол в git пакета alt».
Что повергло меня в состояние неописуемого ужаса, особенно с учётом
желания распространить эту практику на других; а так-то это,
безусловно,  личное дело мейнтенера — как ему удобнее поддерживать
пакеты.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] git bisect

[Sergey V Turchin]

On Wednesday, 11 November 2020 12:11:59 MSK Andrey Savchenko wrote:
> On Wed, 11 Nov 2020 11:02:36 +0300 Sergey V Turchin wrote:
> 
> > On Tuesday, 10 November 2020 19:00:57 MSK Andrey Savchenko wrote:
> > 
> > [...]
> > 
> > > git bisect
> > 
> > Да вы хоть тему читайте! Я писал совершенно о другом и bisec там ну вообще
> > не в кассу. Там бы git освоить хоть как-то, чтобы понять то, о чем было
> > написано в теме письма.
> 
> 
> Что не в тему? Какой другой bisect?
SUBJ

[...]
> Что я понял как «вместо импорта апстримного git в альтовый git
> пакета стал импортировать апстримный тарбол в git пакета alt».
> Что повергло меня в состояние неописуемого ужаса,
Пусть уже добъётся до вашего осознания сборка в репозиторий из .src.rpm .

[...]


-- 
Regards, Sergey.

[devel] Offtopic: git bisect (Was: пакеты из тарбола легко и удобно собираются в git)

[Vladimir D. Seleznev]

On Tue, Nov 10, 2020 at 05:27:37PM +0300, Andrey Savchenko wrote:
> On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> > On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> > 
> > [...]
> > > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> > Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
> > т.к. мне стало так удобнее.
> 
> Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> проблема и нужен git bisect, то внезапно оказывается, что идея
> с тарболами не такая уж и хорошая.

Хотя это оффтопик, но скажу, что бисектить можно апстримный
git-репозиторий вне контекста gear и, что более важное, бисектить
репозитории с отдельными неналоженными патчами гораздо удобнее, чем с
уже наложенными на код.


-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Offtopic: git bisect (Was: пакеты из тарбола легко и удобно собираются в git)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]

On Wed, 11 Nov 2020 16:24:28 +0300 Vladimir D. Seleznev wrote:
> On Tue, Nov 10, 2020 at 05:27:37PM +0300, Andrey Savchenko wrote:
> > On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> > > On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> > > 
> > > [...]
> > > > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > > > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> > > Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
> > > т.к. мне стало так удобнее.
> > 
> > Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> > проблема и нужен git bisect, то внезапно оказывается, что идея
> > с тарболами не такая уж и хорошая.
> 
> Хотя это оффтопик, но скажу, что бисектить можно апстримный
> git-репозиторий вне контекста gear и, что более важное, бисектить
> репозитории с отдельными неналоженными патчами гораздо удобнее, чем с
> уже наложенными на код.

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

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Offtopic: git bisect (Was: пакеты из тарбола легко и удобно собираются в git)

[Vladimir D. Seleznev]

On Wed, Nov 11, 2020 at 04:33:49PM +0300, Andrey Savchenko wrote:
> On Wed, 11 Nov 2020 16:24:28 +0300 Vladimir D. Seleznev wrote:
> > On Tue, Nov 10, 2020 at 05:27:37PM +0300, Andrey Savchenko wrote:
> > > On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> > > > On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> > > > 
> > > > [...]
> > > > > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > > > > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> > > > Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
> > > > т.к. мне стало так удобнее.
> > > 
> > > Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> > > проблема и нужен git bisect, то внезапно оказывается, что идея
> > > с тарболами не такая уж и хорошая.
> > 
> > Хотя это оффтопик, но скажу, что бисектить можно апстримный
> > git-репозиторий вне контекста gear и, что более важное, бисектить
> > репозитории с отдельными неналоженными патчами гораздо удобнее, чем с
> > уже наложенными на код.
> 
> Почему? Вот есть апстримный код, на который наложены десятки или
> даже сотня патчей. Я не знаю, что из них ломает код. Я просто пишу
> тестовый скрипт, запускаю git bisect и занимаюсь другими делами,
> пока git сам мне ищет проблемный коммит.

Ты пишешь про бисект патчей, я думал, ты пишешь про апстримный код.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Offtopic: git bisect (Was: пакеты из тарбола легко и удобно собираются в git)

[Alexey V. Vissarionov]

On 2020-11-11 17:08:51 +0300, Vladimir D. Seleznev wrote:

 >>> Хотя это оффтопик, но скажу, что бисектить можно апстримный
 >>> git-репозиторий вне контекста gear и, что более важное,
 >>> бисектить репозитории с отдельными неналоженными патчами
 >>> гораздо удобнее, чем с уже наложенными на код.
 >> Почему? Вот есть апстримный код, на который наложены десятки
 >> или даже сотня патчей. Я не знаю, что из них ломает код.
 >> Я просто пишу тестовый скрипт, запускаю git bisect и занимаюсь
 >> другими делами, пока git сам мне ищет проблемный коммит.
 > Ты пишешь про бисект патчей, я думал, ты пишешь про апстримный
 > код.

Да какая разница? Вот код, вот последовательность сделанных кем-то
(разработчиком или мейнтейнером, без разницы) изменений - задача в
том, чтобы найти проблемный коммит.

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


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] Offtopic: git bisect (Was: пакеты из тарбола легко и удобно собираются в git)

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 2420 bytes --]

On Wed, 11 Nov 2020 17:08:51 +0300 Vladimir D. Seleznev wrote:
> On Wed, Nov 11, 2020 at 04:33:49PM +0300, Andrey Savchenko wrote:
> > On Wed, 11 Nov 2020 16:24:28 +0300 Vladimir D. Seleznev wrote:
> > > On Tue, Nov 10, 2020 at 05:27:37PM +0300, Andrey Savchenko wrote:
> > > > On Tue, 10 Nov 2020 16:01:33 +0300 Sergey V Turchin wrote:
> > > > > On Tuesday, 10 November 2020 15:41:55 MSK Vitaly Lipatov wrote:
> > > > > 
> > > > > [...]
> > > > > > Так же хочу напомнить, что ассоциация сборки из тарбола со сборкой из
> > > > > > srpm является ложной: пакеты из тарбола легко и удобно собираются в git.
> > > > > Да я вообще сборку всего Qt5/KDE5 перевёл с "git в git" на "из тарбола в git", 
> > > > > т.к. мне стало так удобнее.
> > > > 
> > > > Это удобнее пока отладку делать не нужно, а как возникает серьёзная
> > > > проблема и нужен git bisect, то внезапно оказывается, что идея
> > > > с тарболами не такая уж и хорошая.
> > > 
> > > Хотя это оффтопик, но скажу, что бисектить можно апстримный
> > > git-репозиторий вне контекста gear и, что более важное, бисектить
> > > репозитории с отдельными неналоженными патчами гораздо удобнее, чем с
> > > уже наложенными на код.
> > 
> > Почему? Вот есть апстримный код, на который наложены десятки или
> > даже сотня патчей. Я не знаю, что из них ломает код. Я просто пишу
> > тестовый скрипт, запускаю git bisect и занимаюсь другими делами,
> > пока git сам мне ищет проблемный коммит.
> 
> Ты пишешь про бисект патчей, я думал, ты пишешь про апстримный код.

Я пишу про bisect кода не разделяя его на апстримный и
дополнительные патчи. 


Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Перевод пакетов на python3-module-

[Vladimir D. Seleznev]

On Tue, Nov 10, 2020 at 03:41:55PM +0300, Vitaly Lipatov wrote:
> У меня большая просьба к переводящим пакеты на python3: делать это не 
> как попало (т.е. как вам кажется правильным), а единообразно (т.е. как 
> мне кажется правильным).
> 
> В качестве примера предлагаю посмотреть на спек
> https://packages.altlinux.org/ru/sisyphus/specfiles/python3-module-incremental

Я таки покритикую.

Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
логов сборки? Лучше, кмк, писать %python3_build, и использовать
%python3_build_debug только при отладке сборки.

%python3_prune выглядит очень смелым решением.

Зачем комментировать BuildPreReq:... вместо удаления?

%__pypi_url нигде не определён.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Перевод пакетов на python3-module-

[Vitaly Lipatov]

Vladimir D. Seleznev писал 21.11.20 5:59:
> On Tue, Nov 10, 2020 at 03:41:55PM +0300, Vitaly Lipatov wrote:
>> У меня большая просьба к переводящим пакеты на python3: делать это не
>> как попало (т.е. как вам кажется правильным), а единообразно (т.е. как
>> мне кажется правильным).
>> 
>> В качестве примера предлагаю посмотреть на спек
>> https://packages.altlinux.org/ru/sisyphus/specfiles/python3-module-incremental
> 
> Я таки покритикую.
Это хорошо :)

> Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
> логов сборки? Лучше, кмк, писать %python3_build, и использовать
> %python3_build_debug только при отладке сборки.
А я не знаю, зачем это стали использовать. Мне казалось, что при 
компиляции C-кода это добавляет -g и появляется возможность отлаживать 
код, установив -debuginfo.


> %python3_prune выглядит очень смелым решением.
И отлично работает, заметьте.

> Зачем комментировать BuildPreReq:... вместо удаления?
В какой-то момент в сборки python-пакетов просочились
python3-devel (не ясно, кому они нужны)
и
python3-module-setuptools (требуется ли вообще когда-либо его явно 
указывать?)

> %__pypi_url нигде не определён.
Конечно же он определён в rpm-build-intro.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Перевод пакетов на python3-module-

[Vladimir D. Seleznev]

On Sat, Nov 21, 2020 at 02:34:45PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.11.20 5:59:
> > On Tue, Nov 10, 2020 at 03:41:55PM +0300, Vitaly Lipatov wrote:
> >> У меня большая просьба к переводящим пакеты на python3: делать это не
> >> как попало (т.е. как вам кажется правильным), а единообразно (т.е. как
> >> мне кажется правильным).
> >> 
> >> В качестве примера предлагаю посмотреть на спек
> >> https://packages.altlinux.org/ru/sisyphus/specfiles/python3-module-incremental
> > 
> > Я таки покритикую.
> Это хорошо :)
> 
> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
> > %python3_build_debug только при отладке сборки.
> А я не знаю, зачем это стали использовать. Мне казалось, что при 
> компиляции C-кода это добавляет -g и появляется возможность отлаживать 
> код, установив -debuginfo.

$ rpm -E '%python3_build'

		CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ; 
	CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ; 
	FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ; 
	/usr/bin/python3 setup.py build

$ rpm -E '%python3_build_debug'

		CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ;
	CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ;
	FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ;
	/usr/bin/python3 setup.py build --debug

Как видно, %python3_build_debug не про -g.

> > %python3_prune выглядит очень смелым решением.
> И отлично работает, заметьте.

Пока не удалится то, чего никто не намеревался удалять из-за того, что
имя неудачное оказалось.

> > Зачем комментировать BuildPreReq:... вместо удаления?
> В какой-то момент в сборки python-пакетов просочились python3-devel
> (не ясно, кому они нужны) и python3-module-setuptools (требуется ли
> вообще когда-либо его явно указывать?)

Если они нужны, то оставьте раскомментированными. Если не нужны — то
удалите комментарий.

> > %__pypi_url нигде не определён.
> Конечно же он определён в rpm-build-intro.

Действительно, не заметил.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Перевод пакетов на python3-module-

[Vitaly Lipatov]

Vladimir D. Seleznev писал 21.11.20 15:21:
...
>> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
>> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
>> > %python3_build_debug только при отладке сборки.
>> А я не знаю, зачем это стали использовать. Мне казалось, что при
>> компиляции C-кода это добавляет -g и появляется возможность отлаживать
>> код, установив -debuginfo.
> 
> 	/usr/bin/python3 setup.py build --debug
> 
> Как видно, %python3_build_debug не про -g.
Options for 'build' command:
Или про -g? :)
  --debug (-g)       compile extensions and libraries with debugging
                     information
Вы скажите прямо: эта отладочная информация не нужна, не нужно 
использовать python3_build_debug. Но сложно понять, как получить 
отладочную информацию, если не включаешь флаг «with debugging 
information».

> 
>> > %python3_prune выглядит очень смелым решением.
>> И отлично работает, заметьте.
> 
> Пока не удалится то, чего никто не намеревался удалять из-за того, что
> имя неудачное оказалось.
И что же случится? Машина наедет на человека? Атомный взрыв? Холодная 
война?
Не случится ничего.
Есть большое отличие между реализацией простого инструмента, решающего 
проблемы во всех известных случаях (и который может не сработать при 
специально подобранных данных) и реализацией критически важной системы, 
для которой тестируются все возможные состояния.

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

Возможно, чтобы это понять, нужно предварительно разработать систему, от 
правильности работы которой зависит жизнь человека или корабля.

>> > Зачем комментировать BuildPreReq:... вместо удаления?
>> В какой-то момент в сборки python-пакетов просочились python3-devel
>> (не ясно, кому они нужны) и python3-module-setuptools (требуется ли
>> вообще когда-либо его явно указывать?)
> 
> Если они нужны, то оставьте раскомментированными. Если не нужны — то
> удалите комментарий.
...

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] %python3_build_debug

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.11.20 15:21:
> ...
> >> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
> >> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
> >> > %python3_build_debug только при отладке сборки.
> >> А я не знаю, зачем это стали использовать. Мне казалось, что при
> >> компиляции C-кода это добавляет -g и появляется возможность отлаживать
> >> код, установив -debuginfo.
> > 
> > 	/usr/bin/python3 setup.py build --debug
> > 
> > Как видно, %python3_build_debug не про -g.
> Options for 'build' command:
> Или про -g? :)
>   --debug (-g)       compile extensions and libraries with debugging
>                      information
> Вы скажите прямо: эта отладочная информация не нужна, не нужно 
> использовать python3_build_debug. Но сложно понять, как получить 
> отладочную информацию, если не включаешь флаг «with debugging 
> information».

Отладочная информация (-g) настраивается в другом месте, не имеющем
никакого отношения к питону.  По умолчанию -g уже включена в %optflags.

Что меняет %python3_build_debug по сравнению с %python3_build?


-- 
ldv

Re: [devel] %python3_build_debug

[Vitaly Lipatov]

Dmitry V. Levin писал 21.11.20 16:31:
> On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
...
> Отладочная информация (-g) настраивается в другом месте, не имеющем
> никакого отношения к питону.  По умолчанию -g уже включена в %optflags.
> 
> Что меняет %python3_build_debug по сравнению с %python3_build?

Проверил на пакете python3-module-Pillow

--debug добавляет больше отладочного вывода:
+Looking for xcb
+Checking for include file xcb/xcb.h in /usr/include/freetype2
+Checking for include file xcb/xcb.h in /usr/include/openjpeg-2.3
+Checking for include file xcb/xcb.h in 
/usr/src/RPM/BUILD/python3-module-Pillow-7.2.0/src/libImaging
+Checking for include file xcb/xcb.h in 
/usr/src/RPM/BUILD/python3-module-Pillow-7.2.0
+Checking for include file xcb/xcb.h in /usr/include
+Checking for include file xcb/xcb.h in /usr/local/include
+Checking for include file xcb/xcb.h in /usr/include/python3.8


и добавляет четвёртый флаг -g при компиляции:
-x86_64-alt-linux-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O3 -Wall -pipe -frecord-gcc-switches -Wall -g -O3 
-pipe -frecord-gcc-switches -Wall -g -O2 -fPIC -DHAVE_LIBJPEG 
-DHAVE_OPENJPEG -DHAVE_LIBZ -DHAVE_LIBIMAGEQUANT -DHAVE_L
+x86_64-alt-linux-gcc -pthread -Wno-unused-result -Wsign-compare 
-DNDEBUG -g -fwrapv -O3 -Wall -pipe -frecord-gcc-switches -Wall -g -O3 
-pipe -frecord-gcc-switches -Wall -g -O2 -fPIC -g -DHAVE_LIBJPEG 
-DHAVE_OPENJPEG

Соответственно, для пакетов без компиляции не меняется ничего.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] %python3_build_debug

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 07:52:38PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 21.11.20 16:31:
> > On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
> ...
> > Отладочная информация (-g) настраивается в другом месте, не имеющем
> > никакого отношения к питону.  По умолчанию -g уже включена в %optflags.
> > 
> > Что меняет %python3_build_debug по сравнению с %python3_build?
> 
> Проверил на пакете python3-module-Pillow
> 
> --debug добавляет больше отладочного вывода:
> +Looking for xcb
> +Checking for include file xcb/xcb.h in /usr/include/freetype2
> +Checking for include file xcb/xcb.h in /usr/include/openjpeg-2.3
> +Checking for include file xcb/xcb.h in 
> /usr/src/RPM/BUILD/python3-module-Pillow-7.2.0/src/libImaging
> +Checking for include file xcb/xcb.h in 
> /usr/src/RPM/BUILD/python3-module-Pillow-7.2.0
> +Checking for include file xcb/xcb.h in /usr/include
> +Checking for include file xcb/xcb.h in /usr/local/include
> +Checking for include file xcb/xcb.h in /usr/include/python3.8
> 
> 
> и добавляет четвёртый флаг -g при компиляции:
> -x86_64-alt-linux-gcc -pthread -Wno-unused-result -Wsign-compare 
> -DNDEBUG -g -fwrapv -O3 -Wall -pipe -frecord-gcc-switches -Wall -g -O3 
> -pipe -frecord-gcc-switches -Wall -g -O2 -fPIC -DHAVE_LIBJPEG 
> -DHAVE_OPENJPEG -DHAVE_LIBZ -DHAVE_LIBIMAGEQUANT -DHAVE_L
> +x86_64-alt-linux-gcc -pthread -Wno-unused-result -Wsign-compare 
> -DNDEBUG -g -fwrapv -O3 -Wall -pipe -frecord-gcc-switches -Wall -g -O3 
> -pipe -frecord-gcc-switches -Wall -g -O2 -fPIC -g -DHAVE_LIBJPEG 
> -DHAVE_OPENJPEG

Вот четвёртого-то флага -g нам как раз и не хватало.
А ещё мне понравилось чередование -O3 и -O2.

> Соответственно, для пакетов без компиляции не меняется ничего.

А для пакетов с компиляцией меняется только запись, которую делает
-frecord-gcc-switches.


-- 
ldv

Re: [devel] %python3_build_debug

[Vitaly Lipatov]

Dmitry V. Levin писал 21.11.20 20:01:
...
> Вот четвёртого-то флага -g нам как раз и не хватало.
> А ещё мне понравилось чередование -O3 и -O2.
Тогда
https://bugzilla.altlinux.org/show_bug.cgi?id=39329

Я бы предпочёл отсутствие различий в сборке модулей python через прямой 
запуск setup.py build и через спек, поскольку и то и то является сборкой 
в дистрибутиве.

%python3_setup() \
     %global _buildrequires_build %_buildrequires_build 
%python3_setup_buildrequires \
     CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ;
...

>> Соответственно, для пакетов без компиляции не меняется ничего.
> 
> А для пакетов с компиляцией меняется только запись, которую делает
> -frecord-gcc-switches.

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] %python3_build_debug

[Vladimir D. Seleznev]

On Sat, Nov 21, 2020 at 07:52:38PM +0300, Vitaly Lipatov wrote:
> Dmitry V. Levin писал 21.11.20 16:31:
> > On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
> ...
> > Отладочная информация (-g) настраивается в другом месте, не имеющем
> > никакого отношения к питону.  По умолчанию -g уже включена в %optflags.
> > 
> > Что меняет %python3_build_debug по сравнению с %python3_build?
> 
> Проверил на пакете python3-module-Pillow
> 
> --debug добавляет больше отладочного вывода:

Это я и имел в виду, когда писал про увеличение содержимого логов
сборки.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] %python3_build_debug

[Vitaly Lipatov]

Vladimir D. Seleznev писал 22.11.20 7:44:
> On Sat, Nov 21, 2020 at 07:52:38PM +0300, Vitaly Lipatov wrote:
>> Dmitry V. Levin писал 21.11.20 16:31:
>> > On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
>> ...
>> > Отладочная информация (-g) настраивается в другом месте, не имеющем
>> > никакого отношения к питону.  По умолчанию -g уже включена в %optflags.
>> >
>> > Что меняет %python3_build_debug по сравнению с %python3_build?
>> 
>> Проверил на пакете python3-module-Pillow
>> 
>> --debug добавляет больше отладочного вывода:
> 
> Это я и имел в виду, когда писал про увеличение содержимого логов
> сборки.
Но мы же не прячем вывод configure, может быть, есть смысл всегда видеть 
и эти попытки поиска.
На фоне множества строк, где файлы python копируют и компилируют, это 
вроде даже выглядит осмысленной информацией.

Я бы поступил так:
1. python3_build_debug признал устаревшим и рекомендовал использовать 
python3_build_debug.
2. в python3_build добавил --debug

Либо ваш вариант:
1. использовать python3_build
2. в случае необходимости отладки мантейнер включает для себя временно 
python3_build_debug

-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Перевод пакетов на python3-module-

[Vladimir D. Seleznev]

On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.11.20 15:21:
> ...
> >> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
> >> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
> >> > %python3_build_debug только при отладке сборки.
> >> А я не знаю, зачем это стали использовать. Мне казалось, что при
> >> компиляции C-кода это добавляет -g и появляется возможность отлаживать
> >> код, установив -debuginfo.
> > 
> > 	/usr/bin/python3 setup.py build --debug
> > 
> > Как видно, %python3_build_debug не про -g.
> Options for 'build' command:
> Или про -g? :)
>   --debug (-g)       compile extensions and libraries with debugging
>                      information
> Вы скажите прямо: эта отладочная информация не нужна, не нужно 
> использовать python3_build_debug. Но сложно понять, как получить 
> отладочную информацию, если не включаешь флаг «with debugging 
> information».

Ещё раз посмотрите на вывод команды:

$ rpm -E '%python3_build'

		CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ;
	CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ;
	FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ;
	/usr/bin/python3 setup.py build

В CFLAGS'ах -g, именно из-за этого флага порождается отладочная
информация, которая потом попадает в debuginfo-подпакеты.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] Перевод пакетов на python3-module-

[Vitaly Lipatov]

Vladimir D. Seleznev писал 21.11.20 16:45:
> On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
>> Vladimir D. Seleznev писал 21.11.20 15:21:
>> ...
>> >> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
>> >> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
>> >> > %python3_build_debug только при отладке сборки.
>> >> А я не знаю, зачем это стали использовать. Мне казалось, что при
>> >> компиляции C-кода это добавляет -g и появляется возможность отлаживать
>> >> код, установив -debuginfo.
>> >
>> > 	/usr/bin/python3 setup.py build --debug
>> >
>> > Как видно, %python3_build_debug не про -g.
>> Options for 'build' command:
>> Или про -g? :)
>>   --debug (-g)       compile extensions and libraries with debugging
>>                      information
>> Вы скажите прямо: эта отладочная информация не нужна, не нужно
>> использовать python3_build_debug. Но сложно понять, как получить
>> отладочную информацию, если не включаешь флаг «with debugging
>> information».
> 
> Ещё раз посмотрите на вывод команды:
> 
> $ rpm -E '%python3_build'
> 
> 		CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ;
> 	CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ;
> 	FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ;
> 	/usr/bin/python3 setup.py build
> 
> В CFLAGS'ах -g, именно из-за этого флага порождается отладочная
> информация, которая потом попадает в debuginfo-подпакеты.

Я вам совсем о другом пишу. Но по какой причине вы думаете, что я не 
вижу, и тем более не знаю, как этот макрос устроен?

Но какой смысл имеет добавление -g -O2 в *FLAGS в этом макросе, если:

Dmitry V. Levin писал 21.11.20 16:31:
...
> Отладочная информация (-g) настраивается в другом месте, не имеющем
> никакого отношения к питону.  По умолчанию -g уже включена в %optflags.


-- 
С уважением,
Виталий Липатов,
ALT Linux Team

Re: [devel] Перевод пакетов на python3-module-

[Dmitry V. Levin]

On Sat, Nov 21, 2020 at 07:07:14PM +0300, Vitaly Lipatov wrote:
> Vladimir D. Seleznev писал 21.11.20 16:45:
> > On Sat, Nov 21, 2020 at 04:01:40PM +0300, Vitaly Lipatov wrote:
> >> Vladimir D. Seleznev писал 21.11.20 15:21:
> >> ...
> >> >> > Зачем использовать %python3_build_debug? Чтобы увеличить содержимое
> >> >> > логов сборки? Лучше, кмк, писать %python3_build, и использовать
> >> >> > %python3_build_debug только при отладке сборки.
> >> >> А я не знаю, зачем это стали использовать. Мне казалось, что при
> >> >> компиляции C-кода это добавляет -g и появляется возможность отлаживать
> >> >> код, установив -debuginfo.
> >> >
> >> > 	/usr/bin/python3 setup.py build --debug
> >> >
> >> > Как видно, %python3_build_debug не про -g.
> >> Options for 'build' command:
> >> Или про -g? :)
> >>   --debug (-g)       compile extensions and libraries with debugging
> >>                      information
> >> Вы скажите прямо: эта отладочная информация не нужна, не нужно
> >> использовать python3_build_debug. Но сложно понять, как получить
> >> отладочную информацию, если не включаешь флаг «with debugging
> >> information».
> > 
> > Ещё раз посмотрите на вывод команды:
> > 
> > $ rpm -E '%python3_build'
> > 
> > 		CFLAGS="${CFLAGS:--O2 -g}" ; export CFLAGS ;
> > 	CXXFLAGS="${CXXFLAGS:--O2 -g}" ; export CXXFLAGS ;
> > 	FFLAGS="${FFLAGS:--O2 -g}" ; export FFLAGS ;
> > 	/usr/bin/python3 setup.py build
> > 
> > В CFLAGS'ах -g, именно из-за этого флага порождается отладочная
> > информация, которая потом попадает в debuginfo-подпакеты.
> 
> Я вам совсем о другом пишу. Но по какой причине вы думаете, что я не 
> вижу, и тем более не знаю, как этот макрос устроен?
> 
> Но какой смысл имеет добавление -g -O2 в *FLAGS в этом макросе, если:

Нет, -g -O2 добавляется в *FLAGS совсем в другом макросе:

$ rpmbuild --showrc |grep python3_build
-14: python3_build	%{python3_setup:} build
-14: python3_build_debug	%{python3_setup:} build --debug
-14: python3_build_install	%{python3_setup:} install --root=%buildroot --force

$ rpmbuild --showrc |sed -n '/ python3_setup/,/^-/p'
-14: python3_setup	
	%global _buildrequires_build %_buildrequires_build %python3_setup_buildrequires 
	CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; 
	CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; 
	FFLAGS="${FFLAGS:-%optflags}" ; export FFLAGS ; 
	%__python3 setup.py
-14: python3_setup_buildrequires	python3-module-setuptools

На мой вопрос о том, чем по сути отличается %python3_build_debug
от %python3_build, пока ещё никто не ответил.


-- 
ldv