configure скрипт python (версии 3.10) пытается собрать сведения о платформе для модуля sysconfig, и на LoongArch это у него не получается. В результате ломается сборка модулей расширения, написанных на C, C++ (и прочих компилируемых языках).
(Ответ для 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 или ещё чем-то вымершем). Но я имею в виду, что такое решение не может приниматься на разных архитектурах по-разному.
