ALT Linux Team development discussions
 help / color / mirror / Atom feed
From: Igor Vlasenko <vlasenko@imath.kiev.ua>
To: devel@lists.altlinux.org
Subject: [devel] Сборочница: никогда такого не было, и вот опять.
Date: Thu, 19 Aug 2021 01:03:53 +0300
Message-ID: <20210818220352.GA30520@dad.imath.kiev.ua> (raw)

Сборочница: никогда такого не было, и вот опять.

Уважаемые коллеги!

Хотел бы еще раз привлечь внимание к багу сборочницы
 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


             reply	other threads:[~2021-08-18 22:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-18 22:03 Igor Vlasenko [this message]
2021-08-19  0:00 ` Andrey Savchenko
2021-08-19  6:58 ` Sergey V Turchin
2021-08-19  8:13   ` Igor Vlasenko
2021-08-19 10:02     ` Dmitry V. Levin
2021-08-19 10:48       ` Sergey V Turchin
2021-08-19 10:55         ` Sergey V Turchin
2021-08-19 11:15           ` Dmitry V. Levin
2021-08-19 11:21             ` Sergey V Turchin
2021-08-19 11:30               ` Dmitry V. Levin
2021-08-19 11:41                 ` Sergey V Turchin
2021-08-19 11:55                   ` Sergey V Turchin
2021-08-19 11:53                 ` Sergey V Turchin
2021-08-19 15:21               ` Ivan A. Melnikov
2021-08-20  9:24                 ` Sergey V Turchin
2021-08-19 12:28             ` Anton Farygin
2021-08-19 13:59               ` Dmitry V. Levin
2021-08-19 14:02                 ` Anton Farygin
2021-08-20 10:55       ` [devel] Cколько памяти есть? (Сборочница: никогда такого не было, и вот опять.) Sergey V Turchin
2021-08-20 13:19         ` Vitaly Lipatov
2021-08-20 13:44           ` Sergey V Turchin
2021-08-20 20:09             ` Vitaly Lipatov
2021-08-23 11:25               ` Sergey V Turchin
2021-08-20 21:10         ` Dmitry V. Levin
2021-08-23  9:00           ` Sergey V Turchin
2021-08-23  9:11             ` [devel] Cколько памяти есть? Dmitry V. Levin
2021-08-23  9:16               ` Sergey V Turchin
2021-08-23 10:59               ` Anton Farygin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210818220352.GA30520@dad.imath.kiev.ua \
    --to=vlasenko@imath.kiev.ua \
    --cc=devel@lists.altlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

ALT Linux Team development discussions

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
		devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
	public-inbox-index devel

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://lore.altlinux.org/org.altlinux.lists.devel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git