56409 2025-10-15 16:15:29 +0300 отмена поддержки i586 2025-10-17 11:49:43 +0300 1 1 4 Development Sisyphus puppetdb unstable all Linux NEW P5 normal --- 1 stime946 majioa 3aHyga aen antohami cas glebfm iv lav majioa mike placeholder rauty rider zerg qa-sisyphus oldest_to_newest 274612 0 stime946 2025-10-15 16:15:29 +0300 Для обеспечения возможности обновления стека 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 на эти пакеты. 274619 1 rider 2025-10-15 17:45:48 +0300 А можете рассказать кому нужен puppet на i586 ? 274622 2 mike 2025-10-15 18:08:37 +0300 (Ответ для 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 для списка архитектур. 274639 3 zerg 2025-10-15 20:41:18 +0300 (Ответ для Michael Shigorin на комментарий #2) > С другой стороны, конкретно по webengine ситуация ровно та же В тему: я qtwebengine-6 изначально даже не собирал(хотя, патчи существуют) для i586, что потом не трахаться с выпиливанием. 274640 4 zerg 2025-10-15 20:45:04 +0300 (Ответ для Michael Shigorin на комментарий #2) > (а также кратно увеличит потребление ими места в нашем архиве и > на зеркалах, но это хотя бы ресурсная проблема на ровном месте создаётся, а > не принципиальная). Я это вообще не считаю проблемой. И да, сколько в мегабайтах? P.S. В первую очередь компьютер должен работать на человека, а не наоборот. 274643 5 rider 2025-10-15 20:50:18 +0300 JFYI: https://www.debian.org/releases/trixie/release-notes/issues.html Я удаляю поддержку i586 в тех пакетах, где она не работает по каким-то причинам (т.е. - не трачу время на починку). Архитектура по факту нужна у нас только для arepo и то, эта необходимость с каждым годом тает. 274648 6 zerg 2025-10-15 20:53:30 +0300 (Ответ для Michael Shigorin на комментарий #2) > -BuildArch: noarch > +ExcludeArch: i586 Было сделано прямее. 274650 7 zerg 2025-10-15 20:55:23 +0300 (Ответ для Anton Farygin на комментарий #5) > Архитектура по факту нужна у нас только для arepo Факты говорят об обратном https://download.basealt.ru/pub/distributions/ALTLinux/p11/images/cloud/i586/ 274652 8 zerg 2025-10-15 20:59:55 +0300 (Ответ для Michael Shigorin на комментарий #2) > http://lists.altlinux.org/pipermail/devel/2025-August/219498.html Молчание там в ответ было вполне "внятное". 274657 9 mike 2025-10-15 21:21:47 +0300 (Ответ для Sergey V Turchin на комментарий #6) > (Ответ для Michael Shigorin на комментарий #2) > > -BuildArch: noarch > > +ExcludeArch: i586 > Было сделано прямее. Серёжка, это цитата из коммита (между строками расстояние больше, оставил так для наглядности, буквально скопипастив). Вы кого там опять на танки пустили? А по доступу буду говорить с tsi@. И кому-то прилетит регламент, полагаю. 274660 10 mike 2025-10-15 22:01:56 +0300 (Ответ для 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'ы, шелл-скрипт и документация -- непонятно. 274671 11 zerg 2025-10-16 09:08:13 +0300 (Ответ для Michael Shigorin на комментарий #10) > xeno@ влепил ExcludeArch: Ааа, это неправильно. Он же сделал макрос про "java arches". Надо было его использовать, чтоб , как раз, для бутстрапа на догоняющих архитектурах использовать. 274704 12 19792 mike 2025-10-16 13:04:24 +0300 Created attachment 19792 исправление собираемости 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 Второе может иметь смысл добавить безусловно, раз документацию всё равно не собираем и не пакуем -- но тут нужна оценка специалиста. 19792 2025-10-16 13:04:24 +0300 2025-10-16 13:04:24 +0300 исправление собираемости gradle 8.14.1-alt1 на i586 0001-spec-fix-bootstrap-build-on-i586.patch text/plain 3872 mike RnJvbSA3YzFhNzM1ZTE1YjBiNTE2OGZmZDdhZDk4NTA5MDY0NTUwMzgyZGE4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNaWNoYWVsIFNoaWdvcmluIDxtaWtlQGFsdGxpbnV4Lm9yZz4K RGF0ZTogVGh1LCAxNiBPY3QgMjAyNSAxMjoxNjoxMyArMDMwMApTdWJqZWN0OiBbUEFUQ0hdIHNw ZWM6IGZpeCBib290c3RyYXAgYnVpbGQgb24gaTU4NgoKVGhlIHByb2JsZW06IHN0cmFpZ2h0Zm9y d2FyZCBqYXZhMTctYmFzZWQgYnVpbGQgZmFpbHMgd2l0aAoKKiBXaGF0IHdlbnQgd3Jvbmc6ClVu YWJsZSB0byBzdGFydCB0aGUgZGFlbW9uIHByb2Nlc3MuClRoaXMgcHJvYmxlbSBtaWdodCBiZSBj YXVzZWQgYnkgaW5jb3JyZWN0IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGRhZW1vbi4KRm9yIGV4YW1w bGUsIGFuIHVucmVjb2duaXplZCBqdm0gb3B0aW9uIGlzIHVzZWQuRm9yIG1vcmUgZGV0YWlscyBv biB0aGUgZGFlbW9uLCBwbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly9kb2NzLmdyYWRsZS5vcmcvOC4x NC1yYy0zL3VzZXJndWlkZS9ncmFkbGVfZGFlbW9uLmh0bWwgaW4gdGhlIEdyYWRsZSBkb2N1bWVu dGF0aW9uLgpQcm9jZXNzIGNvbW1hbmQgbGluZTogL3Vzci9saWIvanZtL2phdmEtMTctb3Blbmpk ay0xNy4wLjE2LjAuOC1hbHQxLmk1ODYvYmluL2phdmEgWy4uLl0gLVhYOk1heE1ldGFzcGFjZVNp emU9NzY4bSAtWFg6K0hlYXBEdW1wT25PdXRPZk1lbW9yeUVycm9yIC1YbXgzMTAwbSBbLi4uXQpQ bGVhc2UgcmVhZCB0aGUgZm9sbG93aW5nIHByb2Nlc3Mgb3V0cHV0IHRvIGZpbmQgb3V0IG1vcmU6 Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkVycm9yIG9jY3VycmVkIGR1cmluZyBpbml0aWFsaXph dGlvbiBvZiBWTQpDb3VsZCBub3QgcmVzZXJ2ZSBlbm91Z2ggc3BhY2UgZm9yIDMxNzQ0MDBLQiBv YmplY3QgaGVhcAoKR2V0dGluZyAtWG14IGRvd24gdG8gZS5nLiAxNzAwbSBmcm9tIGluaXRpYWwg MzEwMG0KKHRoZSBndWVzc3dvcmsgYmVpbmcgImFib3V0IGhhbGYgb2YgNjQtYml0IGhlYXAgc2l6 ZQphbmQgbm8gbW9yZSB0aGFuIDIwNDhtIikgcmVzdWx0cyBpbjoKCiogV2hhdCB3ZW50IHdyb25n OgpDb3VsZCBub3QgZGV0ZXJtaW5lIHRoZSBkZXBlbmRlbmNpZXMgb2YgdGFzayAnOmRvY3M6Y29t cGlsZUphdmEnLgo+IEZhaWxlZCB0byBjYWxjdWxhdGUgdGhlIHZhbHVlIG9mIHRhc2sgJzpkb2Nz OmNvbXBpbGVKYXZhJyBwcm9wZXJ0eSAnamF2YUNvbXBpbGVyJy4KICAgPiBDYW5ub3QgZmluZCBh IEphdmEgaW5zdGFsbGF0aW9uIG9uIHlvdXIgbWFjaGluZSAoTGludXggNi4xMi41MC02LjEyLWFs dDEgaTM4NikgbWF0Y2hpbmc6IHtsYW5ndWFnZVZlcnNpb249MjEsIHZlbmRvcj1hbnkgdmVuZG9y LCBpbXBsZW1lbnRhdGlvbj12ZW5kb3Itc3BlY2lmaWMsIG5hdGl2ZUltYWdlQ2FwYWJsZT1mYWxz ZX0uIFNvbWUgdG9vbGNoYWluIHJlc29sdmVycyBoYWQgaW50ZXJuYWwgZmFpbHVyZXM6IGZvb2ph eSAoU2VydmljZSAnU3lzdGVtSW5mbycgaXMgbm90IGF2YWlsYWJsZSAob3M9TGludXggNi4xMi41 MC02LjEyLWFsdDEgaTM4NiwgZW5hYmxlZD1mYWxzZSkuKS4KCkkgd2FzIHVuYWJsZSB0byBmaW5k IHRoZSBjdWxwcml0IGZvciB0aGlzIG9uZSwKYnV0IHdlIGRvbid0IGJ1aWxkIGFuZCBwYWNrYWdl IGRvY3MgaGVyZSBhbnl3YXlzCnNvIHNraXBwaW5nIDpkb2NzOmNvbXBpbGVKYXZhIHRhcmdldCBm b3IgaTU4NgoobWF5YmUgZ2xvYmFsbHkpIHdhcyBmb3VuZCB0byBiZSB0aGUgd29ya2Fyb3VuZC4K ClRoaXMgcmVzdWx0ZWQgaW46Cgo+IFRhc2sgOmRvY3M6ZHNsU3RhbmRhbG9uZURvY2Jvb2sKVGhl IG1lc3NhZ2UgcmVjZWl2ZWQgZnJvbSB0aGUgZGFlbW9uIGluZGljYXRlcyB0aGF0IHRoZSBkYWVt b24gaGFzIGRpc2FwcGVhcmVkLgpbLi4uXQpKVk0gY3Jhc2ggbG9nIGZvdW5kOiBmaWxlOi8vL3Vz ci9zcmMvUlBNL0JVSUxEL2dyYWRsZS04LjE0LjEvLmdyYWRsZS9kYWVtb24vOC4xNC1yYy0zL2hz X2Vycl9waWQyODgyNzYwLmxvZwoKd2l0aCB0aGUgc2FpZCBsb2cgc3RhdGluZzoKCiAgIyBUaGVy ZSBpcyBpbnN1ZmZpY2llbnQgbWVtb3J5IGZvciB0aGUgSmF2YSBSdW50aW1lIEVudmlyb25tZW50 IHRvIGNvbnRpbnVlLgogICMgTmF0aXZlIG1lbW9yeSBhbGxvY2F0aW9uIChtbWFwKSBmYWlsZWQg dG8gbWFwIDE2Nzc3MjE2IGJ5dGVzLgogICAgRXJyb3IgZGV0YWlsOiBGYWlsZWQgdG8gcmVzZXJ2 ZSBtZW1vcnkgZm9yIG1ldGFzcGFjZQoKRGVjcmVhc2luZyAtWG14IGZ1cnRoZXIgZG93biB0byAx NTAwbSBoYXMgc29sdmVkIHRoaXMuCgpTZWUtYWxzbzogaHR0cDovL2J1Z3ppbGxhLmFsdGxpbnV4 Lm9yZy81NjQwOQpTZWUtYWxzbzogaHR0cDovL2FsdGxpbnV4Lm9yZy9TZWN1cmVQYWNrYWdpbmdQ b2xpY3kKLS0tCiAuZ2Vhci9ncmFkbGUuc3BlYyB8IDE0ICsrKysrKysrKysrKystCiAxIGZpbGUg Y2hhbmdlZCwgMTMgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQoKZGlmZiAtLWdpdCBhLy5n ZWFyL2dyYWRsZS5zcGVjIGIvLmdlYXIvZ3JhZGxlLnNwZWMKaW5kZXggZDQ0NmY0ZmRiNzYuLjk0 OGViNDUyNTljIDEwMDY0NAotLS0gYS8uZ2Vhci9ncmFkbGUuc3BlYworKysgYi8uZ2Vhci9ncmFk bGUuc3BlYwpAQCAtMTAsNyArMTAsNiBAQCBMaWNlbnNlOiBBcGFjaGUtMi4wCiBHcm91cDogRGV2 ZWxvcG1lbnQvSmF2YQogVXJsOiBodHRwczovL2dyYWRsZS5vcmcKIFZjczogaHR0cHM6Ly9naXRo dWIuY29tL2dyYWRsZS9ncmFkbGUuZ2l0Ci1FeGNsdWRlQXJjaDogaTU4NgogCiBTb3VyY2UwOiAl bmFtZS0ldmVyc2lvbi50YXIKIFNvdXJjZTE6ICVuYW1lLSV2ZXJzaW9uLXZlbmRvci50YXIKQEAg LTI5LDcgKzI4LDkgQEAgQnVpbGRSZXF1aXJlczogL3Byb2MKIEJ1aWxkUmVxdWlyZXM6IHJwbS1i dWlsZC1qYXZhLW9zZ2kKIEJ1aWxkUmVxdWlyZXM6IGphdmEtMTEtb3Blbmpkay1kZXZlbAogQnVp bGRSZXF1aXJlczogamF2YS0xNy1vcGVuamRrLWRldmVsCislaWZuYXJjaCAlaXg4NgogQnVpbGRS ZXF1aXJlczogamF2YS0yMS1vcGVuamRrLWRldmVsCislZW5kaWYKIEJ1aWxkUmVxdWlyZXM6IGdp dAogCiAlZGVzY3JpcHRpb24KQEAgLTU5LDEwICs2MCwyMSBAQCBleHBvcnQgR1JBRExFX1VTRVJf SE9NRT0iJFBXRC8uZ3JhZGxlIgogCiBDT01NSVRIQVNIPSQoLi9jb21taXQuc2gpCiAKKyVpZmFy Y2ggJWl4ODYKKyMgcmVkdWNlIGhlYXAgc2l6ZSB0byBmaXggMzItYml0IGJ1aWxkOyBzZWUgYWxz byBBTFQjNTY0MDkKK2ZpbmQgLXR5cGUgZiAtbmFtZSBncmFkbGUucHJvcGVydGllcyAtcHJpbnQw IHwKKwl4YXJncyAtcjAgc2VkIC1pICdzLC1YbXgzMTAwbSwtWG14MTUwMG0sJworJWVuZGlmCisK ICMgU2tpcCB0YXNrIDpkb2NzOmphdmFkb2NBbGwgdGhhdCByZXF1aXJlcyAuZ2l0IGRpcmVjdG9y eS4KIC4vZ3JhZGxldyBpbnN0YWxsQWxsIFwKICAgLXggOmRvY3M6amF2YWRvY0FsbCBcCislaWZh cmNoIGk1ODYKKyAgLXggOmRvY3M6Y29tcGlsZUphdmEgXAorICAtUG9yZy5ncmFkbGUuamF2YS5p bnN0YWxsYXRpb25zLnBhdGhzPSIlX2p2bWRpci9qYXZhLTExLW9wZW5qZGssJV9qdm1kaXIvamF2 YS0xNy1vcGVuamRrIiBcCislZWxzZQogICAtUG9yZy5ncmFkbGUuamF2YS5pbnN0YWxsYXRpb25z LnBhdGhzPSIlX2p2bWRpci9qYXZhLTExLW9wZW5qZGssJV9qdm1kaXIvamF2YS0xNy1vcGVuamRr LCVfanZtZGlyL2phdmEtMjEtb3BlbmpkayIgXAorJWVuZGlmCiAgIC1Qb3JnLmdyYWRsZS5qYXZh Lmluc3RhbGxhdGlvbnMuYXV0by1kZXRlY3Q9ZmFsc2UgXAogICAtUGdyYWRsZV9pbnN0YWxsUGF0 aD0iJFBXRC9kaXN0IiBcCiAgIC1QZmluYWxSZWxlYXNlPXRydWUgXAotLSAKMi41MC4xCgo=