39276 2020-11-12 23:26:03 +0300 girar task run --limits [small|normal(default)|large] option 2021-06-21 01:31:38 +0300 1 1 2 Infrastructure Infrastructure girar unspecified x86_64 Linux NEW P5 enhancement --- 39324 39328 39614 1 viy placeholder boyarsh cas ekorneechev glebfm lav ldv cas oldest_to_newest 194155 0 viy 2020-11-12 23:26:03 +0300 Еще раз всплыла проблема неадаптируемых лимитов сборочницы, о том, что пакеты разные и нет одного универсального лимита для всех пакетов которая ранее встречалась редко и поэтому заметалась под ковер, как, к примеру, в https://bugzilla.altlinux.org/show_bug.cgi?id=31683 (я тоже не особо страдал из-за отсутствия решения, так как в случае чего удалял пакет из Сизифа и собирал в autoimports). Но сейчас проблема всплыла в java. Я об ней писал в https://lists.altlinux.org/pipermail/devel/2020-October/212079.html После добавления armh noarch пакеты java должны пересобираться и на этой архитектуре, но сборка на armh и сама по себе у нас медленная, и там умолчальной сейчас не-JIT JVM, что еще тормозит и выводит сборку за лимиты, соответственно, сборочница убивает задания раньше, чем они успели собраться. Таких заданий уже скопилась небольшая очередь, #259882 FAILED #1 sisyphus srpm=jruby-1.7.22-alt2_10jpp8.src.rpm #259809 FAILED #2 sisyphus srpm=batik-1.11-alt1_3jpp8.src.rpm srpm=fop-2.4-alt1_1jpp8.src.rpm #259709 FAILED #1 sisyphus srpm=jakarta-activation-1.2.2-alt1_1jpp9.src.rpm #259499 FAILED #2 sisyphus srpm=jogl2-2.3.2-alt3_9jpp8.src.rpm #259490 NEW #1 p9 srpm=java-10-openjdk-10.0.2.13-alt2_7jpp9.src.rpm #259439 FAILED #2 sisyphus srpm=sbt-0.13.1-alt6_9.1jpp8.src.rpm #259324 FAILED #1 sisyphus srpm=java-9-openjdk-9.0.4.11-alt4_6jpp8.src.rpm #257261 FAILED #2 p9 srpm=java-9-openjdk-9.0.4.11-alt2_6jpp8.M90P.1.src.rpm С этой статистикой можно оценить число пострадавших пактов в Сизифе в 30-120 шт. Предлагаю, как самый ленивый вариант, ввести набор опций для управления лимитами, к примеру, wlimit_time_elapsed => --limit-time-elapsed large с дискретным набором значений (normal=0/large=1 или normal(default)=0/small=1/large=2) и примитивной реализацией: сгенерировать на сборочных массив псевдопользователей с разными лимитами и вычислять нужный номер псевдопользователя по опциям нужный номер псевдопользователя. No=No-as-before+(Total pseudousers before)*(limit-time-elapsed)+(Total before)^2*(limit-time-idle)+ ... (Total before)^N*(limit-N) Упрощая - завести в hasher-priv каждого сборочного узла еще 2 псевдопользователя с номерами +100 и +200 к примеру normal -- обычный номер hasher (к примеру, 0), small - номер hasher +100 large - номер hasher +200 и таким образом при сборке выбирать номер с нужным лимитом. Пригодится как пользователям, желающим уменьшить какой-то лимит (если в пакете есть тенденция зависать в тестах), так и желающим увеличить какой-то лимит. 194374 1 ldv 2020-11-20 18:42:19 +0300 Все такие изменения быстро не делаются. 194379 2 viy 2020-11-20 22:02:53 +0300 (Ответ для Dmitry V. Levin на комментарий #1) > Все такие изменения быстро не делаются. я думаю, что пара месяцев в запасе есть. 195480 3 viy 2021-01-18 05:17:44 +0300 С time-idle limit мне помог хак от zerg' - добавить в спек (while true; do date; sleep 7m; done) & который, хоть и безобразное решение, но позволяет обходить лимиты сборочницы. а вот с wlimit_time_elapsed там все глухо, так что проблема по прежнему серьезная. в частности, по wlimit_time_elapsed не собирается бутстрапный jvm 9 в p9. А он нужен и сам по себе, и чтобы ним собрать jvm 10 которым собрать jvm 11. 195485 4 cas 2021-01-18 09:31:56 +0300 (Ответ для viy на комментарий #2) > (Ответ для Dmitry V. Levin на комментарий #1) > > Все такие изменения быстро не делаются. > > я думаю, что пара месяцев в запасе есть. Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем использовать в p9 javafx для сторонних приложений. 195492 5 ldv 2021-01-18 12:17:29 +0300 (In reply to Andrey Cherepanov from comment #4) > (Ответ для viy на комментарий #2) > > (Ответ для Dmitry V. Levin на комментарий #1) > > > Все такие изменения быстро не делаются. > > > > я думаю, что пара месяцев в запасе есть. > > Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем > использовать в p9 javafx для сторонних приложений. Мне кажется, что ваши усилия направлены по неправильному адресу. 196064 6 ldv 2021-02-06 19:32:53 +0300 В результате никто не захотел кодить костыли для удобной сборки пакетов, которые не собираются за 8 часов. Это ненормально, таких пакетов не должно быть.