Еще раз всплыла проблема неадаптируемых лимитов сборочницы, о том, что пакеты разные и нет одного универсального лимита для всех пакетов которая ранее встречалась редко и поэтому заметалась под ковер, как, к примеру, в 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 и таким образом при сборке выбирать номер с нужным лимитом. Пригодится как пользователям, желающим уменьшить какой-то лимит (если в пакете есть тенденция зависать в тестах), так и желающим увеличить какой-то лимит.
Все такие изменения быстро не делаются.
(Ответ для Dmitry V. Levin на комментарий #1) > Все такие изменения быстро не делаются. я думаю, что пара месяцев в запасе есть.
С time-idle limit мне помог хак от zerg' - добавить в спек (while true; do date; sleep 7m; done) & который, хоть и безобразное решение, но позволяет обходить лимиты сборочницы. а вот с wlimit_time_elapsed там все глухо, так что проблема по прежнему серьезная. в частности, по wlimit_time_elapsed не собирается бутстрапный jvm 9 в p9. А он нужен и сам по себе, и чтобы ним собрать jvm 10 которым собрать jvm 11.
(Ответ для viy на комментарий #2) > (Ответ для Dmitry V. Levin на комментарий #1) > > Все такие изменения быстро не делаются. > > я думаю, что пара месяцев в запасе есть. Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем использовать в p9 javafx для сторонних приложений.
(In reply to Andrey Cherepanov from comment #4) > (Ответ для viy на комментарий #2) > > (Ответ для Dmitry V. Levin на комментарий #1) > > > Все такие изменения быстро не делаются. > > > > я думаю, что пара месяцев в запасе есть. > > Пара месяцев прошла. Дима, мы из-за отсутствия openjdk-11 не можем > использовать в p9 javafx для сторонних приложений. Мне кажется, что ваши усилия направлены по неправильному адресу.
В результате никто не захотел кодить костыли для удобной сборки пакетов, которые не собираются за 8 часов. Это ненормально, таких пакетов не должно быть.
