On Sun, Oct 23, 2022 at 10:37:44PM +0300, Anton Farygin wrote:
> On 23.10.2022 22:05, Vitaly Chikunov wrote:
> > Anton,
> >
> > On Sun, Oct 23, 2022 at 09:52:39PM +0300, Anton Zhukharev wrote:
> >> On Sun, Oct 23, 2022 at 08:25:05PM +0300, Dmitry V. Levin wrote:
> >>> On Sun, Oct 23, 2022 at 12:39:16PM +0300, Anton Zhukharev wrote:
> >>>> Добрый день!
> >>>>
> >>>> Недавно столкнулся с проблемой следующего вида:
> >>>>
> >>>> [ppc64le] /usr/sbin/chroot.fakechroot: line 147: 2435617 CPU time limit exceeded env -u FAKECHROOT_BASE_ORIG FAKECHROOT_CMD_ORIG= LD_LIBRARY_PATH="$fakechroot_chroot_paths" FAKECHROOT_BASE="$fakechroot_chroot_base" "$fakechroot_chroot_chroot" "${@:1:$(($fakechroot_chroot_n - 1))}" "$fakechroot_chroot_final_newroot" "${@:$(($fakechroot_chroot_n + 1))}"
> >>>> 2022-Oct-22 21:18:00 :: [ppc64le] racket-main-distribution.git 8.6-alt1: remote: build failed
> >>>> 2022-Oct-22 21:18:00 :: [ppc64le] #100 racket-main-distribution.git 8.6-alt1: build FAILED
> >>>>
> >>>> в задании 308872.
> >>>>
> >>>> Насколько я понимаю, эта ошибка связана с разделением времени работы
> >>>> процессора между пользовательскими процессами (воспроизвелась только на
> >>>> архитектурах i586, armh и ppc64le - на x86_64 и aarch64 полёт нормальный).
> >>>>
> >>>> Есть способ обхода такого ограничения?
> >>> Сделать так, чтобы racket перестал быть таким неуёмно прожорливым,
> >>> что особенно проявляется на более медленных архитектурах.
> >>>
> >> Это, конечно, не лучшее решение, но сделав установку Racket-пакетов в
> >> 1 поток (-j 1), пакет стал собираться (см. задание 308872).
> >>
> >> Похоже, что планировщик в установщике пакетов Racket'а работает не очень
> >> оптимальным образом.
> >>
> >> Что ж, решение найдено. Процесс сборки стал дольше (кстати, не сильно),
> >> однако мне важен результат, а не скорость.
> >>
> >> Осталось подлатать и в репозитории будет Racket ;).
> > Racket уже был в Сизице до 2022-06-18. Может стоит базироваться на
> > старом спеке. Например, назвать пакет racket.
> >
> Кстати да, лучше конечно наследование какое-то сделать.
> 

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

> https://github.com/racket/racket
> 
> к тому же он и у апстрима называется racket.
> 

Я решил разделить сборку минимального Racket и пакетов к нему:
получились пакеты racket-base и racket-main-distribution.

Скорее всего, необходимо ещё сильнее дробить.

> Но, если я правильно понимаю - сейчас собрано в режиме In-place:
> 
> https://github.com/racket/racket/blob/master/build.md#12-git-repository-build-modes
> 
Сборочная система zuo сама может определить в какой системе как
устанавливать и автоматически у нас использует unixstyle-install.

> А почему бы не взять за основу апстримный git, кстати ?
> 

В апстриме спрашивал - ответили, что апстримный git использовать не
советуется с целью опакечивания. См.: https://github.com/racket/racket/issues/4456#issuecomment-1277449129

-- 
С уважением,
Жухарев Антон