Summary: | Портирование в p9 | ||
---|---|---|---|
Product: | Sisyphus | Reporter: | Vladimir Cherny <black> |
Component: | java-11-openjdk | Assignee: | viy <viy> |
Status: | CLOSED FIXED | QA Contact: | qa-sisyphus |
Severity: | normal | ||
Priority: | P5 | CC: | aen, boyarsh, cas, ekorneechev, ldv, viy |
Version: | unstable | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Bug Depends on: | 39276 | ||
Bug Blocks: |
Description
Vladimir Cherny
2021-01-27 14:18:36 MSK
Чтобы собрать jvm11, надо собрать jvm10. Чтобы собрать jvm10, надо собрать jvm9. собрать jvm9 в p9 в нашей сборочнице не получается из-за armh, надо или в отдельной сборочнице собрать, как это было в Сизифе раньше, или делать что-то в духе https://bugzilla.altlinux.org/show_bug.cgi?id=39276 Какая-то неправильная ситуация сложилась, но я не знаю, как на нее повлиять. (Ответ для viy на комментарий #1) > Чтобы собрать jvm11, надо собрать jvm10. > Чтобы собрать jvm10, надо собрать jvm9. > собрать jvm9 в p9 в нашей сборочнице не получается из-за armh, > надо или в отдельной сборочнице собрать, как это было в Сизифе раньше, > или делать что-то в духе > https://bugzilla.altlinux.org/show_bug.cgi?id=39276 > > Какая-то неправильная ситуация сложилась, но я не знаю, как на нее повлиять. То есть в Сизифе тоже не собирается? Я вижу два варианта: 1. Просить ldv@ дать лимит на сборку java в порядке исключения и разово. Какой это должен быть лимит? 2. Отказаться от сборки java для armh в p9. Дима в cc: (Ответ для AEN на комментарий #2) > То есть в Сизифе тоже не собирается? в Сизифе первый раз с armh там кажется Сергей Большаков как-то в сборочницу вмешивался, чтобы на armh прошло. Сейчас java9 собирается с помощью сама себя, и в лимиты сборочницы влезает. С p9 там нужна именно первая, bootstrap, сборка, с помощью jvm8. (Ответ для viy на комментарий #3) > (Ответ для AEN на комментарий #2) > > То есть в Сизифе тоже не собирается? > > в Сизифе первый раз с armh там кажется Сергей Большаков как-то в сборочницу > вмешивался, чтобы на armh прошло. Сейчас java9 собирается с помощью сама > себя, и в лимиты сборочницы влезает. С p9 там нужна именно первая, > bootstrap, сборка, с помощью jvm8. То есть увеличение лимита нужно для бутстрапа lava9 и все? (Ответ для AEN на комментарий #4) > (Ответ для viy на комментарий #3) > > (Ответ для AEN на комментарий #2) > > > То есть в Сизифе тоже не собирается? > > > > в Сизифе первый раз с armh там кажется Сергей Большаков как-то в сборочницу > > вмешивался, чтобы на armh прошло. Сейчас java9 собирается с помощью сама > > себя, и в лимиты сборочницы влезает. С p9 там нужна именно первая, > > bootstrap, сборка, с помощью jvm8. > > То есть увеличение лимита нужно для бутстрапа lava9 и все? Это самый востребованный случай. В случае бутстрапа lava9 я просто не знаю, что делать. А так проблемы с одним набором лимитов на все пакеты встречаются регулярно. Для лимитов по idle time народ применяет обман сборочницы с помощью хака от zerg@', что тоже звоночек в сторону востребованности более гибкого управления лимитами. Для лимитов по total time лично я, когда сталкивался с такими случаями, просто не связывался с Сизифом и собирал пакет в autoimports. но для p9 это не вариант. Меня сейчас интересует решение конкретной проблемы. Несомненно, общую тоже надо решать. Это совершенно ненормальная ситуация, когда пакету нужно более суток на сборку, мы не можем признавать такое безобразие допустимым. Раз в год в виде исключения я готов попробовать что-нибудь придумать, чтобы такое ненормальное бутстрап-задание собралось. Напишите мне в личку номер задания и количество часов, которое ему нужно. (Ответ для Dmitry V. Levin на комментарий #7) > Раз в год в виде исключения я готов попробовать что-нибудь придумать, чтобы > такое ненормальное бутстрап-задание собралось. Напишите мне в личку номер > задания и количество часов, которое ему нужно. Спасибо! Как бы нам назвать этот день? :) Спасибо, буду готовить задание (Ответ для viy на комментарий #9) > Спасибо, буду готовить задание Игорь, прошу согласовать с cas@. Если я верно его понял, некоторые наши пользователи высказывали претензии к сборке "как у RH". Спасибо. Подготовил 265898 #265898(Ответ для AEN на комментарий #10) > Игорь, прошу согласовать с cas@. > Если я верно его понял, некоторые наши пользователи высказывали претензии к > сборке "как у RH". Все вопросы можно будет исправить позже, так как перезаливать в p9 новые сборки далее будет без проблем, не-bootstrap сборка уже укладывается в лимит по общему времени. (Ответ для AEN на комментарий #10) > (Ответ для viy на комментарий #9) > > Спасибо, буду готовить задание > > Игорь, прошу согласовать с cas@. > Если я верно его понял, некоторые наши пользователи высказывали претензии к > сборке "как у RH". > Спасибо. Там надо убрать патчи для security policies. Для java-11-openjdk это # PR3694, RH1340845: Add security.useSystemPropertiesFile option to java.security to use system crypto policy Patch4: pr3694-rh1340845-support_fedora_rhel_system_crypto_policy.patch # PR3695: Allow use of system crypto policy to be disabled by the user Patch7: pr3695-toggle_system_crypto_policy.patch (Ответ для Andrey Cherepanov на комментарий #12) > Там надо убрать патчи для Понял.security policies. Для java-11-openjdk это > # PR3694, RH1340845: Add security.useSystemPropertiesFile option to > java.security to use system crypto policy > Patch4: pr3694-rh1340845-support_fedora_rhel_system_crypto_policy.patch > # PR3695: Allow use of system crypto policy to be disabled by the user > Patch7: pr3695-toggle_system_crypto_policy.patch Принял. процесс пошел: #266865 EPERM #1 p9 srpm=java-10-openjdk-10.0.2.13-alt5_7jpp8.M90P.1.src.rpm (Ответ для viy на комментарий #14) > процесс пошел: > #266865 EPERM #1 p9 srpm=java-10-openjdk-10.0.2.13-alt5_7jpp8.M90P.1.src.rpm Игорь, спасибо! Это задание отправим тестировщикам, потому с 11 подождем до его пропуска в p9. Главное, что бутстрап armh в p9 прошел. уже в p9 |