Доброго времени суток!

On Thu, 19 Aug 2021 01:03:53 +0300 Igor Vlasenko wrote:
> Сборочница: никогда такого не было, и вот опять.
> 
> Уважаемые коллеги!
> 
> Хотел бы еще раз привлечь внимание к багу сборочницы
>  https://bugzilla.altlinux.org/39276 --
> для сборки пакетов используются одни и те же значения лимитов
> hasher-priv без возможности как-то на них повлиять.
> 
> Это до боли напоминает "прокрустово ложе", историю о борце за
> человеческое равенство разбойнике Прокрусте,
> Добрый разбойник всех, кто к нему попадал, укладывал на свое ложе;
> тем, для кого ложе было коротко, он отрубал ноги,
> а у тех, для кого оно было слишком длинно, он ноги вытягивал.
> 
> Логика подсказывает, что лимиты должны быть не абсолютными, а
> соразмерными пакету. Было бы странно дом для скворца - скворечник,
> будку для собаки и сарай для слона делать одинаковыми физически.
> Однако сборочница именно так и устроена.
> 
> К примеру, лимит wlimit_time_idle.
> Прямо сейчас в репозитории 6 пакетов
> java-1.8.0-openjdk
> java-9-openjdk
> java-10-openjdk
> java3d
> jogl2
> qt5-webengine
> 
> обманывают сборочницу и обходят этот лимит с помощью вставки в спек
> кода вида (while true; do date; sleep 7m; done) &
> 
> Чем плох такой обман?
> 1) замусоривается лог сборки
> 2) вместо предохранителя wlimit_time_idle мы устанавливаем "жучёк".
> Если вдруг, к примеру, выбьет тесты, и сборка зависнет, то
> wlimit_time_idle не сработает, так как будет продолжать идти мусор от
> фонового sleep;date.
> 
> Следующий лимит, wlimit_time_elapsed, уже обойти нельзя.
> Уважаемый Дмитрий не хочет ничего делать в этом случае,
> отговаривается тем, что таких пакетов в нормальных случаях быть не может.
> 
> Здесь я навскидку приведу 4 примера, где как раз сам пакет честный,
> а сборка упирается в wlimit_time_elapsed.
> 
> * библиотека libint, с которой и начался #39276
> * монолитный texlive-2016
> * java-9-openjdk и его эпическая история бутстрап сборки в p9 на armh,
>   см. https://bugzilla.altlinux.org/39614
> * свежий пример, о котором я рассказывал в Переяславле,
>   #274515 FAILED #2 sisyphus srpm=scala-2.10.6-alt3_17jpp8.src.rpm (armh).
> 
> С добавлением новых архитектур сложилась ситуация, когда
> вполне возможно, что в Сизифе таких пакетов, как старая scala (java8+armh)
> несколько десятков, они как мины, ждут, когда их наконец
> попробуют пересобрать на armh, чтобы взорваться на
> wlimit_time_elapsed. Поэтому я и интенсивно переезжаю на java11,
> а java8only пакеты сразу массово выбрасываю в топку, чтобы не
> связываться со сборочницей.
> 
> Как я уже говорил, это очень неприятная проблема на ровном месте.
> 
> И вот теперь прозвенел первый звоночек уже и в отношении
> лимита wlimit_bytes_written. Он должен защищать нас
> от бесконечного цикла, забивающего лог мусором.
> 
> Впервые на моей памяти честный лог сборки в задании
> #282652 FAILED #2 sisyphus srpm=openjfx-11.0.9.2-alt1_6jpp11.src.rpm
> вылез за wlimit_bytes_written.
> 
> Конечно wlimit_bytes_written, как и wlimit_time_idle, можно обойти.
> Можно отключить наиболее частые warnings. Можно выставить VERBOSE=0.
> Доводя до логического конца, можно вообще написать в спеке
> абсурд, зеркально подчеркивающий абсурд фиксированных лимитов,
> написать
> 
> make build >/dev/null 2>&1
> 
> Э8()
> 
> Но openjfx только первая ласточка. Это не отменит того факта,
> что исходники растут, и вполне может быть, что уже через год
> пакеты, не вписывающиеся в wlimit_bytes_written,
> тоже будут исчисляться десятками.
> 
> Как мне хочется спокойно собирать пакеты, а приходится
> бороться со сборочницей, занимаясь глупостями
> вроде обходов лимитов.
> 
> Надо подумать наперед и чинить это сейчас, а не ждать,
> когда эта проблема начнет вырастать
> из пока еще проблемы 2-3 человек (viy,zerg,...)
> в проблему по настоящему массовую.

По-хорошему, эти параметры должны управляться через макросы spec.
Если по какой-то причине это принципиально невозможно (например, их
нужно знать на этапе до возможности прочитать spec), их нужно
задавать через интерфейс build.alt так же, как и зависимости.

Но боюсь, что здесь вопрос более административный, чем технический.

Best regards,
Andrew Savchenko