А можете рассказать кому нужен puppet на i586 ?

(Ответ для Ivan Khanas на комментарий #0)
> Для обеспечения возможности обновления стека Java-пакетов в дистрибутиве
> исключаю архитектуру i586 для Java пакетов.
Чем именно обусловлена такая необходимость/срочность?

Не специалист по java, но краем уха отслеживаю в силу сопровождения sisyphus_e2k и из поводов припоминается отказ от zerovm с переходом исключительно к JIT (mixed mode) вроде как с выпиливанием 32-битного x86 в java21 -- это так?

Сходу наткнулся только на обсуждение JEP 449 ("Deprecate the Windows 32-bit x86 Port for Removal"), что на данный момент нас не касается никак.

> ACL на них висит на Павле Скрылёве, который закрыл ACL и повесил @norebuild,
> чтобы мое задание не прошло.
Похвально, когда кто-то пытается развалить сизиф без внятных аргументов.

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

Понятно, что java-подсистемой в сизифе надо заниматься.  Вот только подпускать на гаубичный выстрел к этому человека, который себя уже так проявил -- опасно: гораздо более опытные и осторожные люди уже напарывались на сложно решаемые проблемы (например, без консультаций с viy@ и cas@ по их опыту точно нельзя).

> Исключение архитектур я делаю поскольку Gradle не собирается под i586
Вешайте багу на gradle и автора коммита http://git.altlinux.org/gears/g/gradle.git?p=gradle.git;a=commitdiff;h=5be6ed414d6c;hp=cc5fdf3ba444bae10a1d70d45c8faa5227f24dde -- поскольку именно там содержится в том числе:

-BuildArch:      noarch
+ExcludeArch: i586

Читаю http://gradle.org/install/ и не вижу для этого оснований; в (отсутствующем) комментарии рядом со строчкой, commit message и %changelog они также не приведены, что нарушает наши практики оформления как минимум последних (и противоречит здравому смыслу): http://altlinux.org/changelog

> и получается ситуация, когда половина проектов на Java можно собрать под i586,
> а другую половину нельзя.
Ой, и кто же это сделал?  И какими соображениями руководствуясь --
"сгорел сарай, гори и хата", так понимаю?

> При этом, если обновлять пакеты по типу jcommander, opentest4j, hamcrest,
> mockito, testng и так далее, которые перешли на Gradle, то все равно придется
> либо исключать архитектуру i586, что приведет к полному ее исключению для
> Java пакетов, либо плодить placeholder`ы, что приведет к огромным проблемам
> в будущем.
Вы пытаетесь проблемы из будущего (понятно, что неизбежные в силу постепенного выпиливания 32-битной поддержки из жабы) привнести по максимуму в настоящее.

Позвольте поинтересоваться -- с какой целью?  Если чисто спортивной в силу нехватки текущих проблем, так давайте я своими поделюсь, в меру талантов поможете.

Вопрос сохранения поддержки i586 в sisyphus как таковом ставится и решается при подготовке к созданию каждой стабильной ветки как минимум с p11 (а то и с p10 или вовсе p9, не помню уже) -- и на данный момент выбор в пользу сохранения в интересах клиентов ООО "Базальт СПО".  Основное contra -- с браузерами.

А среди, возможно, неочевидных pro -- http://altlinux.org/biarch и wine на 64-битных системах (хотя здесь тоже были изменения за последние пару лет, опять же внимательно не отслеживал -- вроде как научили 64-битный wine выполнять IA32 PE binaries, ранее требовалась установка именно 32-битного i586-wine).

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

Что стоило бы сделать -- так это пробное задание с демонстрацией того,
что хотите сделать, _после_ внятного объяснения причин и целей изменения
вместе с анализом последствий, насколько их получается просчитать.

Возможно, для такого потребуется эксперимент на отдельном временном репозитории или даже отдельной сборочнице (тогда обратимся ко glebfm@ насчёт icarus).

А вот исключать поддержку java на i586 на основании несобираемости сломанного Вами лично пакета gradle при весьма лукавой формулировке вида:

---
Дело в том, что новые версии некторых проектов требуют java-21, которая 
у нас не собирается под i586. Также многие проекты перешли на 
использование Gradle для сборки.
--- http://lists.altlinux.org/pipermail/devel/2025-August/219488.html

и том, что даже более новый gradle 9 _не_ требует java21 -- считаю неразумным.

Из очевидных для меня и явно не рассматривавшихся Вами отрицательных последствий -- java-пакеты станут из noarch архитектурнозависимыми, что резко усложнит работы по бутстрапу новых версий java на догоняющих архитектурах (а также кратно увеличит потребление ими места в нашем архиве и на зеркалах, но это хотя бы ресурсная проблема на ровном месте создаётся, а не принципиальная).

> Прошу выдать aprove на эти пакеты.
Разве что "aprove", именно в таком синтаксисе.
Поводов для "approve" пока не наблюдаю.
Скорее наоборот.

PS 2 rauty re http://lists.altlinux.org/pipermail/devel/2025-August/219498.html -- лучше бывает руководствоваться здравым смыслом, чем прецедентным правом;
чёрные списки применяют, когда есть основания исключить часть вариантов по объективным причинам (в случае java это было бы отсутствие поддержки конкретной архитектуры при наличии поддержки в принципе всех остальных), а белые -- когда есть такие основания _включить_ часть вариантов (и здесь у нас речь именно про такое: реализация JIT для конкретного списка архитектур).  С другой стороны, конкретно по webengine ситуация ровно та же -- JIT для списка архитектур.

(Ответ для Michael Shigorin на комментарий #2)
> С другой стороны, конкретно по webengine ситуация ровно та же
В тему: я qtwebengine-6 изначально даже не собирал(хотя, патчи существуют) для i586, что потом не трахаться с выпиливанием.

(Ответ для Michael Shigorin на комментарий #2)
> (а также кратно увеличит потребление ими места в нашем архиве и
> на зеркалах, но это хотя бы ресурсная проблема на ровном месте создаётся, а
> не принципиальная).
Я это вообще не считаю проблемой. И да, сколько в мегабайтах?

P.S. В первую очередь компьютер должен работать на человека, а не наоборот.

JFYI: https://www.debian.org/releases/trixie/release-notes/issues.html

Я удаляю поддержку i586 в тех пакетах, где она не работает по каким-то причинам (т.е. - не трачу время на починку).

Архитектура по факту нужна у нас только для arepo и то, эта необходимость с каждым годом тает.

(Ответ для Michael Shigorin на комментарий #2)
> -BuildArch:      noarch
> +ExcludeArch: i586
Было сделано прямее.

(Ответ для Anton Farygin на комментарий #5)
> Архитектура по факту нужна у нас только для arepo
Факты говорят об обратном https://download.basealt.ru/pub/distributions/ALTLinux/p11/images/cloud/i586/

(Ответ для Michael Shigorin на комментарий #2)
> http://lists.altlinux.org/pipermail/devel/2025-August/219498.html
Молчание там в ответ было вполне "внятное".

(Ответ для Sergey V Turchin на комментарий #6)
> (Ответ для Michael Shigorin на комментарий #2)
> > -BuildArch:      noarch
> > +ExcludeArch: i586
> Было сделано прямее.
Серёжка, это цитата из коммита (между строками расстояние больше, оставил так для наглядности, буквально скопипастив).  Вы кого там опять на танки пустили?

А по доступу буду говорить с tsi@.  И кому-то прилетит регламент, полагаю.

(Ответ для Sergey V Turchin на комментарий #4)
> > (а также кратно увеличит потребление ими места в нашем архиве и
> > на зеркалах, но это хотя бы ресурсная проблема на ровном месте создаётся,
> > а не принципиальная).
> Я это вообще не считаю проблемой. И да, сколько в мегабайтах?
Полгига в noarch, если смотреть по p11.  И да, копейка рубль бережёт
(про экономию на спичках тоже помним, тут Сцилла и Харибда).
 
> P.S. В первую очередь компьютер должен работать на человека, а не наоборот.
Именно.  А человек не должен дураком быть и тем более становиться.
Если я тебе кеды сделаю хуже и заодно кратно толще, у тебя ведь явно будет вопрос -- зачем?

Было бы ухудшение хоть ради чего -- можно было б взвешивать.  А тут вижу:
"[я сломал gradle] и вообще, java 21 без i586, давайте сломаем даже то,
что работает, у меня уже 100500 итераций".

Повторюсь, за такой детсад надо возвращать из майнтейнеров.
Все учимся, но за ошибки надо наказывать, а не отмазывать.


(Ответ для Anton Farygin на комментарий #5)
> JFYI: https://www.debian.org/releases/trixie/release-notes/issues.html
> Я удаляю поддержку i586 в тех пакетах, где она не работает по каким-то
> причинам (т.е. - не трачу время на починку).
Да, это вполне понятно.  А вот с какого перепугу xeno@ влепил ExcludeArch: в спек пакета -- я сейчас проверил содержимое бутстрапного gradle-8.14.1-bin.zip из 8.14.1-alt1 и там jar'ы, шелл-скрипт и документация -- непонятно.

(Ответ для Michael Shigorin на комментарий #10)
> xeno@ влепил ExcludeArch:
Ааа, это неправильно. Он же сделал макрос про "java arches". Надо было его использовать, чтоб , как раз, для бутстрапа на догоняющих архитектурах использовать.

Created attachment 19792 [details]
исправление собираемости gradle 8.14.1-alt1 на i586

TLDR: патч прилагается.

(Ответ для Sergey V Turchin на комментарий #11)
> > xeno@ влепил ExcludeArch:
> Ааа, это неправильно. Он же сделал макрос про "java arches".
Ну к такому я бы как раз не стал докапываться -- бутстрап на то и бутстрап,
чтоб через него поскорей продраться и дальше уж наводить красоту.

Посмотрел ночью -- сборка на i586 начинается (если соответственно обусловить BuildRequires: java-21-openjdk-devel и список путей к JVM в параметре -Porg.gradle.java.installations.paths), но упирается в прибитый гвоздями лимит -Xmx3100m -- получить столько на 32-битной архитектуре не выйдет; после пристрелочного

+%ifarch %ix86
+# reduce heap size
+sed -i 's,-Xmx3100m,-Xmx1700m,' `find -name gradle.properties`
+%endif

(да, это `` тоже надо исправлять по http://altlinux.org/SecurePackagingPolicy, если угораздит починить; и цифра с потолка -- "чуть больше половины" с учётом разницы в размере указателей и отсутствия разницы в размере как минимум части данных, но "до двух гигабайт")

...упёрся в:

* What went wrong:
Could not determine the dependencies of task ':docs:compileJava'.
> Failed to calculate the value of task ':docs:compileJava' property 'javaCompiler'.
   > Cannot find a Java installation on your machine (Linux 6.12.50-6.12-alt1 i386) matching: {languageVersion=21, vendor=any vendor, implementation=vendor-specific, nativeImageCapable=false}. Some toolchain resolvers had internal failures: foojay (Service 'SystemInfo' is not available (os=Linux 6.12.50-6.12-alt1 i386, enabled=false).).

Что странно с учётом -x :docs:javadocAll (исключения сборки документации).

Место, где явно указана зависимость сборки документации от java21, не нашёл.

[ заодно по http://docs.gradle.org/current/userguide/compatibility.html предположил, почему xeno@ остановился на 8.14 и не стал бутстрапить сразу 9.0 -- это последняя версия, для которой указана совместимость с java8 (которая ещё в сизифе и много где до упора будет в работе, судя по долетающему; так что спасибо) ]

Попытался исключить проблемную цель условным:

-x :docs:compileJava \

и получил:

> Task :docs:dslStandaloneDocbook
The message received from the daemon indicates that the daemon has disappeared.
Build request sent: Build{id=56572da4-a69a-4289-948c-83b8ee22d656, currentDir=/usr/src/RPM/BUILD/gradle-8.14.1}
Attempting to read last messages from the daemon log...
Daemon pid: 2882760 
  log file: /usr/src/RPM/BUILD/gradle-8.14.1/.gradle/daemon/8.14-rc-3/daemon-2882760.out.log
[...]
JVM crash log found: file:///usr/src/RPM/BUILD/gradle-8.14.1/.gradle/daemon/8.14-rc-3/hs_err_pid2882760.log

в данном логе значится:

# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 16777216 bytes. Error detail: Failed to reserve memory for metaspace
# Possible reasons:
#   The system is out of physical RAM or swap space
#   In 32 bit mode, the process size limit was hit
# Possible solutions:
#   Reduce memory load on the system
#   Increase physical memory or swap space
#   Check if swap backing store is full
#   Use 64 bit Java on a 64 bit OS
#   Decrease Java heap size (-Xmx/-Xms)
#   Decrease number of Java threads
#   Decrease Java thread stack sizes (-Xss)
#   Set larger code cache with -XX:ReservedCodeCacheSize=

Убавил -Xmx до 1500, пакет собрался.  Текущий набросок патча поверх бутстрапного спека 8.14.1-alt1 прилагаю (для i586 придётся перебутстрапить опять с gradlew).

Ключевое:
* -Xmx1500m на 32-битных архитектурах
* -x :docs:compileJava при отсутствии java21

Второе может иметь смысл добавить безусловно, раз документацию всё равно не собираем и не пакуем -- но тут нужна оценка специалиста.