From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.1 Date: Thu, 19 Aug 2021 01:03:53 +0300 From: Igor Vlasenko To: devel@lists.altlinux.org Message-ID: <20210818220352.GA30520@dad.imath.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.9.1 (2017-09-22) Subject: [devel] =?utf-8?b?0KHQsdC+0YDQvtGH0L3QuNGG0LA6INC90LjQutC+0LM=?= =?utf-8?b?0LTQsCDRgtCw0LrQvtCz0L4g0L3QtSDQsdGL0LvQviwg0Lgg0LLQvtGCINC+?= =?utf-8?b?0L/Rj9GC0Ywu?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2021 22:03:58 -0000 Archived-At: List-Archive: List-Post: Сборочница: никогда такого не было, и вот опять. Уважаемые коллеги! Хотел бы еще раз привлечь внимание к багу сборочницы 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,...) в проблему по настоящему массовую. -- I V