[devel] Спасём python3 вместе! (действительно) - Stable ABI

[devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

Всем привет!

Последние таски по обновлению Python выглядят пугающее: объем
пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
обновление самого Python в Sisyphus происходит дольше, чем в апстриме...

Я прошу обратить внимание на эту проблему куда большую часть сообщества
и принять хоть какое-нибудь решение, которое не оставит все как есть.

А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
момент предложенное. Читать тут:
https://bugzilla.altlinux.org/show_bug.cgi?id=55340#c5
https://bugzilla.altlinux.org/56201

Сейчас чуть подробнее введу в курс (небольшая, но важная выжимка из
https://docs.python.org/3/c-api/stable.html).

* Stable ABI — это набор символов в CPython, которые остаются бинарно-
  совместимыми для различных минорных версий Python 3.X. Экстеншн,
  собранный под Stable ABI (и правильно использующий Limited API),
  должен работать без пересборки на всех минорных версиях Python,
  начиная с той, для которой он был скомпилирован.
  Такие модули часто имеют в имени файла тег abi3
  (например, mymodule.abi3.so)

* Limited C API — это подмножество C API Python, использование
  которого гарантирует совместимость с Stable ABI.

* Интерпретатор Python не проверяет, действительно ли модуль с тегом
  abi3 соответствует Stable ABI. Ответственность за обеспечение
  корректности лежит на мейнтейнере.

В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
соблюдают Stable ABI) и собранные для конкретной минорной версии
Python. Текущая идея сборки компилируемых модулей заключается в том,
чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
приводит к тому, что у нас сейчас при обновлении Python мучается один
бедный grenka, а все сидят и смотрят на это в ожидании окончания
(кто-то даже успевает продлять ему муки).

В общем, идея решения заключается в том, чтобы для модулей, собираемых
под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
что там действительно Stable ABI. Для этого есть инструмент abi3audit,
собираемый в этом задании: https://packages.altlinux.org/tasks/396283

-- 
Anton Zhukharev
ALT Linux Team

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

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Grigory Ustinov]

02.10.2025 16:44, Anton Zhukharev пишет:
> Всем привет!
>
> Последние таски по обновлению Python выглядят пугающее: объем
> пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
Sisyphus происходит дольше по абсолютно другим причинам.
> Я прошу обратить внимание на эту проблему куда большую часть сообщества
> и принять хоть какое-нибудь решение, которое не оставит все как есть.
>
> А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> момент предложенное.
Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
> В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> соблюдают Stable ABI) и собранные для конкретной минорной версии
> Python. Текущая идея сборки компилируемых модулей заключается в том,
> чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> приводит к тому, что у нас сейчас при обновлении Python мучается один
> бедный grenka, а все сидят и смотрят на это в ожидании окончания
> (кто-то даже успевает продлять ему муки).
>
> В общем, идея решения заключается в том, чтобы для модулей, собираемых
> под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> собираемый в этом задании: https://packages.altlinux.org/tasks/396283
Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
> 02.10.2025 16:44, Anton Zhukharev пишет:
> > Всем привет!
> >
> > Последние таски по обновлению Python выглядят пугающее: объем
> > пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> > обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
> Sisyphus происходит дольше по абсолютно другим причинам.
Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
следующей минорной версии, поскольку текущему образу сборки обязательно
требуется фриз сборочницы.

Перечислите все причины, которые, по вашему утверждению, затягивают
обновление.
> > Я прошу обратить внимание на эту проблему куда большую часть сообщества
> > и принять хоть какое-нибудь решение, которое не оставит все как есть.
> >
> > А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> > момент предложенное.
> Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
Да, поэтому текущее подобное решение в Sisyphus и предлагается изменить.
> > В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> > соблюдают Stable ABI) и собранные для конкретной минорной версии
> > Python. Текущая идея сборки компилируемых модулей заключается в том,
> > чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> > приводит к тому, что у нас сейчас при обновлении Python мучается один
> > бедный grenka, а все сидят и смотрят на это в ожидании окончания
> > (кто-то даже успевает продлять ему муки).
> >
> > В общем, идея решения заключается в том, чтобы для модулей, собираемых
> > под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> > что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> > собираемый в этом задании: https://packages.altlinux.org/tasks/396283
> Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?
38 пакетов в текущий момент собраны под Stable ABI.

Это количество можно попробовать увеличить, просто передав
-DPy_LIMITED_API=0x03000000 компилятору во время сборки экстеншена.

-- 
Anton Zhukharev
ALT Linux Team

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

Re: [devel] Спасём python3 вместе! (действительно) - Stable ABI

[Anton Zhukharev]

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

On Fri, Oct 03, 2025 at 09:18:39AM +0300, Anton Zhukharev wrote:
> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
> > 02.10.2025 16:44, Anton Zhukharev пишет:
> > > Всем привет!
> > >
> > > Последние таски по обновлению Python выглядят пугающее: объем
> > > пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
> > > обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
> > Меня объём пересобираемых пакетов не пугает. Обновление самого Python в 
> > Sisyphus происходит дольше по абсолютно другим причинам.
> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
> следующей минорной версии, поскольку текущему образу сборки обязательно
> требуется фриз сборочницы.
Извиняюсь за такую формулировку: фриз происходит на последнем этапе
сборки таска, а не на протяжении всего существования таска с обновлением
Python. 
> Перечислите все причины, которые, по вашему утверждению, затягивают
> обновление.
> > > Я прошу обратить внимание на эту проблему куда большую часть сообщества
> > > и принять хоть какое-нибудь решение, которое не оставит все как есть.
> > >
> > > А под "хоть какое-нибудь решение" я имею ввиду единственное, на данный
> > > момент предложенное.
> > Вот из-за таких "хоть каких-нибудь решений" обновление Python и затянулось.
> Да, поэтому текущее подобное решение в Sisyphus и предлагается изменить.
> > > В Sisyphus сейчас есть модули с тэгом abi3 (будем надеятся, что они
> > > соблюдают Stable ABI) и собранные для конкретной минорной версии
> > > Python. Текущая идея сборки компилируемых модулей заключается в том,
> > > чтобы везде ставить зависимость на %python3_ABI_dep. Естественно, это
> > > приводит к тому, что у нас сейчас при обновлении Python мучается один
> > > бедный grenka, а все сидят и смотрят на это в ожидании окончания
> > > (кто-то даже успевает продлять ему муки).
> > >
> > > В общем, идея решения заключается в том, чтобы для модулей, собираемых
> > > под Stable ABI эту зависимость не генерировать и как-нибудь проверять,
> > > что там действительно Stable ABI. Для этого есть инструмент abi3audit,
> > > собираемый в этом задании: https://packages.altlinux.org/tasks/396283
> > Я правильно понимаю, что всё что выше написано касается всего 38 пакетов?
> 38 пакетов в текущий момент собраны под Stable ABI.
> 
> Это количество можно попробовать увеличить, просто передав
> -DPy_LIMITED_API=0x03000000 компилятору во время сборки экстеншена.
Здесь, если что, место, которое нужно обсуждать.
Просто воткнуть 0x0300000 (то есть версию 3.0) и радоваться не
получится.

-- 
Anton Zhukharev
ALT Linux Team

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

Re: [devel] Затянувшийся фриз сборочницы

[Grigory Ustinov]

03.10.2025 9:18, Anton Zhukharev пишет:
> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>> Всем привет!
>>>
>>> Последние таски по обновлению Python выглядят пугающее: объем
>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за чего
>>> обновление самого Python в Sisyphus происходит дольше, чем в апстриме...
>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>> Sisyphus происходит дольше по абсолютно другим причинам.
> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
> следующей минорной версии, поскольку текущему образу сборки обязательно
> требуется фриз сборочницы.
>
> Перечислите все причины, которые, по вашему утверждению, затягивают
> обновление.

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

Сначала таск был сломан очень несвоевременным обновлением libfmt. Только 
всё разрулили, и тут с двух ног влетел Cython. Решили проблемы и с ним. 
Сейчас таск уже почти неделю в полностью готовом состоянии не может 
пройти из-за нехватки ресурсов на архитектурах i586 и aarch64. Проблема 
не в количестве пакетов, а в том, что крупные пакеты типа llvm, blender, 
vtk и тому подобные собираются вероятностно. Учитывая, что сборка идёт 
на коммит, кэширования результатов нет и имеем что имеем. 3 дня таск 
собирается, потом падает со словами
[aarch64] hasher-privd: parent: handle_io: idle time limit (3600 
seconds) exceeded

В предыдущих обновлениях python3 эта проблема была не так сильно 
выражена. Возможно имеет смысл в следующем обновлении сформировать 
список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
началу, но это не всегда возможно, поскольку обычно они требуют немалые 
деревья пакетов.

Re: [devel] Затянувшийся фриз сборочницы

[Leonid Krivoshein]

Всем привет!


On 10/5/25 13:46, Grigory Ustinov wrote:
> 03.10.2025 9:18, Anton Zhukharev пишет:
>> On Thu, Oct 02, 2025 at 10:45:34PM +0300, Grigory Ustinov wrote:
>>> 02.10.2025 16:44, Anton Zhukharev пишет:
>>>> Всем привет!
>>>>
>>>> Последние таски по обновлению Python выглядят пугающее: объем
>>>> пересобираемых пакетов невероятно огромный и постоянно растет из-за 
>>>> чего
>>>> обновление самого Python в Sisyphus происходит дольше, чем в 
>>>> апстриме...
>>> Меня объём пересобираемых пакетов не пугает. Обновление самого Python в
>>> Sisyphus происходит дольше по абсолютно другим причинам.
>> Не всем нравится сидеть и ждать (уже) годами, пока вы обновите Python до
>> следующей минорной версии, поскольку текущему образу сборки обязательно
>> требуется фриз сборочницы.
>>
>> Перечислите все причины, которые, по вашему утверждению, затягивают
>> обновление.
>
> Пожалуй всё-таки имеет смысл вкратце зарезюмировать текущую ситуацию. 
> В этом году фриз сборочницы действительно затянулся на неприлично 
> длительное время.

Как я понимаю, "фриз" -- это перевод всех собираемых тасков без 
test-only в состояние POSTPONED, когда третья попытка закоммитить 
успешно собравшийся большой таск провалилась, этот "фриз" нужен для 
прохождения в репозиторий одного большого таска, верно?


> У всех ожидающих прошу прощения и немного понимания. Я жду его 
> окончания не меньше вашего и почти в круглосуточном режиме слежу за 
> таском, делая всё, что в моих силах для его скорейшего прохождения.
>
> Сначала таск был сломан очень несвоевременным обновлением libfmt. 
> Только всё разрулили, и тут с двух ног влетел Cython. Решили проблемы 
> и с ним. Сейчас таск уже почти неделю в полностью готовом состоянии не 
> может пройти из-за нехватки ресурсов на архитектурах i586 и aarch64. 
> Проблема не в количестве пакетов, а в том, что крупные пакеты типа 
> llvm, blender, vtk и тому подобные собираются вероятностно. Учитывая, 
> что сборка идёт на коммит, кэширования результатов нет и имеем что 
> имеем. 3 дня таск собирается, потом падает со словами
> [aarch64] hasher-privd: parent: handle_io: idle time limit (3600 
> seconds) exceeded
>
> В предыдущих обновлениях python3 эта проблема была не так сильно 
> выражена. Возможно имеет смысл в следующем обновлении сформировать 
> список пересборки таким образом, чтобы "тяжёлые" пакеты шли поближе к 
> началу, но это не всегда возможно, поскольку обычно они требуют 
> немалые деревья пакетов.
>

Можно внести пару усовершенствований:

1. Поменять приоритет. Он должен быть не у того таска, который *первым 
успешно собрался*, а у того, кто будучи успешно собранным *первым начал 
сборку*. Тогда будет достаточно пересобрать на новом состоянии 
репозитория менее ёмкие таски, уже успешно собравшиеся, и даже попавшие 
в архив. В этом случае их можно удалить из архива. Ёмкость таска можно 
определить по суммарному времени его сборки.

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


-- 
WBR, Leonid Krivoshein.