[devel] CPU time limit exceeded

[devel] CPU time limit exceeded

[Anton Zhukharev]

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

Добрый день!

Недавно столкнулся с проблемой следующего вида:

[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 полёт нормальный).

Есть способ обхода такого ограничения?

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

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

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

Re: [devel] CPU time limit exceeded

[Leonid Krivoshein]

Добрый день!


23.10.2022 12:39, Anton Zhukharev пишет:
> Добрый день!
>
> Недавно столкнулся с проблемой следующего вида:
>
> [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 полёт нормальный).

Насколько повторяем результат при перезапуске задания?


> Есть способ обхода такого ограничения?

Мне кажется, это не ограничение сборочницы, это текущая загруженность её 
узлов так отражается на вашу "вероятностную" сборку, внутри которой 
заложены временные ограничения. Чинить нужно именно сборку. К примеру на 
x86_64 до этого места плавненько дошли за 4.5 минуты, а на ppc64 к этому 
месту шли почти 44 минуты.



> Возможно, что ошибка связана с пакетом fakechroot (к сожалению,
> его использование при сборки этого пакета - единственный рабочий
> способ; подробнее на этом останавливаться пока не буду).


-- 
С уважением,
Леонид Кривошеин.

Re: [devel] CPU time limit exceeded

[Anton Zhukharev]

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

On Sun, Oct 23, 2022 at 03:33:24PM +0300, Leonid Krivoshein wrote:
> Добрый день!
> 
> 
> 23.10.2022 12:39, Anton Zhukharev пишет:
> > Добрый день!
> >
> > Недавно столкнулся с проблемой следующего вида:
> >
> > [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 полёт нормальный).
> 
> Насколько повторяем результат при перезапуске задания?
> 
Постоянно.
 
> > Есть способ обхода такого ограничения?
> 
> Мне кажется, это не ограничение сборочницы, это текущая загруженность её 
> узлов так отражается на вашу "вероятностную" сборку, внутри которой 
> заложены временные ограничения. Чинить нужно именно сборку. К примеру на 
> x86_64 до этого места плавненько дошли за 4.5 минуты, а на ppc64 к этому 
> месту шли почти 44 минуты.
> 
В этом же задании в спек добавил вызов команды "ulimit -a". Это, всё
таки, ограничение.
Сколько суммарно собирается пакет - не важно (racket-base на ppc64le
собирался где-то 2.5 часа, однако CPU time не превысил).

Распараллеливание сборки не поможет (и не помогает: уже убедился),
поскольку потребуется столько же процессорного времени (ну или примерно
столько же).
К тому же распараллеливание привело к "out of memory" на 32-разрядных
архитектурах.

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

Для меня удивительно то, что на ppc64le превышение CPU limit
происходит быстрее, чем заканчивается сборка на x86_64 без превышения.

Жалко, что обойти это, скорее всего, рядовыми способами не получится.

> > Возможно, что ошибка связана с пакетом fakechroot (к сожалению,
> > его использование при сборки этого пакета - единственный рабочий
> > способ; подробнее на этом останавливаться пока не буду).
> 
> 
> -- 
> С уважением,
> Леонид Кривошеин.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

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

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

Re: [devel] CPU time limit exceeded

[Andrey Savchenko]

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

On Sun, 23 Oct 2022 19:32:30 +0300 Anton Zhukharev wrote:
> On Sun, Oct 23, 2022 at 03:33:24PM +0300, Leonid Krivoshein wrote:
> > 23.10.2022 12:39, Anton Zhukharev пишет:
> > > Есть способ обхода такого ограничения?
> > 
> > Мне кажется, это не ограничение сборочницы, это текущая загруженность её 
> > узлов так отражается на вашу "вероятностную" сборку, внутри которой 
> > заложены временные ограничения. Чинить нужно именно сборку. К примеру на 
> > x86_64 до этого места плавненько дошли за 4.5 минуты, а на ppc64 к этому 
> > месту шли почти 44 минуты.
> > 
> В этом же задании в спек добавил вызов команды "ulimit -a". Это, всё
> таки, ограничение.
> Сколько суммарно собирается пакет - не важно (racket-base на ppc64le
> собирался где-то 2.5 часа, однако CPU time не превысил).
> 
> Распараллеливание сборки не поможет (и не помогает: уже убедился),
> поскольку потребуется столько же процессорного времени (ну или примерно
> столько же).
> К тому же распараллеливание привело к "out of memory" на 32-разрядных
> архитектурах.
> 
> В данном пакете происходит банальная установка пакетов для Racket с
> попутной их компиляцией, поэтому как "чинить именно сборку" не ясно.
> Как вариант можно было бы отделить сборку пакетов от сборки документаций
> к ним, однако по результатам нескольких пересборок видно, что порой
> превышение процессорного времени происходит ещё до начала сборки
> документаций.
> 
> Для меня удивительно то, что на ppc64le превышение CPU limit
> происходит быстрее, чем заканчивается сборка на x86_64 без превышения.
> 
> Жалко, что обойти это, скорее всего, рядовыми способами не получится.

Соберите нужные пакеты racket отдельными rpm-пакетами и просто
ставьте их как сборочные зависимости.

Best regards,
Andrew Savchenko

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

Re: [devel] CPU time limit exceeded

[Anton Zhukharev]

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

On Sun, Oct 23, 2022 at 09:51:58PM +0300, Andrey Savchenko wrote:
> On Sun, 23 Oct 2022 19:32:30 +0300 Anton Zhukharev wrote:
> > On Sun, Oct 23, 2022 at 03:33:24PM +0300, Leonid Krivoshein wrote:
> > > 23.10.2022 12:39, Anton Zhukharev пишет:
> > > > Есть способ обхода такого ограничения?
> > > 
> > > Мне кажется, это не ограничение сборочницы, это текущая загруженность её 
> > > узлов так отражается на вашу "вероятностную" сборку, внутри которой 
> > > заложены временные ограничения. Чинить нужно именно сборку. К примеру на 
> > > x86_64 до этого места плавненько дошли за 4.5 минуты, а на ppc64 к этому 
> > > месту шли почти 44 минуты.
> > > 
> > В этом же задании в спек добавил вызов команды "ulimit -a". Это, всё
> > таки, ограничение.
> > Сколько суммарно собирается пакет - не важно (racket-base на ppc64le
> > собирался где-то 2.5 часа, однако CPU time не превысил).
> > 
> > Распараллеливание сборки не поможет (и не помогает: уже убедился),
> > поскольку потребуется столько же процессорного времени (ну или примерно
> > столько же).
> > К тому же распараллеливание привело к "out of memory" на 32-разрядных
> > архитектурах.
> > 
> > В данном пакете происходит банальная установка пакетов для Racket с
> > попутной их компиляцией, поэтому как "чинить именно сборку" не ясно.
> > Как вариант можно было бы отделить сборку пакетов от сборки документаций
> > к ним, однако по результатам нескольких пересборок видно, что порой
> > превышение процессорного времени происходит ещё до начала сборки
> > документаций.
> > 
> > Для меня удивительно то, что на ppc64le превышение CPU limit
> > происходит быстрее, чем заканчивается сборка на x86_64 без превышения.
> > 
> > Жалко, что обойти это, скорее всего, рядовыми способами не получится.
> 
> Соберите нужные пакеты racket отдельными rpm-пакетами и просто
> ставьте их как сборочные зависимости.
> 

Была попытка так сделать, однако минимум (base, racket-lib и что-то там
ещё) пакетов зависят друг от друга, поэтому ставить пакеты main
distribution нужно пачкой (то есть одновременно одной командой, чтобы
пакетный менеджер raco смог разрешить зависимости).

Над макросами для сборки другик пакетов Racket'а я позабочусь в будущем.

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

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Dmitry V. Levin]

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 перестал быть таким неуёмно прожорливым,
что особенно проявляется на более медленных архитектурах.


-- 
ldv

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Zhukharev]

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

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 ;).

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

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Vitaly Chikunov]

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.

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



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Farygin]

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.
>
Кстати да, лучше конечно наследование какое-то сделать.


https://github.com/racket/racket

к тому же он и у апстрима называется racket.

Но, если я правильно понимаю - сейчас собрано в режиме In-place:

https://github.com/racket/racket/blob/master/build.md#12-git-repository-build-modes

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Zhukharev]

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

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

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

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Farygin]

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, а не импорт.

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Andrey Savchenko]

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

On Mon, 24 Oct 2022 10:47:58 +0300 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 выводит результат сборки каждого
> файла).

make тоже может выводить, если ему задать соовтетсвующую опцию.
Обычно это V=1 или VERBOSE=1.

Best regards,
Andrew Savchenko

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Vitaly Chikunov]

On Mon, Oct 24, 2022 at 01:33:38PM +0300, Andrey Savchenko wrote:
> On Mon, 24 Oct 2022 10:47:58 +0300 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 выводит результат сборки каждого
> > файла).
> 
> make тоже может выводить, если ему задать соовтетсвующую опцию.
> Обычно это V=1 или VERBOSE=1.

Еще unset MAKEFLAGS иногда помогает.

> 
> Best regards,
> Andrew Savchenko



> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Dmitry V. Levin]

On Mon, Oct 24, 2022 at 02:00:01PM +0300, Vitaly Chikunov wrote:
> On Mon, Oct 24, 2022 at 01:33:38PM +0300, Andrey Savchenko wrote:
> > On Mon, 24 Oct 2022 10:47:58 +0300 Anton Zhukharev wrote:
[...]
> > > Я изначально пробовал исправить уже существующий спек, однако
> > > пришлось отключать сборку на ppc64le, поскольку она повисала намертво (в
> > > действительности это не так: при сборке с помощью make ничего не
> > > выводится в терминал в течение продолжительного времени (больше часа) и
> > > из-за этого hasher считает, что сборка повисла - однако если собирать с
> > > помощью zuo (их собственная система сборки - собрал отдельно в Сизиф) то
> > > сборка "чинится", поскольку zuo выводит результат сборки каждого
> > > файла).
> > 
> > make тоже может выводить, если ему задать соовтетсвующую опцию.
> > Обычно это V=1 или VERBOSE=1.
> 
> Еще unset MAKEFLAGS иногда помогает.

В данном случае это, скорее всего, результат присутствия -O в $MAKEFLAGS.


-- 
ldv

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Sergey V Turchin]

On Monday, 24 October 2022 15:09:25 MSK Dmitry V wrote:

[...]
> > > > сборка "чинится", поскольку zuo выводит результат сборки каждого
> > > > файла).
> > > 
> > > make тоже может выводить, если ему задать соовтетсвующую опцию.
> > > Обычно это V=1 или VERBOSE=1.
> > Еще unset MAKEFLAGS иногда помогает.
> В данном случае это, скорее всего, результат присутствия -O в $MAKEFLAGS.
Мне `make -Onone` помог в похожем случае, когда ninja скрывал вывод компиляции 
при сборке и вываливал всё по окончанию.

-- 
Regards, Sergey.

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Zhukharev]

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

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 ;).
> 
К сожалению, я поспешил с выводами. Этот способ помог только на i586.

Похоже, что придётся дробить (хотелось этого избежать для пакетов
входящих в main-distribution, однако придётся как-то решить проблему
взаимозависимостей).

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

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Zhukharev]

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

On Mon, Oct 24, 2022 at 10:54:17AM +0300, Anton Zhukharev wrote:
> 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 ;).
> > 
> К сожалению, я поспешил с выводами. Этот способ помог только на i586.
> 
> Похоже, что придётся дробить (хотелось этого избежать для пакетов
> входящих в main-distribution, однако придётся как-то решить проблему
> взаимозависимостей).

Дальше много текста, предлагается читать только тем, кому интересна идея
о возвращении в репозиторий Racket (именно современного CS-варианта).

--

Похоже, что раздробить всё таки легко не получится: сейчас попробую "вкраце"
объяснить почему это довольно сложно в случае с Racket.

Основная проблема заключается в том, что после установки каждого пакета
Racket вносит данные в файл links.rktd (/usr/share/racket/links.rktd),
который содержит ссылки на пакеты (по одному на строку) и ещё
дополнительные данные. Это только половина беды, поскольку решается
(вроде бы) выполнением команды:

    # raco link -i --repair

Дальше - ещё веселее. Также _необходим_ файл pkgs.rktd
(/usr/lib/racket/pkgs/pkgs.rktd), который необходим практически
для того же для чего нужен и links.rktd (он содержит ссылки на пакеты).
Он также обновляется после каждой установки/обновлении пакета. Если этот
файл повредится/будет удалён/недоступен, то пакетный менеджер raco не
увидит, что в системе установлены Racket-пакеты (в /usr/lib/racket/pkgs)

В теории, это можно решить созданием независимого пакета, который будет
содержать список со всеми пакетами из main-distribution (однако как его
обновлять в дальнейшем - не совсем ясно: если кому-то понадобится
установить Racket-пакет не входящий в RPM-пакет, то он должен
быть (1) установлен от пользователя root, (2) он изменит файл, который
принадлежит теоретическому независимому пакету (это, на мой взгляд не
совсем правильно) и (3) будет конфликтовать с другими возможными
пакетами с Racket-пакетами).

Аналогично файлу pkgs.rktd также существуют два файла в
/usr/lib[64]/racket: это launchers.rktd и mans.rktd, которые также
изменяются после установки _некоторых_ пакетов из main-distribution.
Они содержат запускаторы для программ, которые являются Racket-пакетами,
и man-pages соответственно.

Обновлять файлы pkgs.rktd, launchers.rktd и mans.rktd, возможно,
получится в будущем, когда я (или не я) разберусь с кодовой базой Racket
и создам свой велосипед для их актуализации. Но даже если такой
велосипед будет создан, то не понятно когда его запускать: после
установки каждого RPM-пакета с Racket-пакетами выглядит неоптимально,
поскольку в теории может быть вызвано несколько раз, допустим при
обновлении пакетов или их установки, что сильно увеличит длительность
транзакции установки пакетов. Тут мне нужна помощь: существует ли
возможность выполнения определенного скриптлета 1 раз в конце
транзакции? Ну, допустим есть ли что-то вроде "%post --once"?
// Ну или диагонально-другая идея: создать systemd-сервис, который
// будет после обновления пакетов проводить операции актуализации
// этих файлов. Здесь нужно ещё думать.

Сейчас у меня на уме несколько идей, которые нуждаются в, как минимум,
первичных обсуждениях дабы возможные пользователи Racket не испытывали
дискомфорт при использовании его из нашего репозитория:

    1. Оставить только RPM-пакет racket-core, а пользователей "обязать"
       ставить Racket-пакеты себе в домашнюю директорию. (не нравится, к
       тому же не работает, поскольку сейчас в репозитории Racket 8.6, а
       пакетный менеджер raco пытается ставить пакеты для 8.7, который
       ещё в стадии тестирования...)

    2. Выкинуть архитектуры ppc64le и armh и собирать Racket-пакеты из
       main-distribution в один RPM-пакет. (ещё больше не нравится из-за
       отказа от некоторых платформ в нашем репозитории)

    3. Попробовать ставить Racket-пакеты из main-distribution в систему,
       используя EEPM (использовать racket-core из репозитория и просто
       устанавливать Racket-пакеты в рамках локальной сборки на каждой
       пользовательской машине). (нравится, поскольку пакеты будут
       установлены в system-scope, не нужно отказываться от некоторых
       платформ, а процесс сборки надёжен, поскольку у него небольшие
       требования - разве что CPU time)

    4. "Завелосипедить" свой установщик Racket-пакетов для ALT'а (я в
       восторге от этого варианта, но на его реализацию потребуется
       неопределенное количество времени).

Если кому-то интересно о "возможных пользователях Racket", то они могут
появиться после приобретения книги "Как проектировать программы":

    Фелляйзен М., Финдлер Р.Б., Флэтт М.[1], Кришнамурти Ш.
    Как проектировать программы / пер. с англ. А.Н. Киселева; под ред.
    П.Б. Иванова, А.Д. Чичинина, Ю.А. Сыровецкого, С.В. Бронникова. -М:
    ДМК Пресс, 2022. - 724 с.: ил.

    Сайт книги: http://htdp.org/2022-8-7/Book/index.html

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

--
[1] - Флэтт М. (он же mflatt) - главный разработчик Racket (по
совместительству его создатель).

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

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

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Ivan A. Melnikov]

On Wed, Oct 26, 2022 at 10:47:25PM +0300, Anton Zhukharev wrote:
> On Mon, Oct 24, 2022 at 10:54:17AM +0300, Anton Zhukharev wrote:
> > 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 ;).
> > > 
> > К сожалению, я поспешил с выводами. Этот способ помог только на i586.
> > 
> > Похоже, что придётся дробить (хотелось этого избежать для пакетов
> > входящих в main-distribution, однако придётся как-то решить проблему
> > взаимозависимостей).
> 
> Дальше много текста, предлагается читать только тем, кому интересна идея
> о возвращении в репозиторий Racket (именно современного CS-варианта).
> 
> --
> 
> Похоже, что раздробить всё таки легко не получится: сейчас попробую "вкраце"
> объяснить почему это довольно сложно в случае с Racket.
> 
> Основная проблема заключается в том, что после установки каждого пакета
> Racket вносит данные в файл links.rktd (/usr/share/racket/links.rktd),
> который содержит ссылки на пакеты (по одному на строку) и ещё
> дополнительные данные. Это только половина беды, поскольку решается
> (вроде бы) выполнением команды:
> 
>     # raco link -i --repair
> 
> Дальше - ещё веселее. Также _необходим_ файл pkgs.rktd
> (/usr/lib/racket/pkgs/pkgs.rktd), который необходим практически
> для того же для чего нужен и links.rktd (он содержит ссылки на пакеты).
> Он также обновляется после каждой установки/обновлении пакета. Если этот
> файл повредится/будет удалён/недоступен, то пакетный менеджер raco не
> увидит, что в системе установлены Racket-пакеты (в /usr/lib/racket/pkgs)
> 
> В теории, это можно решить созданием независимого пакета, который будет
> содержать список со всеми пакетами из main-distribution (однако как его
> обновлять в дальнейшем - не совсем ясно: если кому-то понадобится
> установить Racket-пакет не входящий в RPM-пакет, то он должен
> быть (1) установлен от пользователя root, (2) он изменит файл, который
> принадлежит теоретическому независимому пакету (это, на мой взгляд не
> совсем правильно) и (3) будет конфликтовать с другими возможными
> пакетами с Racket-пакетами).
> 
> Аналогично файлу pkgs.rktd также существуют два файла в
> /usr/lib[64]/racket: это launchers.rktd и mans.rktd, которые также
> изменяются после установки _некоторых_ пакетов из main-distribution.
> Они содержат запускаторы для программ, которые являются Racket-пакетами,
> и man-pages соответственно.
> 
> Обновлять файлы pkgs.rktd, launchers.rktd и mans.rktd, возможно,
> получится в будущем, когда я (или не я) разберусь с кодовой базой Racket
> и создам свой велосипед для их актуализации. Но даже если такой
> велосипед будет создан, то не понятно когда его запускать: после
> установки каждого RPM-пакета с Racket-пакетами выглядит неоптимально,
> поскольку в теории может быть вызвано несколько раз, допустим при
> обновлении пакетов или их установки, что сильно увеличит длительность
> транзакции установки пакетов. Тут мне нужна помощь: существует ли
> возможность выполнения определенного скриптлета 1 раз в конце
> транзакции? Ну, допустим есть ли что-то вроде "%post --once"?

Письмо читал по диагонали, но кажется Вам сюда:

https://www.altlinux.org/RPMFileTrigger


> // Ну или диагонально-другая идея: создать systemd-сервис, который
> // будет после обновления пакетов проводить операции актуализации
> // этих файлов. Здесь нужно ещё думать.
> 
> Сейчас у меня на уме несколько идей, которые нуждаются в, как минимум,
> первичных обсуждениях дабы возможные пользователи Racket не испытывали
> дискомфорт при использовании его из нашего репозитория:
> 
>     1. Оставить только RPM-пакет racket-core, а пользователей "обязать"
>        ставить Racket-пакеты себе в домашнюю директорию. (не нравится, к
>        тому же не работает, поскольку сейчас в репозитории Racket 8.6, а
>        пакетный менеджер raco пытается ставить пакеты для 8.7, который
>        ещё в стадии тестирования...)
> 
>     2. Выкинуть архитектуры ppc64le и armh и собирать Racket-пакеты из
>        main-distribution в один RPM-пакет. (ещё больше не нравится из-за
>        отказа от некоторых платформ в нашем репозитории)
> 
>     3. Попробовать ставить Racket-пакеты из main-distribution в систему,
>        используя EEPM (использовать racket-core из репозитория и просто
>        устанавливать Racket-пакеты в рамках локальной сборки на каждой
>        пользовательской машине). (нравится, поскольку пакеты будут
>        установлены в system-scope, не нужно отказываться от некоторых
>        платформ, а процесс сборки надёжен, поскольку у него небольшие
>        требования - разве что CPU time)
> 
>     4. "Завелосипедить" свой установщик Racket-пакетов для ALT'а (я в
>        восторге от этого варианта, но на его реализацию потребуется
>        неопределенное количество времени).
> 
> Если кому-то интересно о "возможных пользователях Racket", то они могут
> появиться после приобретения книги "Как проектировать программы":
> 
>     Фелляйзен М., Финдлер Р.Б., Флэтт М.[1], Кришнамурти Ш.
>     Как проектировать программы / пер. с англ. А.Н. Киселева; под ред.
>     П.Б. Иванова, А.Д. Чичинина, Ю.А. Сыровецкого, С.В. Бронникова. -М:
>     ДМК Пресс, 2022. - 724 с.: ил.
> 
>     Сайт книги: http://htdp.org/2022-8-7/Book/index.html
> 
> Конечно, таких пользователей может оказаться немного, однако это
> неплохой случай занять эту небольшую нишу в области образования.
> 
> --
> [1] - Флэтт М. (он же mflatt) - главный разработчик Racket (по
> совместительству его создатель).
> 
> -- 
> С уважением,
> Жухарев Антон

> -----BEGIN PGP SIGNATURE-----
> 
> iQIzBAEBCAAdFiEEncj8Wbn95ehqoNT0ETK72RYVmrMFAmNZjswACgkQETK72RYV
> mrOzGRAA1xJR2svrChz4bxiHYZQNaPyyMpgTZDjkE3vwteIy1N8NS6GzUL8sWQtI
> nCMT8JkWN/6RnxnzWsCcUSTVHZK7b0ew4KMCgb6v66okECoJkQQiFMAWG2yedG5d
> 34B2XTEm21mZChIwsaWDhoaBeSR3ld1nmXlrX9GdxN94BP/q1PvedyHANSUn0yBD
> dFV6WBWyeBWZIGXIYL9dXm7djz8SuZsR6zNE0M9pK7B0LiIPOVV5yRj6e+60uM4c
> I/nwxXZ0ZQIgArxlyL1prOT+oI6Ez2lZslJrTDBgo3y6SnGEyvH74Tk8SkGosJGX
> eQKtz3HkAE2PRZg303UR8YlceM1WmFyLgSHRQLjCHOGd2pPZmCSYSfwO8T16zUZf
> +ZBNYwJ7BAoav+wl8kJ6rdL4NZwqMc5ddSWwzG/CdceDA1M4kHUekYS2AVICcFxi
> GSt0J2yEgQblK2YgxnYN5XfGJ0MaE3mGjiU7CTcO+cbm3fnamE/RBGcM86s0N9wJ
> xgJxfvFbEqbL1cgcb5qYYe1W+h9pu1CSpliKdH73V/l1Q7kwjVmgeot6q4DLgUCb
> ngtd3AFwJ0AyO5eRlUJMsQnShqWURDqx1ZJrnjoSGWPL5Scis6QieZatwidvg2AR
> u4vz+frH9ibssg2W5DnZWWybpuRoGGh1/uqktA/bV6KaFEmLmUM=
> =x12J
> -----END PGP SIGNATURE-----


> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] racket cpu hog (was: CPU time limit exceeded)

[Anton Farygin]

On 26.10.2022 22:47, Anton Zhukharev wrote:
> В теории, это можно решить созданием независимого пакета, который будет
> содержать список со всеми пакетами из main-distribution (однако как его
> обновлять в дальнейшем - не совсем ясно: если кому-то понадобится
> установить Racket-пакет не входящий в RPM-пакет, то он должен
> быть (1) установлен от пользователя root, (2) он изменит файл, который
> принадлежит теоретическому независимому пакету (это, на мой взгляд не
> совсем правильно) и (3) будет конфликтовать с другими возможными
> пакетами с Racket-пакетами).
>
> Аналогично файлу pkgs.rktd также существуют два файла в
> /usr/lib[64]/racket: это launchers.rktd и mans.rktd, которые также
> изменяются после установки_некоторых_  пакетов из main-distribution.
> Они содержат запускаторы для программ, которые являются Racket-пакетами,
> и man-pages соответственно.

Я бы перенёс эти файлы в /var, научив raco использовать их оттуда, или 
если возможен второй вариант - добавить поддржку каталогов

launchers.rktd.d и mans.rktd.d
в /usr/lib64/racket - что бы каждый пакет таскал свою часть с собой и складывал её в отдельный файл. Тогда вообще не нужно будет обновлять общий файл-каталог.