(Ответ для Alexey Sheplyakov на комментарий #0)
> configure скрипт python (версии 3.10) пытается собрать сведения о платформе
> для модуля sysconfig, и на LoongArch это у него не получается. В результате
> ломается сборка модулей расширения, написанных на C, C++ (и прочих
> компилируемых языках).

А также в python3 зависит от nis (libnsl2), а на "новых" архитектурах этого отголоска 80-х нет

The following changes since commit 5258f22e54659a329155fb8ef3b44c15f169629a:

  3.10.8-alt1.1 (2022-12-17 18:34:54 +0700)

are available in the Git repository at:

  http://git.altlinux.org/people/asheplyakov/packages/python3.git loongarch64

for you to fetch changes up to fa13b5177a9da313203b58f465dd59a057dfd302:

  3.10.8-alt1.2 (2023-05-17 08:41:20 +0400)

----------------------------------------------------------------
Alexey Sheplyakov (4):
      spec: a few tweaks for loongarch64
      spec: fixed build without tk
      spec: simplified the initial build
      3.10.8-alt1.2

Zhang Na (1):
      bpo-46498: Add Platform triplets for LoongArch64

 python3.spec         | 57 +++++++++++++++++++++++++++++++++++++++++++++++++++------
 python3/configure    | 14 ++++++++++++++
 python3/configure.ac | 14 ++++++++++++++
 3 files changed, 79 insertions(+), 6 deletions(-)

(Ответ для Alexey Sheplyakov на комментарий #2)
> The following changes since commit 5258f22e54659a329155fb8ef3b44c15f169629a:
> 
>   3.10.8-alt1.1 (2022-12-17 18:34:54 +0700)
> 
> are available in the Git repository at:
> 
>   http://git.altlinux.org/people/asheplyakov/packages/python3.git loongarch64
> 
> for you to fetch changes up to fa13b5177a9da313203b58f465dd59a057dfd302:
> 
>   3.10.8-alt1.2 (2023-05-17 08:41:20 +0400)
> 
> ----------------------------------------------------------------
> Alexey Sheplyakov (4):
>       spec: a few tweaks for loongarch64
>       spec: fixed build without tk
>       spec: simplified the initial build
>       3.10.8-alt1.2
> 
> Zhang Na (1):
>       bpo-46498: Add Platform triplets for LoongArch64
> 
>  python3.spec         | 57
> +++++++++++++++++++++++++++++++++++++++++++++++++++------
>  python3/configure    | 14 ++++++++++++++
>  python3/configure.ac | 14 ++++++++++++++
>  3 files changed, 79 insertions(+), 6 deletions(-)

Или

#320644 TESTED #1 [test-only] sisyphus python3.git=3.10.8-alt1.2

(In reply to Alexey Sheplyakov from comment #1)
> А также в python3 зависит от nis (libnsl2), а на "новых" архитектурах этого
> отголоска 80-х нет

Речь о libnsl1 или о libnsl2?  Второй должно быть можно просто собрать, это отдельный пакет.
Вопрос актуальности этого в python ортогонален, кончено.

(Ответ для Gleb F-Malinovskiy на комментарий #4)
> (In reply to Alexey Sheplyakov from comment #1)
> > А также в python3 зависит от nis (libnsl2), а на "новых" архитектурах этого
> > отголоска 80-х нет
> 
> Речь о libnsl1 или о libnsl2?

О libnsl2. И она таки не является частью glibc. 

> Второй должно быть можно просто собрать, это отдельный пакет.

Но сборочные зависимости у libnsl2 несколько разбухшие:
libtirpc -> krb5 -> linux-pam

Можно, конечно, собрать для начала libtirpc без kerberos, но проще оторвать libnsl2 от python3,
и идти собирать systemd (libudev), glib2, Mesa и прочие полезные штуки, которым нужны meson и/или gtk-doc.

> Вопрос актуальности этого в python ортогонален, кончено.

В начальной сборке точно не нужен.
А дальше всё равно придётся ещё раз пересобрать python3 (когда будут собраны X11 клиентские библиотеки и tk).

> The text of disapproval follows:

> libnsl2-devel is not a part of glibc.

Комментарий исправлю. Кроме этого есть замечания?

(In reply to Alexey Sheplyakov from comment #5)
> Комментарий исправлю.
Ну там и %ifnarch получается в этой ситуации неправильным.  Если как-то зависимость на nsl и оборачивать, то это изменение про бутстрап, а совсем не про loongarch.

> Кроме этого есть замечания?
Мне не целом не очень нравится rm -f в spec потому что в итоге неизвестно, делает такая команда что-то или нет потому что это значит «удалить если есть, иначе ничего не делать».  Но я надеюсь, что про эту часть изменений выскажется grenka@,  он всё же является мейнтейнером этого пакета последние много лет.

(Ответ для Gleb F-Malinovskiy на комментарий #6)
> (In reply to Alexey Sheplyakov from comment #5)
> > Комментарий исправлю.
> Ну там и %ifnarch получается в этой ситуации неправильным.  Если как-то
> зависимость на nsl и оборачивать, то это изменение про бутстрап, а совсем не
> про loongarch.
> 
> > Кроме этого есть замечания?
> Мне не целом не очень нравится rm -f в spec потому что в итоге неизвестно,
> делает такая команда что-то или нет потому что это значит «удалить если
> есть, иначе ничего не делать».  Но я надеюсь, что про эту часть изменений
> выскажется grenka@,  он всё же является мейнтейнером этого пакета последние
> много лет.

Мне там много что не нравилось, особенно черрипик коммита, который прям в исходниках добавляет поддержку новой архитектуры. Я решил отложить этот вопрос до выхода 3.11.

(Ответ для Grigory Ustinov на комментарий #7)
> (Ответ для Gleb F-Malinovskiy на комментарий #6)
> > (In reply to Alexey Sheplyakov from comment #5)
> > > Комментарий исправлю.
> > Ну там и %ifnarch получается в этой ситуации неправильным.  Если как-то
> > зависимость на nsl и оборачивать, то это изменение про бутстрап, а совсем не
> > про loongarch.
> > 
> > > Кроме этого есть замечания?
> > Мне не целом не очень нравится rm -f в spec потому что в итоге неизвестно,
> > делает такая команда что-то или нет потому что это значит «удалить если
> > есть, иначе ничего не делать».  Но я надеюсь, что про эту часть изменений
> > выскажется grenka@,  он всё же является мейнтейнером этого пакета последние
> > много лет.
> 
> Мне там много что не нравилось, особенно черрипик коммита, который прям в
> исходниках добавляет поддержку новой архитектуры.

А откуда ещё может взяться поддержка новой архитектуры, кроме как "прям в исходниках"?

> Я решил отложить этот вопрос до выхода 3.11.

1) python 3.11.3 выпущен 5-го апреля.
2) В нём нет этого коммита
3) Сколько (и самое главное - чего) ещё надо ждать?

Добрый день.

А в чём проблема коммита с поддержкой архитектуры? Оно написано корректно и в рамках задумки проекта. Я бы хотел больше конструктива чем "много чего не понравилось".

(Ответ для Grigory Ustinov на комментарий #7)
> (Ответ для Gleb F-Malinovskiy на комментарий #6)
> > (In reply to Alexey Sheplyakov from comment #5)
> > > Комментарий исправлю.
> > Ну там и %ifnarch получается в этой ситуации неправильным.  Если как-то
> > зависимость на nsl и оборачивать, то это изменение про бутстрап, а совсем не
> > про loongarch.
> > 
> > > Кроме этого есть замечания?
> > Мне не целом не очень нравится rm -f в spec потому что в итоге неизвестно,
> > делает такая команда что-то или нет потому что это значит «удалить если
> > есть, иначе ничего не делать».  Но я надеюсь, что про эту часть изменений
> > выскажется grenka@,  он всё же является мейнтейнером этого пакета последние
> > много лет.
> 
> Мне там много что не нравилось, особенно черрипик коммита, который прям в
> исходниках добавляет поддержку новой архитектуры. Я решил отложить этот
> вопрос до выхода 3.11.

(Ответ для Alexey Sheplyakov на комментарий #8)
> А откуда ещё может взяться поддержка новой архитектуры, кроме как "прям в
> исходниках"?

Из патча. Ваш коммит перезатрётся ближайшим же обновлением.

> 1) python 3.11.3 выпущен 5-го апреля.
> 2) В нём нет этого коммита

Тем более вы сами так говорите.

> 3) Сколько (и самое главное - чего) ещё надо ждать?

Я жду, когда починят сборку rpm. Так-то у меня всё готово.

(Ответ для Grigory Ustinov на комментарий #10)
> (Ответ для Alexey Sheplyakov на комментарий #8)
> > А откуда ещё может взяться поддержка новой архитектуры, кроме как "прям в
> > исходниках"?
> 
> Из патча. Ваш коммит перезатрётся ближайшим же обновлением.

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


> > 1) python 3.11.3 выпущен 5-го апреля.
> > 2) В нём нет этого коммита
> 
> Тем более вы сами так говорите.

Я ожидал, что люди делают merge осознанно. Теперь вижу, что ошибся (не стоило судить по себе).

> > 3) Сколько (и самое главное - чего) ещё надо ждать?
> 
> Я жду, когда починят сборку rpm.

Каковы критерии того, что сборка rpm починена?
Кто именно будет её чинить?
Могу ли я чем-то помочь?

(Ответ для Alexey Sheplyakov на комментарий #11)
> (Ответ для Grigory Ustinov на комментарий #10)
> > (Ответ для Alexey Sheplyakov на комментарий #8)
> > > А откуда ещё может взяться поддержка новой архитектуры, кроме как "прям в
> > > исходниках"?
> > 
> > Из патча. Ваш коммит перезатрётся ближайшим же обновлением.
> 
> Я правильно понял, что Ваш запрос звучит так: "добавьте нужный код отдельно
> стоящим патчем, по образу и подобию тех, что уже есть"?
Да. git format-patch @^ например. Причём номер у него будет 1013 я полагаю.
> 
> 
> > > 1) python 3.11.3 выпущен 5-го апреля.
> > > 2) В нём нет этого коммита
> > 
> > Тем более вы сами так говорите.
> 
> Я ожидал, что люди делают merge осознанно. Теперь вижу, что ошибся (не
> стоило судить по себе).
Вам бы неплохо было бы пройти джойн, прежде чем строчить пулреквесты. У нас в альте есть несколько общепринятых схем сборки пакетов. Изменения в пакет вносятся либо патчами, либо коммитами из которых формируется кумулятивный патч. Можете почитать man gear-rules. Мне и без вашего изменения каждый мердж приходится делать крайне осознанно. Зачем же усложнять мне жизнь ещё больше?
> 
> > > 3) Сколько (и самое главное - чего) ещё надо ждать?
> > 
> > Я жду, когда починят сборку rpm.
> 
> Каковы критерии того, что сборка rpm починена?
Пакет rpm успешно собирается.
> Кто именно будет её чинить?
Я не знаю. Пока очереди желающих не видно. Предположительно мейнтейнер данного пакета.
> Могу ли я чем-то помочь?
Вряд ли.

(Ответ для Grigory Ustinov на комментарий #12)
> (Ответ для Alexey Sheplyakov на комментарий #11)
> > (Ответ для Grigory Ustinov на комментарий #10)
> > > (Ответ для Alexey Sheplyakov на комментарий #8)
> > > > А откуда ещё может взяться поддержка новой архитектуры, кроме как "прям в
> > > > исходниках"?
> > > 
> > > Из патча. Ваш коммит перезатрётся ближайшим же обновлением.
> > 
> > Я правильно понял, что Ваш запрос звучит так: "добавьте нужный код отдельно
> > стоящим патчем, по образу и подобию тех, что уже есть"?
> Да. git format-patch @^ например. Причём номер у него будет 1013 я полагаю.
> > 
> > 
> > > > 1) python 3.11.3 выпущен 5-го апреля.
> > > > 2) В нём нет этого коммита
> > > 
> > > Тем более вы сами так говорите.
> > 
> > Я ожидал, что люди делают merge осознанно. Теперь вижу, что ошибся (не
> > стоило судить по себе).
> Вам бы неплохо было бы пройти джойн, прежде чем строчить пулреквесты.

Вам бы неплохо научиться общаться с людьми. Могу и я научить. Совершенно бесплатно, хотя и немного больно.

> У нас в альте есть несколько общепринятых схем сборки пакетов.

Патч для поддержки архитектуры loongarch64 у Вас есть.
Дальше действуйте сами, раз Вам не понравился "патч в код".

(Ответ для Alexey Sheplyakov на комментарий #13) 
> Вам бы неплохо научиться общаться с людьми. Могу и я научить. Совершенно
> бесплатно, хотя и немного больно.

Я ни в коем случае не хотел вас задеть или обидеть.
 
> Патч для поддержки архитектуры loongarch64 у Вас есть.
> Дальше действуйте сами, раз Вам не понравился "патч в код".

Да. В принципе именно так я и хотел поступить. Постараюсь приложить как можно скорее!

python3-3.11.4-alt1 -> sisyphus:

 Fri Jun 09 2023 Grigory Ustinov <grenka@altlinux> 3.11.4-alt1
 - Updated to upstream version 3.11.4.
 - Fixed build on Elbrus (thx to ilyakurdyukov@).
 - Added support for LoongArch64 (thx to asheplyakov@) (Closes: #46170).
 - Simplified the initial build (thx to asheplyakov@) (Closes: #46171).

В итоге это неправильное изменение и неправильный комментарий про libnsl2 попали в python:
https://git.altlinux.org/gears/p/python3.git?p=python3.git;a=commitdiff;h=0702381d4b615f751fda4c01f612fba242adccdd

libnsl2 не имеет отношения к glibc и должен быть собран под loongarch64 так же как и под остальные архитектуры.  Это изменение нужно откатить.

По поводу части про valgrind я считаю, что лучше делать список архитектур, на которых он есть.  Тем более, такой список даже уже есть в виде пакета с макросом 
https://git.altlinux.org/gears/r/rpm-macros-valgrind.git .

(Ответ для Gleb F-Malinovskiy на комментарий #16)
> libnsl2 не имеет отношения к glibc и должен быть собран под loongarch64 так
> же как и под остальные архитектуры.  Это изменение нужно откатить.

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

(Ответ для Gleb F-Malinovskiy на комментарий #16)
> В итоге это неправильное изменение и неправильный комментарий про libnsl2
> попали в python:
> https://git.altlinux.org/gears/p/python3.git?p=python3.git;a=commitdiff;
> h=0702381d4b615f751fda4c01f612fba242adccdd
> 
> libnsl2 не имеет отношения к glibc и должен быть собран под loongarch64 так
> же как и под остальные архитектуры. 

Кому сильно нужны технологии 80-х годов прошлого века - пусть собирает.
Правда, для сборки libnsl2 понадобится python3 (libnsl2 -> libtirpc -> krb5 -> libverto -> libevent -> python3). 

> Это изменение нужно откатить.

Нет, не нужно. Скорее нужно выпилить libnsl2, она только топливо жрёт.

> По поводу части про valgrind я считаю, что лучше делать список архитектур,
> на которых он есть.  Тем более, такой список даже уже есть в виде пакета с
> макросом 
> https://git.altlinux.org/gears/r/rpm-macros-valgrind.git .

(In reply to Alexey Sheplyakov from comment #18)
> Нет, не нужно. Скорее нужно выпилить libnsl2, она только топливо жрёт.

Такие вещи не делаются под %ifarch, если убирать библиотеку то на всех архитектурах.

(Ответ для Gleb F-Malinovskiy на комментарий #19)
> (In reply to Alexey Sheplyakov from comment #18)
> > Нет, не нужно. Скорее нужно выпилить libnsl2, она только топливо жрёт.
> 
> Такие вещи не делаются под %ifarch, если убирать библиотеку то на всех
> архитектурах.

Спорное утверждение. Как раз на x86 у кого-то и может оказаться работающий NIS (с серверной частью на Solaris или ещё чем-то вымершем).

Но да, в этом месте лучше сделать %if_enabled bootstrap

(In reply to Alexey Sheplyakov from comment #20)
> (Ответ для Gleb F-Malinovskiy на комментарий #19)
> > (In reply to Alexey Sheplyakov from comment #18)
> > > Нет, не нужно. Скорее нужно выпилить libnsl2, она только топливо жрёт.
> > 
> > Такие вещи не делаются под %ifarch, если убирать библиотеку то на всех
> > архитектурах.
> 
> Спорное утверждение. Как раз на x86 у кого-то и может оказаться работающий
> NIS (с серверной частью на Solaris или ещё чем-то вымершем).

Но я имею в виду, что такое решение не может приниматься на разных архитектурах по-разному.