Проблема с racket, похоже, плавающая.

Один день оно не пересобирается, затем опять собирается:
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-December/105191.html
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-December/105199.html

Аналогичное поведение я замечал и раньше. Вот, например, такое же повторялось в конце ноября:
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-November/105140.html
https://lists.altlinux.org/pipermail/sisyphus-cybertalk/2018-November/105148.html

Локально мне пока что не удавалось воспроизвести проблему. Я собираюсь обновить версию, но нет гарантии, что данная плавающая проблема будет решена таким образом.

Это уж точно какая-то проблема на сборочнице.

(In reply to comment #2)
> Это уж точно какая-то проблема на сборочнице.

Не похоже.  Судя по логу, raco setup иногда просто зацикливается.

> 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k

Причём зацикливается в userspace.

(В ответ на комментарий №3)
> (In reply to comment #2)
> > Это уж точно какая-то проблема на сборочнице.
> 
> Не похоже.  Судя по логу, raco setup иногда просто зацикливается.
> 
> > 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k
> 
> Причём зацикливается в userspace.

Он не зацикливается, он может долго работать в секции %install, но локально он ни разу не вис у меня, всегда через некоторое время он успешно завершал свою работу. Похоже, сборочница иногда зря его прибивает, и делает это на основе каких-то неизвестных факторов.

(In reply to comment #4)
> (В ответ на комментарий №3)
> > (In reply to comment #2)
> > > Это уж точно какая-то проблема на сборочнице.
> > 
> > Не похоже.  Судя по логу, raco setup иногда просто зацикливается.
> > 
> > > 7885.91user 595.28system 39:38.63elapsed 356%CPU (0avgtext+0avgdata 4378412maxresident)k
> > 
> > Причём зацикливается в userspace.
> 
> Он не зацикливается, он может долго работать в секции %install, но локально он
> ни разу не вис у меня, всегда через некоторое время он успешно завершал свою
> работу. Похоже, сборочница иногда зря его прибивает, и делает это на основе
> каких-то неизвестных факторов.

Судя по логу, оно само умирает:
make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded

В /etc/hasher-priv/system написано:
rlimit_soft_cpu=7200
rlimit_hard_cpu=7260

Другими словами, каждому процессу выделено до 2 часов CPU time.
Это очень много.

(В ответ на комментарий №5)
> Судя по логу, оно само умирает:
> make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded
> 
> В /etc/hasher-priv/system написано:
> rlimit_soft_cpu=7200
> rlimit_hard_cpu=7260
> 
> Другими словами, каждому процессу выделено до 2 часов CPU time.
> Это очень много.

Судя по логу, его убивают лимиты, а вовсе не само оно умирает.

Это не противоречит тому, что иногда из-за некоторых факторов, предположительно внешних, этих лимитов для установки ему хватает, а иногда - нет.

Дим, а может ли быть такая ситуация, что по каким-то внешним причинам (загруженность машины, overcommit или ещё что-то) процесс начинает долго висеть ?

У меня тоже был какой-то пакет, который умирал по CPU Time, но как-то оно само рассосалось.

(In reply to comment #7)
> Дим, а может ли быть такая ситуация, что по каким-то внешним причинам
> (загруженность машины, overcommit или ещё что-то) процесс начинает долго висеть
> ?

Висение процесса не влияет на то время, которое ограничивает RLIMIT_CPU,
если, конечно, ядро не спятило.

> У меня тоже был какой-то пакет, который умирал по CPU Time, но как-то оно само
> рассосалось.

Это, наверное, был wlimit_time_elapsed или wlimit_time_idle.

(In reply to comment #6)
> (В ответ на комментарий №5)
> > Судя по логу, оно само умирает:
> > make[1]: *** [Makefile:178: install-3m] CPU time limit exceeded
> > 
> > В /etc/hasher-priv/system написано:
> > rlimit_soft_cpu=7200
> > rlimit_hard_cpu=7260
> > 
> > Другими словами, каждому процессу выделено до 2 часов CPU time.
> > Это очень много.
> 
> Судя по логу, его убивают лимиты, а вовсе не само оно умирает.
> 
> Это не противоречит тому, что иногда из-за некоторых факторов, предположительно
> внешних, этих лимитов для установки ему хватает, а иногда - нет.

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

Да, я тоже хотел тебе предложить.
Я посмотрел на разницу между успешной и ошибочной сборкой racket и вижу, что в случае успеха он просто успевает ещё выполнить 56 операций по сборке.

на fail дополнительных повторных процессов raco setup , отсутствующих на success - я не вижу.

2ldv: не увеличил ?

(In reply to comment #11)
> 2ldv: не увеличил ?

Увеличил с двух часов до трёх.  Кажется, не помогло.
Видимо, всё-таки зацикливается с некоторой вероятностью.

racket-6.12-alt1 -> sisyphus:

Mon Dec 10 2018 Aleksei Nikiforov <darktemplar@altlinux> 6.12-alt1
- Updated to upstream version 6.12 (Closes: #35721)

Спасибо!

*** Bug 36203 has been marked as a duplicate of this bug. ***

Сейчас там наблюдается
hasher-priv: master: idle time limit (3600 seconds) exceeded
hsh-rebuild: rebuild of `racket-6.12-alt1.src.rpm' failed.

Насколько я понимаю, сборка racket очень чувствительна к загруженности сборочного сервера.

*** Bug 40313 has been marked as a duplicate of this bug. ***