[devel] Чисто конкретно по лимитам сборочницы.

[devel] Чисто конкретно по лимитам сборочницы.

[Igor Vlasenko]

Чисто конкретно по лимитам сборочницы.

Уважаемый Дмитрий,
хотел бы пояснить, почему я считаю вашу принципиальную позицию
по лимитам сборочницы неверной.

В статистике есть такое понятие, как нормальное, или Гауссовское,
распределение. Его плотность - характерная колоколообразная кривая.
Ваша позиция была бы корректной, если бы разброс параметров сборки
подчинялся бы нормальному распределению.
Для него действительно легко указать компактную область (лимиты),
выход за которые -- вероятность слишком ничтожная, чтобы ее учитывать.

Однако если мы посмотрим на реальное распределение плотности
параметров пакетов в Сизифе, то мы увидим кривую, похожую на график
Гамма-распределения, к примеру, хи-квадрат распределения,
с пиком и выраженным длинным хвостом в сторону бесконечности.
Для Гамма-распределения, увы, если мы хотим, чтобы постоянные лимиты
работали, их приходится неоправданно завышать (делать слишком далекими
от пика). Они и сейчас слишком неудобные (далекие от пика).

К примеру, сейчас, если тесты при сборке пакета сорвутся в
цикл, что-то понемногу выводя (не провоцируя wlimit_time_idle),
то для пакета, собирающегося 3-5 мин. придется ждать 10 часов,
чтобы сработал wlimit_time_elapsed.
Если бы wlimit_time_elapsed коррелировал со временем сборки пакета,
то время ожидания падения сборки было бы более человекоориентированным.

Если же цикл активно выводит, то сработает wlimit_bytes_written.
Я сталкивался с такими логами сборки в процессе разработки
logoved. Лог в пол гигабайта, где первые 50-100 килобайт - осмысленный
лог сборки, затем 500 мегабайт мусора, затем сообщение, что наконец
сработал wlimit_bytes_written.

Логовед такой лог парсил десятки минут. Да и лишний трафик напрягает.
Если бы wlimit_bytes_written коррелировал с размером нормального лога пакета,
то логи FTBFS были бы гораздо более человеко- и машинно- читабельными.

Поэтому я полагаю, что в данном случае вы, Дмитрий, ведете безнадежную
борьбу против законов природы.

Ранее вы могли бы отмахиваться от моих проблем, в духе
"viy@ - исключение, и пакеты у него неправильные".
Хотя опять же, по статистике, наибольшая вероятность первым нарваться
на проблемы у пользователя с наибольшей и наиболее разнообразной
по типам и системам сборки пакетной базой.

Стоило уже тогда не игнорировать проблему.

Сейчас же проблемы уже начали расползаться по все большему кругу
пользователей. Я только сейчас осознал, что теперь к клубу
униженных и угнетенных (viy@, zerg@,...) прибавился и cas@,
ведь он взялся за java-1.8.0-openjdk.
Судя по success-логам пересборки, для пакета
azure-sdk-for-ruby-20200316-alt1.2
считанные доли процента отделяют его от срабатывания wlimit_bytes_written.

еще больше пакетов превысили порог времени сборки в 4 часа на x86_64,
их майнтайнерам приготовиться к нежданчикам с wlimit_time_elapsed на armh.

И хотел бы сказать, Дмитрий, что и у вас самих далеко не нулевая
вероятность самому вступить в "клуб униженных и угнетенных лимитами".
Во всяком случае, в прошлом письме, когда я привел 4 примера пакетов,
которые не вписывались в wlimit_time_elapsed,
я забыл про пример cross-gcc, который я в свое время по просьбе уважаемых
коллег импортировал в Сизиф. Тогда cross-gcc тоже не вписывался в
wlimit_time_elapsed, и по согласованию с уважаемым заказчиком сборки,
я кастрировал сборку, выбросив часть cross-архитектур, которые
заказчику были не нужны. Получается, уже gcc5 был не так уж далек от
лимита, а последние gcc всего в 4 раза меньше лимита.

Хотелось бы понять, Дмитрий, если новый LibreOffice 8 или gcc13
не впишется в лимиты сборочницы, сохраните ли вы свою принципиальную
позицию, будете вы резать gcc на подпакеты, или тихо сдвинете лимиты,
поскольку "это другое, понимать надо"?


-- 

I V

Re: [devel] обнаружение зациклившихся сборок

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
[...]
> К примеру, сейчас, если тесты при сборке пакета сорвутся в
> цикл, что-то понемногу выводя (не провоцируя wlimit_time_idle),
> то для пакета, собирающегося 3-5 мин. придется ждать 10 часов,
> чтобы сработал wlimit_time_elapsed.
> Если бы wlimit_time_elapsed коррелировал со временем сборки пакета,
> то время ожидания падения сборки было бы более человекоориентированным.
> 
> Если же цикл активно выводит, то сработает wlimit_bytes_written.
> Я сталкивался с такими логами сборки в процессе разработки
> logoved. Лог в пол гигабайта, где первые 50-100 килобайт - осмысленный
> лог сборки, затем 500 мегабайт мусора, затем сообщение, что наконец
> сработал wlimit_bytes_written.
> 
> Логовед такой лог парсил десятки минут. Да и лишний трафик напрягает.
> Если бы wlimit_bytes_written коррелировал с размером нормального лога пакета,
> то логи FTBFS были бы гораздо более человеко- и машинно- читабельными.

Что такое время нормальной сборки пакета и размер нормального лога пакета?

Смотрите, у нас в сборочнице есть такой код:

# Step 8: build.
rm -f "$tmpdir"/OK{1,2}
{
        hsh-rebuild --query-repackage "$build_source" 2>&1 &&
                touch "$tmpdir"/OK1 ||:
} | {
        gawk 'BEGIN{ts0=systime()}{print strftime("[%T]",systime()-ts0,1),$0}' > build/log &&
                touch "$tmpdir"/OK2 ||:
}
[ -f "$tmpdir"/OK1 -a -f "$tmpdir"/OK2 ] || {
        . ./gb-remote-log
        sed -r 's/^\[[0-9]{2}(:[0-9]{2}){2}\] //' build/log |
                buildlog_errors |
                sed "s/^/$arch_prefix/"
        Fatal 'build failed'
} >&2

Ничто не мешает усовершенствовать скрипт, который сейчас однострочник на
gawk, просто добавляющий в лог временные отметки, таким образом, чтобы
обнаруживать зацикливание и прерывать сборку.  Возьмётесь реализовать?


-- 
ldv

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Alexey Gladkov]

On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> Чисто конкретно по лимитам сборочницы.
> 
> Уважаемый Дмитрий,
> хотел бы пояснить, почему я считаю вашу принципиальную позицию
> по лимитам сборочницы неверной.

Я не Дмитрий, но решил высказаться, потому что вы по кругу повторяете одно
и тоже.

> Логовед такой лог парсил десятки минут. Да и лишний трафик напрягает.
> Если бы wlimit_bytes_written коррелировал с размером нормального лога пакета,
> то логи FTBFS были бы гораздо более человеко- и машинно- читабельными.

Вы жалуетесь на тяжёлую судьбу мантейнера. Я бы вам посочувствовал, если
бы не был тоже мантейнером.

Если в пакете есть глючные тесты, то их нужно либо исправлять, либо
отключать. Это зона ответственности мантейнера.

Если у вас столько пакетов, что вы не в состоянии их поддерживать, то
может не стоит поддерживать столько пакетов ? 

> Поэтому я полагаю, что в данном случае вы, Дмитрий, ведете безнадежную
> борьбу против законов природы.

Я часто теряюсь в ваших огромных письмах с лирическими отступлениями.
Какие ещё законы природы ?

> Ранее вы могли бы отмахиваться от моих проблем, в духе
> "viy@ - исключение, и пакеты у него неправильные".

Я также как и вы регулярно натыкаюсь на лимиты сборочницы в пакете
chromium. Это случилось буквально релиз назад. Только приложив чуть-чуть
усилий удалось уложиться в лимиты _без_ хаков, хотя там присутствует весь
набор (ninja, llvm внутренний и внешний и т.д.).

Указание лимитов в пакете я считаю в корне не верным. Ну разве, что хинт
типа S, M, L, XXL... за которыми будут скрываться значение посильные
сборочнице.

Ваше предложение вычислять лимиты по предыдущему логу не покрывает
случаев, когда мантейнер собирает новый пакет или включает тесты в пакете.

Например, после включения тестов в nss время сборки прыгнула с десятков
минут, до:

#100  rust       49:02  1:22:03    51:13    55:25   42:09
#400  nss        52:01  2:20:35  1:12:00  1:40:52   45:12 
#600  firefox  1:17:26  1:00:47    46:27    41:16   33:53

кстати, это вписывается в лимиты сборочницы. Тоже касается и rust (я
включил у него тесты).

Раз вы любите всякие распределения, расскажите как учесть такой гап ?

-- 
Rgrds, legion

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Paul Wolneykien]

В Thu, 19 Aug 2021 16:31:37 +0200
Alexey Gladkov <legion@altlinux.ru> пишет:

> On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> > Чисто конкретно по лимитам сборочницы.
> > 
> > Уважаемый Дмитрий,
> > хотел бы пояснить, почему я считаю вашу принципиальную позицию
> > по лимитам сборочницы неверной.  
> 
> Я не Дмитрий, но решил высказаться, потому что вы по кругу повторяете
> одно и тоже.

  У меня примерно такое же впечатление пока от чтения этой дискуссии и
ещё ощущение ... недосказанности что ли. (А может быть это я просто не в
курсе дел совсем.) Уважаемые дискурсанты, расскажите, пожалуйста, а
почему лимиты на сборочнице сейчас выставлены именно в такие значения,
в которые они выставлены, а не в какие-то другие? Откуда взялись эти
числа?

Re: [devel] обнаружение зациклившихся сборок

[Alexey V. Vissarionov]

On 2021-08-19 17:16:46 +0300, Dmitry V. Levin wrote:

 >> Если бы wlimit_bytes_written коррелировал с размером
 >> нормального лога пакета, то логи FTBFS были бы гораздо
 >> более человеко- и машинно- читабельными.
 > Что такое время нормальной сборки пакета и размер нормального
 > лога пакета?

Ну очевидно же - матожидание времени сборки и размера лога
соответственно.

Эту информацию надо собирать и учитывать. Превышение на порядок
(даже двоичный) - повод внимательно посмотреть, что случилось.
Превышение на два порядка - однозначный повод остановить сборку
как неудачную.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net

Re: [devel] обнаружение зациклившихся сборок

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 06:05:08PM +0300, Alexey V. Vissarionov wrote:
> On 2021-08-19 17:16:46 +0300, Dmitry V. Levin wrote:
> 
>  >> Если бы wlimit_bytes_written коррелировал с размером
>  >> нормального лога пакета, то логи FTBFS были бы гораздо
>  >> более человеко- и машинно- читабельными.
>  > Что такое время нормальной сборки пакета и размер нормального
>  > лога пакета?
> 
> Ну очевидно же - матожидание времени сборки и размера лога
> соответственно.
> 
> Эту информацию надо собирать и учитывать. Превышение на порядок
> (даже двоичный) - повод внимательно посмотреть, что случилось.
> Превышение на два порядка - однозначный повод остановить сборку
> как неудачную.

Ну, с таким подходом вы тесты в nss никогда не включите, даже если
захотите.  И новых пакетов тоже не факт, что сможете собрать.


-- 
ldv

Re: [devel] обнаружение зациклившихся сборок

[Alexey Gladkov]

On Thu, Aug 19, 2021 at 06:13:10PM +0300, Dmitry V. Levin wrote:
> On Thu, Aug 19, 2021 at 06:05:08PM +0300, Alexey V. Vissarionov wrote:
> > On 2021-08-19 17:16:46 +0300, Dmitry V. Levin wrote:
> > 
> >  >> Если бы wlimit_bytes_written коррелировал с размером
> >  >> нормального лога пакета, то логи FTBFS были бы гораздо
> >  >> более человеко- и машинно- читабельными.
> >  > Что такое время нормальной сборки пакета и размер нормального
> >  > лога пакета?
> > 
> > Ну очевидно же - матожидание времени сборки и размера лога
> > соответственно.
> > 
> > Эту информацию надо собирать и учитывать. Превышение на порядок
> > (даже двоичный) - повод внимательно посмотреть, что случилось.
> > Превышение на два порядка - однозначный повод остановить сборку
> > как неудачную.
> 
> Ну, с таким подходом вы тесты в nss никогда не включите, даже если
> захотите.  И новых пакетов тоже не факт, что сможете собрать.

Сборочница размер лога сборки в которой стремится к нулю! )))

Если же разрешить рост лога на N%, то я представляю себе радость по
постепенному включению тестов )))

-- 
Rgrds, legion

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Andrey Savchenko]

[-- Attachment #1: Type: text/plain, Size: 4330 bytes --]

On Thu, 19 Aug 2021 16:31:37 +0200 Alexey Gladkov wrote:
> On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> > Поэтому я полагаю, что в данном случае вы, Дмитрий, ведете безнадежную
> > борьбу против законов природы.
> 
> Я часто теряюсь в ваших огромных письмах с лирическими отступлениями.
> Какие ещё законы природы ?

Гамма распределение случайных величин и два его важных частных
случая: хи-квадрат и нормальное. Оба играют важнейшую роль
в квантовой и статистической физике (да и других разделах физики и
иных естественных науках), и поэтому являются законами природы.
Стыдно этого не знать.

Для распределения времени сборки наших пакетов нормальное
распределение не применимо, ЦПТ (центральная предельная теорема) не
работает, а имеется поэтому текущие лимиты некорректны и научно
доказана его необоснованность. По всей видимости, данное
распределение на нашей сборочнице неплохо описывается хи-квадрат
распределением, для которого характерен долгий и статистически
значимый хвост вправо плотности вероятности.

> > Ранее вы могли бы отмахиваться от моих проблем, в духе
> > "viy@ - исключение, и пакеты у него неправильные".
> 
> Я также как и вы регулярно натыкаюсь на лимиты сборочницы в пакете
> chromium. Это случилось буквально релиз назад. Только приложив чуть-чуть
> усилий удалось уложиться в лимиты _без_ хаков, хотя там присутствует весь
> набор (ninja, llvm внутренний и внешний и т.д.).

Ваши слова лишь подтверждают неадекватность действующих лимитов,
которые установлены впритык для больших и сложных пакетов.

> Указание лимитов в пакете я считаю в корне не верным. Ну разве, что хинт
> типа S, M, L, XXL... за которыми будут скрываться значение посильные
> сборочнице.

При правильной реализации такое решение также приемлемо.

> Ваше предложение вычислять лимиты по предыдущему логу не покрывает
> случаев, когда мантейнер собирает новый пакет или включает тесты в пакете.
> 
> Например, после включения тестов в nss время сборки прыгнула с десятков
> минут, до:
> 
> #100  rust       49:02  1:22:03    51:13    55:25   42:09
> #400  nss        52:01  2:20:35  1:12:00  1:40:52   45:12 
> #600  firefox  1:17:26  1:00:47    46:27    41:16   33:53
> 
> кстати, это вписывается в лимиты сборочницы. Тоже касается и rust (я
> включил у него тесты).
> 
> Раз вы любите всякие распределения, расскажите как учесть такой гап ?
 
Использовать экспоненциальную шкалу, которая является совершенно
естественной для нашего мира, что справедливо подмечал ещё Лев
Давыдович Ландау.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Alexey Gladkov]

On Thu, Aug 19, 2021 at 08:37:21PM +0300, Andrey Savchenko wrote:
> On Thu, 19 Aug 2021 16:31:37 +0200 Alexey Gladkov wrote:
> > On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> > > Поэтому я полагаю, что в данном случае вы, Дмитрий, ведете безнадежную
> > > борьбу против законов природы.
> > 
> > Я часто теряюсь в ваших огромных письмах с лирическими отступлениями.
> > Какие ещё законы природы ?
> 
> Гамма распределение случайных величин и два его важных частных
> случая: хи-квадрат и нормальное. Оба играют важнейшую роль
> в квантовой и статистической физике (да и других разделах физики и
> иных естественных науках), и поэтому являются законами природы.
> Стыдно этого не знать.

Спасибо, что подыграли :)

> Для распределения времени сборки наших пакетов нормальное
> распределение не применимо, ЦПТ (центральная предельная теорема) не
> работает,

А можно пруф этого утверждения, что не применимо ?

> а имеется поэтому текущие лимиты некорректны и научно
> доказана его необоснованность.

Допускаю. Ок, но тогда вас не затруднит скинуть ссылку на научную статью
про неприменимость нормального распределение к нашей сборочнице ?


> По всей видимости, данное
> распределение на нашей сборочнице неплохо описывается хи-квадрат
> распределением, для которого характерен долгий и статистически
> значимый хвост вправо плотности вероятности.

Вы, как и viy@, сотрясаете воздух. Есть логи. Можно вас (столь
образованных в отличии от меня) попросить проанализировать время сборки и
размер лога и представить результат ?

> > Я также как и вы регулярно натыкаюсь на лимиты сборочницы в пакете
> > chromium. Это случилось буквально релиз назад. Только приложив чуть-чуть
> > усилий удалось уложиться в лимиты _без_ хаков, хотя там присутствует весь
> > набор (ninja, llvm внутренний и внешний и т.д.).
> 
> Ваши слова лишь подтверждают неадекватность действующих лимитов,
> которые установлены впритык для больших и сложных пакетов.

Нет, не подтверждает. Мои слова говорят о том, что если пакет упёрся в
лимит это не значит, что виноват лимит. И что мантейнер большого пакета
может в них уложиться. Да, такое не всегда правда, но это не значит, что
не нужно стараться.

> > Раз вы любите всякие распределения, расскажите как учесть такой гап ?
>  
> Использовать экспоненциальную шкалу, которая является совершенно
> естественной для нашего мира, что справедливо подмечал ещё Лев
> Давыдович Ландау.

Браво.

-- 
Rgrds, legion

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 08:37:21PM +0300, Andrey Savchenko wrote:
> On Thu, 19 Aug 2021 16:31:37 +0200 Alexey Gladkov wrote:
> > On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> > > Поэтому я полагаю, что в данном случае вы, Дмитрий, ведете безнадежную
> > > борьбу против законов природы.
> > 
> > Я часто теряюсь в ваших огромных письмах с лирическими отступлениями.
> > Какие ещё законы природы ?
> 
> Гамма распределение случайных величин и два его важных частных
> случая: хи-квадрат и нормальное. Оба играют важнейшую роль
> в квантовой и статистической физике (да и других разделах физики и
> иных естественных науках), и поэтому являются законами природы.
> Стыдно этого не знать.
> 
> Для распределения времени сборки наших пакетов нормальное
> распределение не применимо, ЦПТ (центральная предельная теорема) не
> работает, а имеется поэтому текущие лимиты некорректны и научно
> доказана его необоснованность. По всей видимости, данное
> распределение на нашей сборочнице неплохо описывается хи-квадрат
> распределением, для которого характерен долгий и статистически
> значимый хвост вправо плотности вероятности.

Всё это наукообразие никому не интересно.

Всякий раз, когда кто-то приходит и говорит, что лимит слишком тесный
и его надо увеличить минимум в 2 раза, должен доказать, что это не от
криворукости, а от неизбежности.  Существенное поднятие лимита должно быть
сложнее исправления сборки.

Как в том примере с cross-gcc, импортированным из Федоры, про который
вспоминал Игорь.  Конечно, гораздо проще тупо поднять лимит в несколько
раз и собрать это поделие в неизменном виде.  Но тогда ещё проще сразу
поставить Федору, и ничего собирать не надо.

Если сделать ретроспективные лимиты, вы же сами громче всех будете
возмущаться, когда ваши пакеты перестанут пролезать.  А с ними это
обязательно произойдёт.


-- 
ldv

Re: [devel] Чисто конкретно по лимитам сборочницы.

[Dmitry V. Levin]

On Thu, Aug 19, 2021 at 06:04:49PM +0300, Paul Wolneykien wrote:
> В Thu, 19 Aug 2021 16:31:37 +0200, Alexey Gladkov пишет:
> > On Thu, Aug 19, 2021 at 04:37:01PM +0300, Igor Vlasenko wrote:
> > > Чисто конкретно по лимитам сборочницы.
> > > 
> > > Уважаемый Дмитрий,
> > > хотел бы пояснить, почему я считаю вашу принципиальную позицию
> > > по лимитам сборочницы неверной.  
> > 
> > Я не Дмитрий, но решил высказаться, потому что вы по кругу повторяете
> > одно и тоже.
> 
>   У меня примерно такое же впечатление пока от чтения этой дискуссии и
> ещё ощущение ... недосказанности что ли. (А может быть это я просто не в
> курсе дел совсем.) Уважаемые дискурсанты, расскажите, пожалуйста, а
> почему лимиты на сборочнице сейчас выставлены именно в такие значения,
> в которые они выставлены, а не в какие-то другие? Откуда взялись эти
> числа?

Лимиты исторически выставлялись и корректировались таким образом, чтобы
пакеты в Сизифе собирались.


-- 
ldv