Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Kirill Maslinsky]

Girar Builder awaiter robot writes:

> http://git.altlinux.org/tasks/238855/logs/events.4.1.log
>
> 2020-Apr-25 20:31:29 :: test-only task #238855 for sisyphus resumed by kirill:
[...]
> 2020-Apr-25 20:41:27 :: [ppc64le] #300 R-base.git 4.0.0-alt1: build start
[...]
> make[6]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
> hasher-priv: master: idle time limit (3600 seconds) exceeded
> 2020-Apr-25 21:46:14 :: [ppc64le] R-base.git 4.0.0-alt1: remote: build failed
> 2020-Apr-25 21:46:14 :: [ppc64le] #300 R-base.git 4.0.0-alt1: build FAILED

Вероятно, этот timeout на ppc64le связан с присутствием texlive в
сборочных зависимостях R? Можно ли что-то сделать, чтобы эта сборка прошла?

-- 
KM

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Dmitry V. Levin]

On Sun, Apr 26, 2020 at 04:19:58PM +0300, Kirill Maslinsky wrote:
> 
> Girar Builder awaiter robot writes:
> 
> > http://git.altlinux.org/tasks/238855/logs/events.4.1.log
> >
> > 2020-Apr-25 20:31:29 :: test-only task #238855 for sisyphus resumed by kirill:
> [...]
> > 2020-Apr-25 20:41:27 :: [ppc64le] #300 R-base.git 4.0.0-alt1: build start
> [...]
> > make[6]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
> > hasher-priv: master: idle time limit (3600 seconds) exceeded
> > 2020-Apr-25 21:46:14 :: [ppc64le] R-base.git 4.0.0-alt1: remote: build failed
> > 2020-Apr-25 21:46:14 :: [ppc64le] #300 R-base.git 4.0.0-alt1: build FAILED
> 
> Вероятно, этот timeout на ppc64le связан с присутствием texlive в
> сборочных зависимостях R?

Присутствие texlive в сборочной среде - это, конечно, ужасно, потому что
нынешний texlive в Сизифе - это что-то совершенно непотребное, но timeout
связан с чем-то другим, поскольку, во-первых, время создания сборочной
среды учитывается отдельно, и, во-вторых, на соседних архитектурах сборка
этого подзадания заняла меньше 16 минут.


-- 
ldv

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Michael Shigorin]

On Sun, Apr 26, 2020 at 05:20:52PM +0300, Dmitry V. Levin wrote:
> Присутствие texlive в сборочной среде - это, конечно, ужасно,
> потому что нынешний texlive в Сизифе - это что-то совершенно
> непотребное

viy@ пытался собрать его в мелконарезанном виде, сам помнишь.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] про texlive

[Dmitry V. Levin]

On Sun, Apr 26, 2020 at 05:35:24PM +0300, Michael Shigorin wrote:
> On Sun, Apr 26, 2020 at 05:20:52PM +0300, Dmitry V. Levin wrote:
> > Присутствие texlive в сборочной среде - это, конечно, ужасно,
> > потому что нынешний texlive в Сизифе - это что-то совершенно
> > непотребное
> 
> viy@ пытался собрать его в мелконарезанном виде, сам помнишь.

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


-- 
ldv

Re: [devel] про texlive

[Andrey Savchenko]

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

On Sun, 26 Apr 2020 18:33:46 +0300 Dmitry V. Levin wrote:
> On Sun, Apr 26, 2020 at 05:35:24PM +0300, Michael Shigorin wrote:
> > On Sun, Apr 26, 2020 at 05:20:52PM +0300, Dmitry V. Levin wrote:
> > > Присутствие texlive в сборочной среде - это, конечно, ужасно,
> > > потому что нынешний texlive в Сизифе - это что-то совершенно
> > > непотребное
> > 
> > viy@ пытался собрать его в мелконарезанном виде, сам помнишь.
> 
> С неадекватным генератором зависимостей это была мертворождённая идея,
> в лучшем случае получился бы тот же монстр, что и сейчас, но из нескольких
> тысяч пакетов, а в худшем - нерабочий texlive.

Он был вполне работающим. Генератор зависемостей там не идеальный,
но выдающий работоспособный результат. Реальная причина проблем:
неэффективно реализованный install check на нашей сборочнице, если
вообще не сказать отвратительно работающий. Он работает настолько
плохо, что на железе послабее пришлось вовсе отключить и без всяких
texlive. Но эта проблема молча игнорируется, вместо чего все
стрелки переводятся на texlive.

Я хочу сказать отдельное спасибо viy@ за то, что он обновил texlive
и вместо почти не пригодного к использованию tevlive-2008 (я не мог
скомпилировать там большинство своих презентаций и статей из-за
отсутствующей функциональности) мы теперь имеем вполне пригодный
к работе texlive-2019, пусть и не идеально упакованный.

Best regards,
Andrew Savchenko

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

Re: [devel] про texlive

[Dmitry V. Levin]

On Sun, Apr 26, 2020 at 06:54:27PM +0300, Andrey Savchenko wrote:
> On Sun, 26 Apr 2020 18:33:46 +0300 Dmitry V. Levin wrote:
> > On Sun, Apr 26, 2020 at 05:35:24PM +0300, Michael Shigorin wrote:
> > > On Sun, Apr 26, 2020 at 05:20:52PM +0300, Dmitry V. Levin wrote:
> > > > Присутствие texlive в сборочной среде - это, конечно, ужасно,
> > > > потому что нынешний texlive в Сизифе - это что-то совершенно
> > > > непотребное
> > > 
> > > viy@ пытался собрать его в мелконарезанном виде, сам помнишь.
> > 
> > С неадекватным генератором зависимостей это была мертворождённая идея,
> > в лучшем случае получился бы тот же монстр, что и сейчас, но из нескольких
> > тысяч пакетов, а в худшем - нерабочий texlive.
> 
> Он был вполне работающим. Генератор зависемостей там не идеальный,
> но выдающий работоспособный результат.

Не идеальный?  Да он полсизифа вытягивал, пока я в
texlive-texmf-2019-alt2_7.src.rpm гвоздей не заколотил,
теперь только четверть сизифа вытягивает.

> Реальная причина проблем:
> неэффективно реализованный install check на нашей сборочнице, если
> вообще не сказать отвратительно работающий. Он работает настолько
> плохо, что на железе послабее пришлось вовсе отключить и без всяких
> texlive. Но эта проблема молча игнорируется, вместо чего все
> стрелки переводятся на texlive.

Не понимаю, о чём идёт речь, install check включён на всех архитектурах.

Если речь идёт про ваш e2k, то чем меньше вы будете говорить,
что вы там ещё отключили, тем менее плохо мы будем о вас думать.

> Я хочу сказать отдельное спасибо viy@ за то, что он обновил texlive
> и вместо почти не пригодного к использованию tevlive-2008 (я не мог
> скомпилировать там большинство своих презентаций и статей из-за
> отсутствующей функциональности) мы теперь имеем вполне пригодный
> к работе texlive-2019, пусть и не идеально упакованный.

Отвратительно упакованный, мне пришлось для него отдельный чрут соорудить,
потому что в хост-систему такое ставить немыслимо.

viy@ можно и нужно много за что сказать спасибо,
но за нынешний texlive у меня язык не повернётся поблагодарить.


-- 
ldv

Re: [devel] про texlive

[Andrey Savchenko]

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

On Sun, 26 Apr 2020 20:36:44 +0300 Dmitry V. Levin wrote:
> On Sun, Apr 26, 2020 at 06:54:27PM +0300, Andrey Savchenko wrote:
> > On Sun, 26 Apr 2020 18:33:46 +0300 Dmitry V. Levin wrote:
> > > On Sun, Apr 26, 2020 at 05:35:24PM +0300, Michael Shigorin wrote:
> > > > On Sun, Apr 26, 2020 at 05:20:52PM +0300, Dmitry V. Levin wrote:
> > > > > Присутствие texlive в сборочной среде - это, конечно, ужасно,
> > > > > потому что нынешний texlive в Сизифе - это что-то совершенно
> > > > > непотребное
> > > > 
> > > > viy@ пытался собрать его в мелконарезанном виде, сам помнишь.
> > > 
> > > С неадекватным генератором зависимостей это была мертворождённая идея,
> > > в лучшем случае получился бы тот же монстр, что и сейчас, но из нескольких
> > > тысяч пакетов, а в худшем - нерабочий texlive.
> > 
> > Он был вполне работающим. Генератор зависемостей там не идеальный,
> > но выдающий работоспособный результат.
> 
> Не идеальный?  Да он полсизифа вытягивал, пока я в
> texlive-texmf-2019-alt2_7.src.rpm гвоздей не заколотил,
> теперь только четверть сизифа вытягивает.

Я не верю этим словам. Цифры, пожалуйста. Сейчас Сизиф —
это 48395 бинарных пакетов на (x86_64 + noarch).
Следовательно, даже при округлении вниз, полсизифа — это 24197
пакетов и четверть сизифа — 12098 пакетов. texlive тянет примерно
на пару порядков меньше.

> > Реальная причина проблем:
> > неэффективно реализованный install check на нашей сборочнице, если
> > вообще не сказать отвратительно работающий. Он работает настолько
> > плохо, что на железе послабее пришлось вовсе отключить и без всяких
> > texlive. Но эта проблема молча игнорируется, вместо чего все
> > стрелки переводятся на texlive.
> 
> Не понимаю, о чём идёт речь, install check включён на всех архитектурах.
> 
> Если речь идёт про ваш e2k, то чем меньше вы будете говорить,
> что вы там ещё отключили, тем менее плохо мы будем о вас думать.

Install check там выключен по одной простой причине: там DDR3
память, которая не справляется с вашим якобы корректно работающим
install check за разумное время. Вот и возникает вопрос
в целесообразности таких проверок. Тем более, что много раз
обсуждалось как можно улучшить эту проверку, но никому нет дела.
Особо подчеркну, что в моём понимании "корректность работы" — это
не только математическая самосогласованность выполняемой операции,
но и её практическая осуществимость, а равно целесообразность.

> > Я хочу сказать отдельное спасибо viy@ за то, что он обновил texlive
> > и вместо почти не пригодного к использованию tevlive-2008 (я не мог
> > скомпилировать там большинство своих презентаций и статей из-за
> > отсутствующей функциональности) мы теперь имеем вполне пригодный
> > к работе texlive-2019, пусть и не идеально упакованный.
> 
> Отвратительно упакованный, мне пришлось для него отдельный чрут соорудить,
> потому что в хост-систему такое ставить немыслимо.

Почему? Пару гигабайт на диске жалко?

> viy@ можно и нужно много за что сказать спасибо,
> но за нынешний texlive у меня язык не повернётся поблагодарить.

Ваши предложения? Использовать допотопный texlive, потому что он
идеологически правильно упакован? Или устанавливать texlive
самостоятельно вне репозитория, что приходилось делать людям до
выполненного viy@ обновления.

Best regards,
Andrew Savchenko

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

Re: [devel] про texlive и installcheck тысяч подзаданий

[Michael Shigorin]

On Mon, Apr 27, 2020 at 09:45:46AM +0300, Andrey Savchenko wrote:
> > > Реальная причина проблем:
> > > неэффективно реализованный install check на нашей сборочнице

В смысле последовательный, что в случае мегазаданий вроде kde
или python явно также не идёт на пользу.  Понятно, что сейчас
это архитектурное ограничение; жаль, что уже в эпоху не просто
SMP, а многоядерных процессоров решили сделать так, но бывает.

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

> > Не понимаю, о чём идёт речь, install check включён на всех
> > архитектурах.

Разве на aarch64 был включён и на ThunderX?
Не помню точно, но вроде тогда включать не стали.
(а если стали -- Черепанов, поди, передаёт приветы)

> > Если речь идёт про ваш e2k, то чем меньше вы будете говорить,
> > что вы там ещё отключили, тем менее плохо мы будем о вас думать.

Ну почему, временно(tm) отключенная ручка doc/docs/apidoc
не только оставила нас без порой полезного, но и вскрыла
некоторое количество разнокалиберных ляпов в спеках.
(понятно, что давным-давно пора её включать и чинить,
если что не станет собираться теперь -- этому сильно
мешала питонятина со sphinx, ныне побеждённая)

> Install check там выключен по одной простой причине: там DDR3
> память, которая не справляется с вашим якобы корректно
> работающим install check за разумное время.

DDR3 и на basalt, например -- она умеет работать быстрее.
На наших текущих сборочных узлах e2kv4 DDR3-1333 выдаёт
примерно до половины своей пиковой полосы пропускания,
которую я видел на x86_64 (правда, экстремально выжатых).

Там, как и на ThunderX, явно даёт знать ещё один вопрос:
ядер достаточно много, но каждое из них относительно x86_64
на задачах распаковки пакетов выходит существенно медленней.

> Вот и возникает вопрос в целесообразности таких проверок.
> Тем более, что много раз обсуждалось как можно улучшить эту
> проверку, но никому нет дела.

Насколько понимаю по обсуждениям переделки сборочницы --
дело есть, просто нетривиальное весьма.

> > viy@ можно и нужно много за что сказать спасибо, но за
> > нынешний texlive у меня язык не повернётся поблагодарить.
> Ваши предложения?

Давайте я скажу.  Дима, если тебя устраивал второй вариант
с мелкой порезкой, который Игорь собирал своей сборочницей
-- ну так обеспечь возможность прохождения такого в сизиф,
много у кого язык сразу повернётся поблагодарить вас обоих
;-)

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] про texlive и installcheck тысяч подзаданий

[mcpain]

В письме от понедельник, 27 апреля 2020 г. 11:11:42 MSK пользователь 
Michael Shigorin написал:
> On Mon, Apr 27, 2020 at 09:45:46AM +0300, Andrey Savchenko wrote:
> > > > Реальная причина проблем:
> > > > неэффективно реализованный install check на нашей сборочнице
> 
> В смысле последовательный, что в случае мегазаданий вроде kde
> или python явно также не идёт на пользу.

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

А в идеале - анализировать зависимости пакета и вычислять тот минимум, 
который нужно установить вручную, чтобы по зависимостям вытянулось всё 
остальное и тогда во время проверки будет создаваться меньше chroot'ов

Re: [devel] про texlive и installcheck тысяч подзаданий

[Alexey V. Vissarionov]

On 2020-04-27 11:30:36 +0300, mcpain@altlinux.org wrote:

 >>>>> Реальная причина проблем: неэффективно реализованный
 >>>>> install check на нашей сборочнице
 >> В смысле последовательный, что в случае мегазаданий вроде
 >> kde или python явно также не идёт на пользу.
 > Более того, он выполняет кучу лишней работы в случае, когда
 > в первую очередь проверяется пакет, установка которого тащит
 > по зависимостям всё остальное и было бы хорошо такие пакеты
 > помечать как OК, потому что они тоже установились.

Скорее всего, они так уже помечены. За исключением очевидного
случая, когда эти зависимости были собраны в том же задании
(типичный пример: %name требует lib%name = %version-%release).

 > А в идеале - анализировать зависимости пакета и вычислять
 > тот минимум, который нужно установить вручную, чтобы
 > по зависимостям вытянулось всё остальное и тогда
 > во время проверки будет создаваться меньше chroot'ов

Это просто по уму. В идеале - еще и минимизировать эти самые
установочные зависимости.


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

Re: [devel] про texlive и installcheck тысяч (под)пакетов

[Michael Shigorin]

On Mon, Apr 27, 2020 at 11:40:29AM +0300, Alexey V. Vissarionov wrote:
> >> В смысле последовательный, что в случае мегазаданий вроде
> >> kde или python явно также не идёт на пользу.
> > Более того, он выполняет кучу лишней работы в случае, когда
> > в первую очередь проверяется пакет, установка которого тащит
> > по зависимостям всё остальное и было бы хорошо такие пакеты
> > помечать как OК, потому что они тоже установились.
> Скорее всего, они так уже помечены. За исключением очевидного
> случая, когда эти зависимости были собраны в том же задании
> (типичный пример: %name требует lib%name = %version-%release).

Я криво дополнил тему, прошу прощения.  Итерация-то идёт
по собранным бинарным пакетам, а не просто подзаданиям.
Иначе конфликтующие подпакеты пакета из подзадания
проверку не могли бы пройти в принципе.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] про texlive и installcheck тысяч подзаданий

[Andrey Savchenko]

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

On Mon, 27 Apr 2020 11:30:36 +0300 mcpain@altlinux.org wrote:
> В письме от понедельник, 27 апреля 2020 г. 11:11:42 MSK пользователь 
> Michael Shigorin написал:
> > On Mon, Apr 27, 2020 at 09:45:46AM +0300, Andrey Savchenko wrote:
> > > > > Реальная причина проблем:
> > > > > неэффективно реализованный install check на нашей сборочнице
> > 
> > В смысле последовательный, что в случае мегазаданий вроде kde
> > или python явно также не идёт на пользу.
> 
> Более того, он выполняет кучу лишней работы в случае, когда в первую 
> очередь проверяется пакет, установка которого тащит по зависимостям всё 
> остальное и было бы хорошо такие пакеты помечать как OК, потому что они 
> тоже установились.
> 
> А в идеале - анализировать зависимости пакета и вычислять тот минимум, 
> который нужно установить вручную, чтобы по зависимостям вытянулось всё 
> остальное и тогда во время проверки будет создаваться меньше chroot'ов

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

Best regards,
Andrew Savchenko

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

Re: [devel] про texlive и installcheck тысяч подзаданий

[Michael Shigorin]

On Mon, Apr 27, 2020 at 11:40:53AM +0300, Andrey Savchenko wrote:
> Ещё можно повторно использовать образ, в который устанавливался
> пакет, чтоб для большого числа подпакетов не делать одну и ту же
> работу много раз. В зависимости от реализации это может немного
> уменьшить точность теста, но зато сильно его ускорит.

Сломается на конфликтующих.  Понятно, что в принципе это
параллелить надо, но для начала можно попробовать сделать
разделяемый hasher cache -- когда-то при экспериментах
над mkimage* мне это довольно заметно помогло (~5--10%):
последовательно собираемые стадии брали один архив чрута.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] про texlive и installcheck тысяч подзаданий

[Andrey Savchenko]

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

On Mon, 27 Apr 2020 12:01:40 +0300 Michael Shigorin wrote:
> On Mon, Apr 27, 2020 at 11:40:53AM +0300, Andrey Savchenko wrote:
> > Ещё можно повторно использовать образ, в который устанавливался
> > пакет, чтоб для большого числа подпакетов не делать одну и ту же
> > работу много раз. В зависимости от реализации это может немного
> > уменьшить точность теста, но зато сильно его ускорит.
> 
> Сломается на конфликтующих.

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

> Понятно, что в принципе это
> параллелить надо, но для начала можно попробовать сделать
> разделяемый hasher cache -- когда-то при экспериментах
> над mkimage* мне это довольно заметно помогло (~5--10%):
> последовательно собираемые стадии брали один архив чрута.

Это тоже полезно, но тот же параллелизм даст прирост в разы
пропрорционально числу ядер (при условии достаточного количества
памяти и остальных ресурсов).

Best regards,
Andrew Savchenko

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

Re: [devel] про texlive и installcheck тысяч подзаданий

[Michael Shigorin]

On Mon, Apr 27, 2020 at 11:30:36AM +0300, mcpain@altlinux.org wrote:
> А в идеале - анализировать зависимости пакета и вычислять тот минимум, 
> который нужно установить вручную, чтобы по зависимостям вытянулось всё 
> остальное и тогда во время проверки будет создаваться меньше chroot'ов

Тут минимум два подводных камня:
- бывают конфликтующие (под)пакеты;
- диагностика проблем наверняка усложнится.

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

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Kirill Maslinsky]

Dmitry V. Levin writes:

>> > hasher-priv: master: idle time limit (3600 seconds) exceeded
>> > 2020-Apr-25 21:46:14 :: [ppc64le] R-base.git 4.0.0-alt1: remote: build failed
>> > 2020-Apr-25 21:46:14 :: [ppc64le] #300 R-base.git 4.0.0-alt1: build FAILED
>> 
>> Вероятно, этот timeout на ppc64le связан с присутствием texlive в
>> сборочных зависимостях R?
>
> Присутствие texlive в сборочной среде - это, конечно, ужасно, потому что
> нынешний texlive в Сизифе - это что-то совершенно непотребное,

texlive в Сизифе пока не могу принять на свой счет, R собирает ТеХом
документацию, может быть, это можно оторвать, но кажется, сейчас не
самый подходящий момент. R в Сизифе уже почти год не пересобирается. 

> но timeout
> связан с чем-то другим, поскольку, во-первых, время создания сборочной
> среды учитывается отдельно, и, во-вторых, на соседних архитектурах сборка
> этого подзадания заняла меньше 16 минут.

А как бы получить более подробную диагностическую информацию?

-- 
KM

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Kirill Maslinsky]

Dmitry V. Levin writes:

>> > http://git.altlinux.org/tasks/238855/logs/events.4.1.log

[...let's save texlive flame for another time...]

> , но timeout
> связан с чем-то другим, поскольку, во-первых, время создания сборочной
> среды учитывается отдельно, и, во-вторых, на соседних архитектурах сборка
> этого подзадания заняла меньше 16 минут.

Сравнил логи сборки ppc64le и x86_64, никаких существенных различий не
вижу, кроме, может быть, меньшего количества ядер на ppc

-+ make -j32
++ make -j132

В остальном сборка на ppc идёт гладко и обрывается примерно in the
middle of nowhere, это даже не переход к другой фазе сборки, на x86_64
после этого момента просто продолжается сборка по подкаталогам src/library:

make[5]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
ppc64le-alt-linux-gcc -shared -L../../../../lib -L/usr/local/lib64 -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[5]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
make[6]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[6]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'

hasher-priv: master: idle time limit (3600 seconds) exceeded
hsh-rebuild: rebuild of `R-base-4.0.0-alt1.src.rpm' failed.
                                                                                              
Уважаемые знатоки ppc64le и сборочных сред, было бы интересно услышать
ваши гипотезы и предложения. 

-- 
KM

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Anton Farygin]

On 27.04.2020 11:48, Kirill Maslinsky wrote:
> -+ make -j32
> ++ make -j132

-j132 выглядит очень сурово. Можно было бы попробовать поприжать.

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Andrey Savchenko]

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

On Mon, 27 Apr 2020 13:57:32 +0300 Anton Farygin wrote:
> On 27.04.2020 11:48, Kirill Maslinsky wrote:
> > -+ make -j32
> > ++ make -j132
> 
> -j132 выглядит очень сурово. Можно было бы попробовать поприжать.

Сколько ядер, столько -j — это норма©™.
Если это баг системы сборки, нужно бы отладить.
У нас есть возможность дать разработчикам шелл на ppc64le?

Best regards,
Andrew Savchenko

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

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Michael Shigorin]

On Mon, Apr 27, 2020 at 01:57:32PM +0300, Anton Farygin wrote:
> On 27.04.2020 11:48, Kirill Maslinsky wrote:
> > -+ make -j32
> > ++ make -j132
> -j132 выглядит очень сурово. Можно было бы попробовать поприжать.

Ну там это %__nprocs и памяти будто достаточно.

-- 
 ---- WBR, Michael Shigorin / http://altlinux.org
  ------ http://opennet.ru / http://anna-news.info

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Dmitry V. Levin]

On Mon, Apr 27, 2020 at 11:48:32AM +0300, Kirill Maslinsky wrote:
> 
> Dmitry V. Levin writes:
> 
> >> > http://git.altlinux.org/tasks/238855/logs/events.4.1.log
> 
> [...let's save texlive flame for another time...]

Там в логе сборки ещё наблюдается
checking for latex inconsolata package... missing
configure: WARNING: neither inconsolata.sty nor zi4.sty found: PDF vignettes and package manuals will not be rendered optimally

> > , но timeout
> > связан с чем-то другим, поскольку, во-первых, время создания сборочной
> > среды учитывается отдельно, и, во-вторых, на соседних архитектурах сборка
> > этого подзадания заняла меньше 16 минут.
> 
> Сравнил логи сборки ppc64le и x86_64, никаких существенных различий не
> вижу, кроме, может быть, меньшего количества ядер на ppc
> 
> -+ make -j32
> ++ make -j132

Я попробовал с -j1, результат аналогичный:
+ make -j1
...
ppc64le-alt-linux-gcc -shared -L../../../../lib -L/usr/local/lib64 -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -L../../../../lib -lR
make[6]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
mkdir -p -- ../../../../library/tools/libs
make[6]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
make[5]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
make[4]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'
make[4]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'
installing 'sysdata.rda'

hasher-priv: master: idle time limit (3600 seconds) exceeded


-- 
ldv

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Dmitry V. Levin]

On Mon, Apr 27, 2020 at 03:00:56PM +0300, Dmitry V. Levin wrote:
> On Mon, Apr 27, 2020 at 11:48:32AM +0300, Kirill Maslinsky wrote:
> > 
> > Dmitry V. Levin writes:
> > 
> > >> > http://git.altlinux.org/tasks/238855/logs/events.4.1.log
> > 
> > [...let's save texlive flame for another time...]
> 
> Там в логе сборки ещё наблюдается
> checking for latex inconsolata package... missing
> configure: WARNING: neither inconsolata.sty nor zi4.sty found: PDF vignettes and package manuals will not be rendered optimally
> 
> > > , но timeout
> > > связан с чем-то другим, поскольку, во-первых, время создания сборочной
> > > среды учитывается отдельно, и, во-вторых, на соседних архитектурах сборка
> > > этого подзадания заняла меньше 16 минут.
> > 
> > Сравнил логи сборки ppc64le и x86_64, никаких существенных различий не
> > вижу, кроме, может быть, меньшего количества ядер на ppc
> > 
> > -+ make -j32
> > ++ make -j132
> 
> Я попробовал с -j1, результат аналогичный:
> + make -j1
> ...
> ppc64le-alt-linux-gcc -shared -L../../../../lib -L/usr/local/lib64 -o tools.so text.o init.o Rmd5.o md5.o signals.o install.o getfmts.o http.o gramLatex.o gramRd.o -L../../../../lib -lR
> make[6]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
> mkdir -p -- ../../../../library/tools/libs
> make[6]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
> make[5]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools/src'
> make[4]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'
> make[4]: Entering directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'
> installing 'sysdata.rda'
> 
> hasher-priv: master: idle time limit (3600 seconds) exceeded

Судя по тому, что сразу после фразы
installing 'sysdata.rda'
в логе не последовало фразы
make[4]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'
можно сделать вывод о том, что операция
installing 'sysdata.rda'
зависла.

В файле share/make/basepkg.mk на эту тему написано следующее:

sysdata: $(srcdir)/R/sysdata.rda
        @$(ECHO) "installing 'sysdata.rda'"
        @$(ECHO) "tools:::sysdata2LazyLoadDB(\"$(srcdir)/R/sysdata.rda\",\"$(top_builddir)/library/$(pkg)/R\")" | \
          R_DEFAULT_PACKAGES=NULL LC_ALL=C $(R_EXE)

Получается, что $(R_EXE) просто зависло.


-- 
ldv

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Kirill Maslinsky]

Dmitry V. Levin writes:

> On Mon, Apr 27, 2020 at 03:00:56PM +0300, Dmitry V. Levin wrote:

> Судя по тому, что сразу после фразы
> installing 'sysdata.rda'
> в логе не последовало фразы
> make[4]: Leaving directory '/usr/src/RPM/BUILD/R-4.0.0/src/library/tools'

[...]

> Получается, что $(R_EXE) просто зависло.

Спасибо, Дима. А можно и правда shell на ppc64le, чтобы попробовать
разобраться, что там не так $(R_EXE)?

--
КМ

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Kirill Maslinsky]

Dmitry V. Levin writes:

> Получается, что $(R_EXE) просто зависло.

$(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
вообще всегда при запуске. Похоже, это происходит вот в этом цикле:

http://git.altlinux.org/people/kirill/packages/R-base.git?p=R-base.git;a=blob;f=src/main/machar.c;h=8db54f1350fe85b0204c7affb4ef79180fc3e5ad;hb=edfd434c0f879f16a9a8f124648df4b4eb23a7e3#l156

src/main/machar.c

155         for(;;) {
156                 temp = one - a;
157                 if (temp - one != zero)
158                         break;
159                 a = a * beta;
160                 *negep = *negep - 1;
161         }

Что бы это могло быть?

--
КМ

Re: [devel] [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1

[Vladislav Zavjalov]

On Tue, Apr 28, 2020 at 10:53:03PM +0300, Kirill Maslinsky wrote:
> 
> Dmitry V. Levin writes:
> 
> > Получается, что $(R_EXE) просто зависло.
> 
> $(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
> вообще всегда при запуске. Похоже, это происходит вот в этом цикле:
> 
> http://git.altlinux.org/people/kirill/packages/R-base.git?p=R-base.git;a=blob;f=src/main/machar.c;h=8db54f1350fe85b0204c7affb4ef79180fc3e5ad;hb=edfd434c0f879f16a9a8f124648df4b4eb23a7e3#l156
> 
> src/main/machar.c
> 
> 155         for(;;) {
> 156                 temp = one - a;
> 157                 if (temp - one != zero)
> 158                         break;
> 159                 a = a * beta;
> 160                 *negep = *negep - 1;
> 161         }
> 
> Что бы это могло быть?

Я нашел какие-то ошибки про особенности long double на ppc64.
(например, https://github.com/numpy/numpy/issues/10281)
Там советуют собирать с -mabi=ieeelongdouble.

[devel] Минутка математики (Was: Re: [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1)

[Alexey Sheplyakov]

Здравствуйте!

On Tue, Apr 28, 2020 at 10:53:03PM +0300, Kirill Maslinsky wrote:
 
> $(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
> вообще всегда при запуске. Похоже, это происходит вот в этом цикле:
> 
> http://git.altlinux.org/people/kirill/packages/R-base.git?p=R-base.git;a=blob;f=src/main/machar.c;h=8db54f1350fe85b0204c7affb4ef79180fc3e5ad;hb=edfd434c0f879f16a9a8f124648df4b4eb23a7e3#l156
> 
> src/main/machar.c
> 
> 155         for(;;) {
> 156                 temp = one - a;
> 157                 if (temp - one != zero)
> 158                         break;
> 159                 a = a * beta;
> 160                 *negep = *negep - 1;
> 161         }
> 
> Что бы это могло быть?

Исходя из базы (beta) и длины мантиссы (it) пытаются вычислить минимальное
число eps, такое, что 1.0 - eps != 1.0 (точнее, его логарифм по основанию
beta). Когда этот код писали, еще не было стандарта IEEE 754, <float.h>,
макросов {FLT,DBL,LDBL}_EPS. Приходилось вот так изворачиваться.

Но на ppc64 (и некоторых SPARCv9) вместо нормального (IEEE 754) long doulbe
почему-то используется double double, т.е. представление числа в виде пары
(суммы) двух double. При таком способе большИе числа можно представить
точнее, чем double. Например, число 2^53 1/2 можно точно (без округления)
представить в виде cуммы "большого" числа 2^53 и "маленького" 1/2. А в double
такое число не влезет, 53 бит не хватит, придется округлять. Причем диапазон
"маленького" числа гораздо шире, чем у целого той же разрядности (53 бита),
ведь есть 11-битный показатель, и им можно масштабировать! Но не выйдет
представить с большей (чем double) точностью положительное число, меньшее
2^{-1021}, по той же причине -- показатель все равно 11 бит. Таким образом,
у double double длина мантиссы не постоянна и зависит от показателя.
А функция MACH_NAME исходит из обратного, т.е. из (в общем-то разумного)
предположения, что длина мантисы фиксирована.


А теперь вернемся к 1 + eps != 1.0. С помощью "честного" числа с плавающей
точкой с длиной мантисы 106 бит (что соответствует паре double) можно
представить b1.0000{100 нулей}1, или 1 + 1/2^105. А с помощью double double
можно представить даже b1.0{1019 нулей}1 в виде пары (1, 1/2^(-1021)).
Потому попытка искать с 

149         *negep = *it + 3;

или -109, и в дальнейшем *увеличивать* показатель

155         for(;;) {
156                 temp = one - a;
157                 if (temp - one != zero)
158                         break;
159                 a = a * beta;
160                 *negep = *negep - 1;
161         }

заведомо обречена. Поэтому этот цикл никогда не закончится (ну, может
когда int со знаком переполнится).

К счастью, "подарок" от IBM (double double) легко отключть с помощью флагов
компиляции

-mabi=ieeelongdouble -mlong-double-128

Такие дела. Простите за много букв.

Всего доброго,
    Алексей

Re: [devel] Минутка математики (Was: Re: [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1)

[Kirill Maslinsky]

Alexey Sheplyakov writes:

>> $(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
>> вообще всегда при запуске. Похоже, это происходит вот в этом цикле:

[...]

> К счастью, "подарок" от IBM (double double) легко отключть с помощью флагов
> компиляции
>
> -mabi=ieeelongdouble -mlong-double-128
>
> Такие дела. Простите за много букв.

Алексей, спасибо огромное за столь подробное объяснение! С этими флагами
R на ppc64le действительно собрался, но теперь падают тесты. Буду
разбираться дальше.

--
KM

Re: [devel] Минутка математики (Was: Re: [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1)

[Alexey Sheplyakov]

Добрый день!

On Wed, Apr 29, 2020 at 06:09:39PM +0300, Kirill Maslinsky wrote:
> 
> Alexey Sheplyakov writes:
> 
> >> $(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
> >> вообще всегда при запуске. Похоже, это происходит вот в этом цикле:
> 
> [...]
> 
> > К счастью, "подарок" от IBM (double double) легко отключть с помощью флагов
> > компиляции
> >
> > -mabi=ieeelongdouble -mlong-double-128
> >
> > Такие дела. Простите за много букв.
> 
> Алексей, спасибо огромное за столь подробное объяснение! С этими флагами
> R на ppc64le действительно собрался, но теперь падают тесты. Буду
> разбираться дальше.

Мне следовало написать точнее. Весь мой рассказ не следует воспринимать
как однозначную рекомендацию использовать стандартный long double (хотя
это и кажется логичным). Я пояснил (в меру своего понимания), что именно
происходит, и почему оно происходит именно так. Решений же возможно
несколько, как минимум

1) Адаптировать проблемный код для работы с double double [очень сложно]
2) Научить R использовать только float, double на ppc64 
3) Использовать стандартный long doulbe на ppc64, т.е.
   -mabi=ieeelongdouble -mlong-double-128
   Но в этом случае нужно использовать стандартный long double не
   только в собственно R, но и всех библиотеках, которые использует R:
   blas, lapack, ..., libm (тут возникает вопрос -- а как это повлияет
   на других "пользователях" этих библиотек, и ответа на него я не знаю)

Re: [devel] Минутка математики (Was: Re: [#238855] [test-only] FAILED (try 4) openblas.git=0.3.9-alt1 R-base.git=4.0.0-alt1)

[Alexey Sheplyakov]

On Wed, Apr 29, 2020 at 04:56:16PM +0400, Alexey Sheplyakov wrote:

> > $(R_EXE) на ppc64le зависает не в специфическом месте при сборке, а
> > вообще всегда при запуске. Похоже, это происходит вот в этом цикле:
> > 
> > http://git.altlinux.org/people/kirill/packages/R-base.git?p=R-base.git;a=blob;f=src/main/machar.c;h=8db54f1350fe85b0204c7affb4ef79180fc3e5ad;hb=edfd434c0f879f16a9a8f124648df4b4eb23a7e3#l156
> > 
> > src/main/machar.c
> > 
> > 155         for(;;) {
> > 156                 temp = one - a;
> > 157                 if (temp - one != zero)
> > 158                         break;
> > 159                 a = a * beta;
> > 160                 *negep = *negep - 1;
> > 161         }
> > 
> > Что бы это могло быть?
> 
> Исходя из базы (beta) и длины мантиссы (it) пытаются вычислить минимальное
> число eps, такое, что 1.0 - eps != 1.0 (точнее, его логарифм по основанию
> beta). Когда этот код писали, еще не было стандарта IEEE 754, <float.h>,
> макросов {FLT,DBL,LDBL}_EPS. Приходилось вот так изворачиваться.
> 
> Но на ppc64 (и некоторых SPARCv9) вместо нормального (IEEE 754) long doulbe
> почему-то используется double double, т.е. представление числа в виде пары
> (суммы) двух double. При таком способе большИе числа можно представить
> точнее, чем double. Например, число 2^53 1/2 можно точно (без округления)
> представить в виде cуммы "большого" числа 2^53 и "маленького" 1/2. А в double
> такое число не влезет, 53 бит не хватит, придется округлять. Причем диапазон
> "маленького" числа гораздо шире, чем у целого той же разрядности (53 бита),
> ведь есть 11-битный показатель, и им можно масштабировать! Но не выйдет
> представить с большей (чем double) точностью положительное число, меньшее
> 2^{-1021}, по той же причине -- показатель все равно 11 бит. Таким образом,
> у double double длина мантиссы не постоянна и зависит от показателя.
> А функция MACH_NAME исходит из обратного, т.е. из (в общем-то разумного)
> предположения, что длина мантисы фиксирована.
> 
> 
> А теперь вернемся к 1 + eps != 1.0. С помощью "честного" числа с плавающей
> точкой с длиной мантисы 106 бит (что соответствует паре double) можно
> представить b1.0000{100 нулей}1, или 1 + 1/2^105. А с помощью double double
> можно представить даже b1.0{1019 нулей}1 в виде пары (1, 1/2^(-1021)).

Имеется в виду пара (1, 1/2^1021), конечно же. Прошу прощения за опечатку.

> Потому попытка искать с 
> 
> 149         *negep = *it + 3;
> 
> или -109, и в дальнейшем *увеличивать* показатель
> 
> 155         for(;;) {
> 156                 temp = one - a;
> 157                 if (temp - one != zero)
> 158                         break;
> 159                 a = a * beta;
> 160                 *negep = *negep - 1;
> 161         }
> 
> заведомо обречена. Поэтому этот цикл никогда не закончится (ну, может
> когда int со знаком переполнится).
> 
> К счастью, "подарок" от IBM (double double) легко отключть с помощью флагов
> компиляции
> 
> -mabi=ieeelongdouble -mlong-double-128
>