Для обеспечения возможности обновления стека Java-пакетов в дистрибутиве исключаю архитектуру i586 для Java пакетов. Данное решение распространяется на все Java-пакеты, включая clojure и leiningen. От них в свою очередь зависят пакеты: puppetdb puppetserver foreman puppet-theforeman-puppetserver-foreman ACL на них висит на Павле Скрылёве, который закрыл ACL и повесил @norebuild, чтобы мое задание не прошло. https://packages.altlinux.org/ru/tasks/393021 Исключение архитектур я делаю поскольку Gradle не собирается под i586 и получается ситуация, когда половина проектов на Java можно собрать под i586, а другую половину нельзя. При этом, если обновлять пакеты по типу jcommander, opentest4j, hamcrest, mockito, testng и так далее, которые перешли на Gradle, то все равно придется либо исключать архитектуру i586, что приведет к полному ее исключению для Java пакетов, либо плодить placeholder`ы, что приведет к огромным проблемам в будущем. Прошу выдать aprove на эти пакеты.
А можете рассказать кому нужен 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 Второе может иметь смысл добавить безусловно, раз документацию всё равно не собираем и не пакуем -- но тут нужна оценка специалиста.
