From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: Date: Mon, 24 Oct 2022 10:54:02 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: ru To: devel@lists.altlinux.org References: <20221023172505.GA8234@altlinux.org> <20221023190537.afzhetwyqk65qr5s@altlinux.org> <700f0c82-8ae5-f54f-ebcd-f846735ad17d@basealt.ru> From: Anton Farygin Organization: BaseALT In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [devel] racket cpu hog (was: CPU time limit exceeded) 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: Mon, 24 Oct 2022 07:54:08 -0000 Archived-At: List-Archive: List-Post: On 24.10.2022 10:47, Anton Zhukharev wrote: > 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 выводит результат сборки каждого > файла). Под наследованием я имел в виду хотя-бы сохранение changelog'ов и описаний. Но нет так нет - это вообще на самом деле не критично, если работа делается с нуля. > >> https://github.com/racket/racket >> >> к тому же он и у апстрима называется racket. >> > Я решил разделить сборку минимального Racket и пакетов к нему: > получились пакеты racket-base и racket-main-distribution. > > Скорее всего, необходимо ещё сильнее дробить. Понятно. > А почему бы не взять за основу апстримный git, кстати ? > В апстриме спрашивал - ответили, что апстримный git использовать не > советуется с целью опакечивания. См.: https://github.com/racket/racket/issues/4456#issuecomment-1277449129 Ну апстримы, как правило, всегда предпочитают сборку из релизных тарболлов, просто для сопровождения удобнее иметь git, а не импорт.