[devel] I: cmake macros

[devel] I: cmake macros

[Arseny Maslennikov]

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

Hi!

Вчера прошло задание 269879 с cmake 3.19.7-alt3.
Описание изменения и цели, которые оно должно было достигнуть, я
поместил на страничку https://www.altlinux.org/CMakeMigration2021,
чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
обсудить подробности, это всё ещё можно сделать)

Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
совсем тривиальным причинам, были обновлены в том же задании, но не все;
далее о тех, кто остался.

Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
спеках которых есть "%cmake_build VERBOSE=1":
% git grep -F '%cmake_build VERBOSE=1' | wc
     32      68    1508
Сейчас verbose передаётся по умолчанию (можно было так не делать, но
спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
предпочтении мейнтейнеров — поэтому и было принято такое решение).

Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
опции --verbose, если вам так больше нравится. (Некоторые пакеты я успел
исправить лично; к слову, там были накручены в виде makeflags либо
вообще неактуальные переменные, либо ныне настраиваемые по-другому)

Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
в задании 272559, совместимый и с текущими спеками в p9 на момент его
составления, и с копируемыми спеками из Сизифа.
Я сначала займусь этим заданием (потому что копирование спеков сейчас
затруднено, уже были жалобы в личку), а после буду исправлять оставшиеся
пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.

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

Re: [devel] I: cmake macros

[Andrey Cherepanov]

31.05.2021 12:20, Arseny Maslennikov пишет:
> Hi!
>
> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> Описание изменения и цели, которые оно должно было достигнуть, я
> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> обсудить подробности, это всё ещё можно сделать)
>
> Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
> совсем тривиальным причинам, были обновлены в том же задании, но не все;
> далее о тех, кто остался.
>
> Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
> спеках которых есть "%cmake_build VERBOSE=1":
> % git grep -F '%cmake_build VERBOSE=1' | wc
>       32      68    1508
> Сейчас verbose передаётся по умолчанию (можно было так не делать, но
> спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
> предпочтении мейнтейнеров — поэтому и было принято такое решение).
>
> Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
> вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
> опции --verbose, если вам так больше нравится. (Некоторые пакеты я успел
> исправить лично; к слову, там были накручены в виде makeflags либо
> вообще неактуальные переменные, либо ныне настраиваемые по-другому)
>
> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
> в задании 272559, совместимый и с текущими спеками в p9 на момент его
> составления, и с копируемыми спеками из Сизифа.
> Я сначала займусь этим заданием (потому что копирование спеков сейчас
> затруднено, уже были жалобы в личку), а после буду исправлять оставшиеся
> пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.

Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов. 
Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: cmake macros

[Grigory Ustinov]

31.05.2021 13:09, Andrey Cherepanov пишет:
> 31.05.2021 12:20, Arseny Maslennikov пишет:
>> Hi!
>>
>> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
>> Описание изменения и цели, которые оно должно было достигнуть, я
>> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
>> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
>> обсудить подробности, это всё ещё можно сделать)
>>
>> Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
>> совсем тривиальным причинам, были обновлены в том же задании, но не все;
>> далее о тех, кто остался.
>>
>> Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
>> спеках которых есть "%cmake_build VERBOSE=1":
>> % git grep -F '%cmake_build VERBOSE=1' | wc
>>       32      68    1508
>> Сейчас verbose передаётся по умолчанию (можно было так не делать, но
>> спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
>> предпочтении мейнтейнеров — поэтому и было принято такое решение).
>>
>> Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
>> вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
>> опции --verbose, если вам так больше нравится. (Некоторые пакеты я успел
>> исправить лично; к слову, там были накручены в виде makeflags либо
>> вообще неактуальные переменные, либо ныне настраиваемые по-другому)
>>
>> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
>> в задании 272559, совместимый и с текущими спеками в p9 на момент его
>> составления, и с копируемыми спеками из Сизифа.
>> Я сначала займусь этим заданием (потому что копирование спеков сейчас
>> затруднено, уже были жалобы в личку), а после буду исправлять оставшиеся
>> пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.
>
> Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов. 
> Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
Или исправить сломанные пакеты.

Re: [devel] I: cmake macros

[Andrey Cherepanov]

31.05.2021 13:22, Grigory Ustinov пишет:
>
> 31.05.2021 13:09, Andrey Cherepanov пишет:
>> 31.05.2021 12:20, Arseny Maslennikov пишет:
>>> Hi!
>>>
>>> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
>>> Описание изменения и цели, которые оно должно было достигнуть, я
>>> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
>>> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
>>> обсудить подробности, это всё ещё можно сделать)
>>>
>>> Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
>>> совсем тривиальным причинам, были обновлены в том же задании, но не 
>>> все;
>>> далее о тех, кто остался.
>>>
>>> Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
>>> спеках которых есть "%cmake_build VERBOSE=1":
>>> % git grep -F '%cmake_build VERBOSE=1' | wc
>>>       32      68    1508
>>> Сейчас verbose передаётся по умолчанию (можно было так не делать, но
>>> спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
>>> предпочтении мейнтейнеров — поэтому и было принято такое решение).
>>>
>>> Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
>>> вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
>>> опции --verbose, если вам так больше нравится. (Некоторые пакеты я 
>>> успел
>>> исправить лично; к слову, там были накручены в виде makeflags либо
>>> вообще неактуальные переменные, либо ныне настраиваемые по-другому)
>>>
>>> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
>>> в задании 272559, совместимый и с текущими спеками в p9 на момент его
>>> составления, и с копируемыми спеками из Сизифа.
>>> Я сначала займусь этим заданием (потому что копирование спеков сейчас
>>> затруднено, уже были жалобы в личку), а после буду исправлять 
>>> оставшиеся
>>> пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.
>>
>> Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов. 
>> Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
> Или исправить сломанные пакеты.

А в чём они сломаны, если собирались много лет?

-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 01:38:11PM +0300, Andrey Cherepanov wrote:
> 31.05.2021 13:22, Grigory Ustinov пишет:
> > 
> > 31.05.2021 13:09, Andrey Cherepanov пишет:
> > > 31.05.2021 12:20, Arseny Maslennikov пишет:
> > > > Hi!
> > > > 
> > > > Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> > > > Описание изменения и цели, которые оно должно было достигнуть, я
> > > > поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> > > > чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> > > > обсудить подробности, это всё ещё можно сделать)
> > > > 
> > > > Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
> > > > совсем тривиальным причинам, были обновлены в том же задании, но
> > > > не все;
> > > > далее о тех, кто остался.
> > > > 
> > > > Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
> > > > спеках которых есть "%cmake_build VERBOSE=1":
> > > > % git grep -F '%cmake_build VERBOSE=1' | wc
> > > >       32      68    1508
> > > > Сейчас verbose передаётся по умолчанию (можно было так не делать, но
> > > > спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
> > > > предпочтении мейнтейнеров — поэтому и было принято такое решение).
> > > > 
> > > > Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
> > > > вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
> > > > опции --verbose, если вам так больше нравится. (Некоторые пакеты
> > > > я успел
> > > > исправить лично; к слову, там были накручены в виде makeflags либо
> > > > вообще неактуальные переменные, либо ныне настраиваемые по-другому)
> > > > 
> > > > Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
> > > > в задании 272559, совместимый и с текущими спеками в p9 на момент его
> > > > составления, и с копируемыми спеками из Сизифа.
> > > > Я сначала займусь этим заданием (потому что копирование спеков сейчас
> > > > затруднено, уже были жалобы в личку), а после буду исправлять
> > > > оставшиеся
> > > > пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.
> > > 
> > > Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
> > > Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
> > Или исправить сломанные пакеты.
> 
> А в чём они сломаны, если собирались много лет?

Не ставят себе %_cmake__builddir и при этом явно обращаются к ./BUILD,
думая, что каталог именно там.

Да и кроме этого — не все из них собирались много лет, по всей видимости
(см. соседнее письмо про libvxl).

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

Re: [devel] I: cmake macros

[Andrey Cherepanov]

31.05.2021 13:50, Arseny Maslennikov пишет:
> On Mon, May 31, 2021 at 01:38:11PM +0300, Andrey Cherepanov wrote:
>> 31.05.2021 13:22, Grigory Ustinov пишет:
>>> 31.05.2021 13:09, Andrey Cherepanov пишет:
>>>> 31.05.2021 12:20, Arseny Maslennikov пишет:
>>>>> Hi!
>>>>>
>>>>> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
>>>>> Описание изменения и цели, которые оно должно было достигнуть, я
>>>>> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
>>>>> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
>>>>> обсудить подробности, это всё ещё можно сделать)
>>>>>
>>>>> Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
>>>>> совсем тривиальным причинам, были обновлены в том же задании, но
>>>>> не все;
>>>>> далее о тех, кто остался.
>>>>>
>>>>> Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
>>>>> спеках которых есть "%cmake_build VERBOSE=1":
>>>>> % git grep -F '%cmake_build VERBOSE=1' | wc
>>>>>        32      68    1508
>>>>> Сейчас verbose передаётся по умолчанию (можно было так не делать, но
>>>>> спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
>>>>> предпочтении мейнтейнеров — поэтому и было принято такое решение).
>>>>>
>>>>> Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
>>>>> вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
>>>>> опции --verbose, если вам так больше нравится. (Некоторые пакеты
>>>>> я успел
>>>>> исправить лично; к слову, там были накручены в виде makeflags либо
>>>>> вообще неактуальные переменные, либо ныне настраиваемые по-другому)
>>>>>
>>>>> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
>>>>> в задании 272559, совместимый и с текущими спеками в p9 на момент его
>>>>> составления, и с копируемыми спеками из Сизифа.
>>>>> Я сначала займусь этим заданием (потому что копирование спеков сейчас
>>>>> затруднено, уже были жалобы в личку), а после буду исправлять
>>>>> оставшиеся
>>>>> пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.
>>>> Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
>>>> Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
>>> Или исправить сломанные пакеты.
>> А в чём они сломаны, если собирались много лет?
> Не ставят себе %_cmake__builddir и при этом явно обращаются к ./BUILD,
> думая, что каталог именно там.
>
> Да и кроме этого — не все из них собирались много лет, по всей видимости
> (см. соседнее письмо про libvxl).

И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
конечно же, должны жить в состоянии перманентной революции без 
каких-либо улучшений?


-- 
Andrey Cherepanov
cas@altlinux.org

Re: [devel] noarch check failed

[Dmitry V. Levin]

On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> 31.05.2021 13:50, Arseny Maslennikov пишет:
[...]
> > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > (см. соседнее письмо про libvxl).
> 
> И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> конечно же, должны жить в состоянии перманентной революции без 
> каких-либо улучшений?

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


-- 
ldv

Re: [devel] noarch check failed

[Vladimir D. Seleznev]

On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > 31.05.2021 13:50, Arseny Maslennikov пишет:
> [...]
> > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > (см. соседнее письмо про libvxl).
> > 
> > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > конечно же, должны жить в состоянии перманентной революции без 
> > каких-либо улучшений?
> 
> Невозможность пересобрать пакеты из-за того, что инструмент сборки
> документации генерит нечто, зависящее от случайных событий - это серьёзная
> проблема, масштаб которой нужно срочно выяснить.

Очевидно, не от случайного события, а от путей каталога сборки. Пути
попадают в файлы документации; если путь каталога сборки включает в себя
имя целевой архитектуры, нельзя получить noarch-пакет.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] noarch check failed

[Dmitry V. Levin]

On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > [...]
> > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > (см. соседнее письмо про libvxl).
> > > 
> > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > конечно же, должны жить в состоянии перманентной революции без 
> > > каких-либо улучшений?
> > 
> > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > проблема, масштаб которой нужно срочно выяснить.
> 
> Очевидно, не от случайного события, а от путей каталога сборки.

Но зачем?


-- 
ldv

Re: [devel] noarch check failed

[Vladimir D. Seleznev]

On Mon, May 31, 2021 at 05:28:44PM +0300, Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> > On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > > [...]
> > > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > > (см. соседнее письмо про libvxl).
> > > > 
> > > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > > конечно же, должны жить в состоянии перманентной революции без 
> > > > каких-либо улучшений?
> > > 
> > > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > > проблема, масштаб которой нужно срочно выяснить.
> > 
> > Очевидно, не от случайного события, а от путей каталога сборки.
> 
> Но зачем?

Вопрос хороший, но в нашем случае другой вопрос: кто должен исправлять
документацию у полсотни пакетов и проталкивать исправления в апстримы?

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] noarch check failed

[Dmitry V. Levin]

On Mon, May 31, 2021 at 02:32:35PM +0000, Vladimir D. Seleznev wrote:
> On Mon, May 31, 2021 at 05:28:44PM +0300, Dmitry V. Levin wrote:
> > On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> > > On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > > > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > > > [...]
> > > > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > > > (см. соседнее письмо про libvxl).
> > > > > 
> > > > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > > > конечно же, должны жить в состоянии перманентной революции без 
> > > > > каких-либо улучшений?
> > > > 
> > > > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > > > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > > > проблема, масштаб которой нужно срочно выяснить.
> > > 
> > > Очевидно, не от случайного события, а от путей каталога сборки.
> > 
> > Но зачем?
> 
> Вопрос хороший, но в нашем случае другой вопрос: кто должен исправлять
> документацию у полсотни пакетов и проталкивать исправления в апстримы?

Инструменты не должны себя вести таким образом, это так себе reproducible build.


-- 
ldv

Re: [devel] noarch check failed

[Andrey Savchenko]

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

On Mon, 31 May 2021 17:55:43 +0300 Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 02:32:35PM +0000, Vladimir D. Seleznev wrote:
> > On Mon, May 31, 2021 at 05:28:44PM +0300, Dmitry V. Levin wrote:
> > > On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> > > > On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > > > > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > > > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > > > > [...]
> > > > > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > > > > (см. соседнее письмо про libvxl).
> > > > > > 
> > > > > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > > > > конечно же, должны жить в состоянии перманентной революции без 
> > > > > > каких-либо улучшений?
> > > > > 
> > > > > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > > > > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > > > > проблема, масштаб которой нужно срочно выяснить.
> > > > 
> > > > Очевидно, не от случайного события, а от путей каталога сборки.
> > > 
> > > Но зачем?
> > 
> > Вопрос хороший, но в нашем случае другой вопрос: кто должен исправлять
> > документацию у полсотни пакетов и проталкивать исправления в апстримы?
> 
> Инструменты не должны себя вести таким образом, это так себе reproducible build.

По-моему, перед doxygen никогда не ставилась задача
воспроизводимой сборки, по крайней мере апстримом, поскольку это
документация, а не исполняемый код. Там задача — просто build, из
того, что есть, ну а если какой-то бит от фазы луны зависит — кому
какое дело, если итоговый результат по сути своей тот же. С graphviz
(dot) — аналогичная ситуация.

Возможно, следует задуматься о выводе документации без исполняемых
файлов из под требования бинарной воспроизводимости.

Best regards,
Andrew Savchenko

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

Re: [devel] noarch check failed

[Vladimir D. Seleznev]

On Mon, May 31, 2021 at 05:55:43PM +0300, Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 02:32:35PM +0000, Vladimir D. Seleznev wrote:
> > On Mon, May 31, 2021 at 05:28:44PM +0300, Dmitry V. Levin wrote:
> > > On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> > > > On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > > > > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > > > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > > > > [...]
> > > > > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > > > > (см. соседнее письмо про libvxl).
> > > > > > 
> > > > > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > > > > конечно же, должны жить в состоянии перманентной революции без 
> > > > > > каких-либо улучшений?
> > > > > 
> > > > > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > > > > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > > > > проблема, масштаб которой нужно срочно выяснить.
> > > > 
> > > > Очевидно, не от случайного события, а от путей каталога сборки.
> > > 
> > > Но зачем?
> > 
> > Вопрос хороший, но в нашем случае другой вопрос: кто должен исправлять
> > документацию у полсотни пакетов и проталкивать исправления в апстримы?
> 
> Инструменты не должны себя вести таким образом, это так себе reproducible build.

Оно может быть воспроизводимо в пределах архитектуры.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] noarch check failed

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 02:26:04PM +0000, Vladimir D. Seleznev wrote:
> On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > [...]
> > > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > > (см. соседнее письмо про libvxl).
> > > 
> > > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > > конечно же, должны жить в состоянии перманентной революции без 
> > > каких-либо улучшений?
> > 
> > Невозможность пересобрать пакеты из-за того, что инструмент сборки
> > документации генерит нечто, зависящее от случайных событий - это серьёзная
> > проблема, масштаб которой нужно срочно выяснить.
> 
> Очевидно, не от случайного события, а от путей каталога сборки. Пути
> попадают в файлы документации;

Зря попадают...

> если путь каталога сборки включает в себя
> имя целевой архитектуры, нельзя получить noarch-пакет.

Или, как в случае uhd, в каталоги с документацией попадают от
этих путей хеши.

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

Re: [devel] noarch check failed

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > 31.05.2021 13:50, Arseny Maslennikov пишет:
> [...]
> > > Да и кроме этого — не все из них собирались много лет, по всей видимости
> > > (см. соседнее письмо про libvxl).
> > 
> > И зачем им понадобилось это усложнение на ровном месте? Мейнтейнеры, 
> > конечно же, должны жить в состоянии перманентной революции без 
> > каких-либо улучшений?
> 
> Невозможность пересобрать пакеты из-за того, что инструмент сборки
> документации генерит нечто, зависящее от случайных событий - это серьёзная
> проблема, масштаб которой нужно срочно выяснить.

На первый взгляд я бы смотрел в направлении doxygen.

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

Re: [devel] noarch check failed

[Yuri Sedunov]

В Пн, 31/05/2021 в 18:06 +0300, Arseny Maslennikov пишет:
> On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov wrote:
> > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > [...]
> > > > Да и кроме этого — не все из них собирались много лет, по всей
> > > > видимости (см. соседнее письмо про libvxl).
> > > 
> > > И зачем им понадобилось это усложнение на ровном месте?
> > > Мейнтейнеры, конечно же, должны жить в состоянии перманентной
> > > революции без каких-либо улучшений?
> > 
> > Невозможность пересобрать пакеты из-за того, что инструмент сборки 
> > документации генерит нечто, зависящее от случайных событий - это
> > серьёзная проблема, масштаб которой нужно срочно выяснить.
> 
> На первый взгляд я бы смотрел в направлении doxygen.

Наверно. В пакетах из #272282 документация, в которых собирается с
помощью doxygen наблюдается интересная закономерность размера от
архитектуры. 
$ for a in i586 x86_64 aarch64 armh ppc64le; do echo -ne $a:\\t; rpmq -
p --queryformat '%{SIZE}\n'
"http://git.altlinux.org/tasks/272282/build/400/$a/rpms/libglibmm-doc-2.66.1-alt1.noarch.rpm
"; done
i586:	40241540
x86_64:	40244966
aarch64:	40244902
armh:	40244902
ppc64le:	40244902

$ for a in i586 x86_64 aarch64 armh ppc64le; do echo -ne $a:\\t; rpmq -
p --queryformat '%{SIZE}\n'
"http://git.altlinux.org/tasks/272282/build/500/$a/rpms/libglibmm2.68-devel-doc-2.68.1-alt1.noarch.rpm
"; done
i586:	38291881
x86_64:	38291905
aarch64:	38291901
armh:	38291901
ppc64le:	38291901




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

-- 
Yuri N. Sedunov

Re: [devel] noarch check failed

[Yuri Sedunov]

В Пн, 31/05/2021 в 18:52 +0300, Yuri Sedunov пишет:
> В Пн, 31/05/2021 в 18:06 +0300, Arseny Maslennikov пишет:
> > On Mon, May 31, 2021 at 02:53:51PM +0300, Dmitry V. Levin wrote:
> > > On Mon, May 31, 2021 at 02:06:10PM +0300, Andrey Cherepanov
> > > wrote:
> > > > 31.05.2021 13:50, Arseny Maslennikov пишет:
> > > [...]
> > > > > Да и кроме этого — не все из них собирались много лет, по
> > > > > всей
> > > > > видимости (см. соседнее письмо про libvxl).
> > > > 
> > > > И зачем им понадобилось это усложнение на ровном месте?
> > > > Мейнтейнеры, конечно же, должны жить в состоянии перманентной
> > > > революции без каких-либо улучшений?
> > > 
> > > Невозможность пересобрать пакеты из-за того, что инструмент
> > > сборки документации генерит нечто, зависящее от случайных событий
> > > - это серьёзная проблема, масштаб которой нужно срочно выяснить.
> > 
> > На первый взгляд я бы смотрел в направлении doxygen.
> 
> Наверно. В пакетах из #272282 документация, в которых собирается с
> помощью doxygen наблюдается интересная закономерность размера от
> архитектуры. 
> $ for a in i586 x86_64 aarch64 armh ppc64le; do echo -ne $a:\\t; rpmq
> -p --queryformat '%{SIZE}\n'"  
> http://git.altlinux.org/tasks/272282/build/400/$a/rpms/libglibmm-doc-2.66.1-alt1.noarch.rpm
> "; done
> i586:   40241540
> x86_64: 40244966
> aarch64:        40244902
> armh:   40244902
> ppc64le:        40244902
> 
> $ for a in i586 x86_64 aarch64 armh ppc64le; do echo -ne $a:\\t; rpmq
> -p --queryformat '%{SIZE}\n' " 
> http://git.altlinux.org/tasks/272282/build/500/$a/rpms/libglibmm2.68-devel-doc-2.68.1-alt1.noarch.rpm
> "; done
> i586:   38291881
> x86_64: 38291905
> 
> aarch64:        38291901
> armh:   38291901
> ppc64le:        38291901
> 

Выяснилось, что для сборки документации с помощью doxygen категорически
не хватает шрифтов.

Примерчик dot-файла.
$ head -5 classGlib_1_1ustring__inherit__graph.dot 
digraph "Glib::ustring"
{
 // LATEX_PDF_SIZE
  edge
[fontname="Sans",fontsize="10",labelfontname="Sans",labelfontsize="10"]
;
  node [fontname="Sans",fontsize="10",shape=record];

Если добавить в BR пакетов, которые не прошли "noarch check" fonts-ttf-
open-sans, то получим...

[#272282] TESTED (try 8) srpm=mm-common-1.0.3-alt1.src.rpm ...

лишь иллюзию благополучия, поскольку в остальных пакетах несмотря на
успешный "noarch check" картинки в документации испорчены, -- на них
нет текста.

И так, вероятно, во всей документации собранной нашим doxygen, если
только нужные шрифты, скорей всего случайно, не оказались в сборочной
среде.

-- 
Yuri N. Sedunov

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 01:22:47PM +0300, Grigory Ustinov wrote:
> 
> 31.05.2021 13:09, Andrey Cherepanov пишет:
> > 31.05.2021 12:20, Arseny Maslennikov пишет:
> > > Hi!
> > > 
> > > Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> > > Описание изменения и цели, которые оно должно было достигнуть, я
> > > поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> > > чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> > > обсудить подробности, это всё ещё можно сделать)
> > > 
> > > Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
> > > совсем тривиальным причинам, были обновлены в том же задании, но не все;
> > > далее о тех, кто остался.
> > > 
> > > Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
> > > спеках которых есть "%cmake_build VERBOSE=1":
> > > % git grep -F '%cmake_build VERBOSE=1' | wc
> > >       32      68    1508
> > > Сейчас verbose передаётся по умолчанию (можно было так не делать, но
> > > спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
> > > предпочтении мейнтейнеров — поэтому и было принято такое решение).
> > > 
> > > Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
> > > вызову make с VERBOSE=0

Вдогонку: в этом случае лучше явно передать cmake -G'Unix Makefiles' и
не зависеть от значения -G по умолчанию.

> > > или `cmake --build "%_cmake__builddir"' без
> > > опции --verbose, если вам так больше нравится. (Некоторые пакеты я успел
> > > исправить лично; к слову, там были накручены в виде makeflags либо
> > > вообще неактуальные переменные, либо ныне настраиваемые по-другому)

Другая категория спеков — те, где вызывается %cmake_build t1 t2 t3 ...
Перед списком целей надо вставить -t или --target: %cmake_build -t t1 t2 t3 ...
Ну, или вызывать явно native builder tool.
До каких-то пакетов у меня дошли руки, до некоторых — ещё нет.

> > > Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
> > > в задании 272559, совместимый и с текущими спеками в p9 на момент его
> > > составления, и с копируемыми спеками из Сизифа.
> > > Я сначала займусь этим заданием (потому что копирование спеков сейчас
> > > затруднено, уже были жалобы в личку), а после буду исправлять оставшиеся
> > > пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.

Отправил задание.

> > 
> > Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
Приношу искренние извинения за попорченные нервы, но см. ниже.
> > Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
> Или исправить сломанные пакеты.

По этому поводу.

При работе над 269879 я заметил несколько пакетов, которые собирались,
но не проходили noarch check из-за не до конца сгенерированной
документации на разных архитектурах.
Это как минимум:
:dir=/people/arseny/packages/coin3d.git
:dir=/people/arseny/packages/libopencv.git
:dir=/people/arseny/packages/soqt.git
:dir=/people/arseny/packages/libvxl.git
:dir=/people/arseny/packages/uhd.git

Понять характер проблемы можно по логам #272855 и #272860 (два разных
исправления для libvxl).

Их, как и некоторые другие пакеты, пришлось выкинуть из 269879, и сейчас
они не пересобираются.

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

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

Re: [devel] I: cmake macros

[Aleksei Nikiforov]

31.05.2021 13:45, Arseny Maslennikov пишет:>>>
>>> Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
> Приношу искренние извинения за попорченные нервы, но см. ниже.
>>> Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
>> Или исправить сломанные пакеты.
> 
> По этому поводу.
> 
> При работе над 269879 я заметил несколько пакетов, которые собирались,
> но не проходили noarch check из-за не до конца сгенерированной
> документации на разных архитектурах.
> Это как минимум:
> :dir=/people/arseny/packages/coin3d.git
> :dir=/people/arseny/packages/libopencv.git
> :dir=/people/arseny/packages/soqt.git
> :dir=/people/arseny/packages/libvxl.git
> :dir=/people/arseny/packages/uhd.git
> 
> Понять характер проблемы можно по логам #272855 и #272860 (два разных
> исправления для libvxl).
> 
> Их, как и некоторые другие пакеты, пришлось выкинуть из 269879, и сейчас
> они не пересобираются.
> 
> Для таких пакетов у меня в packages лежат сборочные теги, их надо просто
> собрать. Я займусь этим в ближайшее время.
> 
Судя по результатам тестов, документация получается разной из-за того, 
что на разных архитектурах макрос %_cmake__builddir принимает разное 
значение. Т.е. разлом сборки этих пакетов - прямое следствие данного 
обновления cmake.

Re: [devel] noarch check failing

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 04:49:58PM +0300, Aleksei Nikiforov wrote:
> 31.05.2021 13:45, Arseny Maslennikov пишет:>>>
> > > > Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
> > Приношу искренние извинения за попорченные нервы, но см. ниже.
> > > > Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
> > > Или исправить сломанные пакеты.
> > 
> > По этому поводу.
> > 
> > При работе над 269879 я заметил несколько пакетов, которые собирались,
> > но не проходили noarch check из-за не до конца сгенерированной
> > документации на разных архитектурах.
> > Это как минимум:
> > :dir=/people/arseny/packages/coin3d.git
> > :dir=/people/arseny/packages/libopencv.git
> > :dir=/people/arseny/packages/soqt.git
> > :dir=/people/arseny/packages/libvxl.git
> > :dir=/people/arseny/packages/uhd.git
> > 
> > Понять характер проблемы можно по логам #272855 и #272860 (два разных
> > исправления для libvxl).
> > 
> > Их, как и некоторые другие пакеты, пришлось выкинуть из 269879, и сейчас
> > они не пересобираются.
> > 
> > Для таких пакетов у меня в packages лежат сборочные теги, их надо просто
> > собрать. Я займусь этим в ближайшее время.
> > 
> Судя по результатам тестов, документация получается разной из-за того, что
> на разных архитектурах макрос %_cmake__builddir принимает разное значение.

Кстати, иногда собрать одинаково на разных архитектурах (ещё на
итерациях задания 269879) удавалось.

> Т.е. разлом сборки этих пакетов - прямое следствие данного обновления cmake.

Спасибо.
Что ж, вернем им одинаковое.

Кстати, когда я локально тестировал на x86_64 и в «hsh
--with-qemu=aarch64 --target=aarch64», у меня из 5 раз ни разу не
получилось разных noarch-пакетов в двух случаях.

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 04:49:58PM +0300, Aleksei Nikiforov wrote:
> 31.05.2021 13:45, Arseny Maslennikov пишет:>>>
> > > > Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
> > Приношу искренние извинения за попорченные нервы, но см. ниже.
> > > > Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
> > > Или исправить сломанные пакеты.
> > 
> > По этому поводу.
> > 
> > При работе над 269879 я заметил несколько пакетов, которые собирались,
> > но не проходили noarch check из-за не до конца сгенерированной
> > документации на разных архитектурах.
> > Это как минимум:
> > :dir=/people/arseny/packages/coin3d.git
> > :dir=/people/arseny/packages/libopencv.git
> > :dir=/people/arseny/packages/soqt.git
> > :dir=/people/arseny/packages/libvxl.git
> > :dir=/people/arseny/packages/uhd.git
> > 
> > Понять характер проблемы можно по логам #272855 и #272860 (два разных
> > исправления для libvxl).
> > 
> > Их, как и некоторые другие пакеты, пришлось выкинуть из 269879, и сейчас
> > они не пересобираются.
> > 
> > Для таких пакетов у меня в packages лежат сборочные теги, их надо просто
> > собрать. Я займусь этим в ближайшее время.
> > 
> Судя по результатам тестов, документация получается разной из-за того, что
> на разных архитектурах макрос %_cmake__builddir принимает разное значение.

Даже с одинаковым!
http://git.altlinux.org/tasks/273059/logs/events.3.1.log

% curl -fsSL http://git.altlinux.org/tasks/273059/build/200/aarch64/log |
  grep -F "Build files have been written to"
[00:00:15] -- Build files have been written to: /usr/src/RPM/BUILD/libvxl-2.0.2/BUILD
Нет зависимости от архитектуры.


> Т.е. разлом сборки этих пакетов - прямое следствие данного обновления cmake.

> _______________________________________________
> 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] I: cmake macros

[Aleksei Nikiforov]

31.05.2021 19:33, Arseny Maslennikov пишет:
> On Mon, May 31, 2021 at 04:49:58PM +0300, Aleksei Nikiforov wrote:
>> 31.05.2021 13:45, Arseny Maslennikov пишет:>>>
>>>>> Уважаемый Арсений. На ровном месте у меня сломалось десяток пакетов.
>>> Приношу искренние извинения за попорченные нервы, но см. ниже.
>>>>> Прошу вернуть BUILD как значение по умолчанию в %_cmake__builddir.
>>>> Или исправить сломанные пакеты.
>>>
>>> По этому поводу.
>>>
>>> При работе над 269879 я заметил несколько пакетов, которые собирались,
>>> но не проходили noarch check из-за не до конца сгенерированной
>>> документации на разных архитектурах.
>>> Это как минимум:
>>> :dir=/people/arseny/packages/coin3d.git
>>> :dir=/people/arseny/packages/libopencv.git
>>> :dir=/people/arseny/packages/soqt.git
>>> :dir=/people/arseny/packages/libvxl.git
>>> :dir=/people/arseny/packages/uhd.git
>>>
>>> Понять характер проблемы можно по логам #272855 и #272860 (два разных
>>> исправления для libvxl).
>>>
>>> Их, как и некоторые другие пакеты, пришлось выкинуть из 269879, и сейчас
>>> они не пересобираются.
>>>
>>> Для таких пакетов у меня в packages лежат сборочные теги, их надо просто
>>> собрать. Я займусь этим в ближайшее время.
>>>
>> Судя по результатам тестов, документация получается разной из-за того, что
>> на разных архитектурах макрос %_cmake__builddir принимает разное значение.
> 
> Даже с одинаковым!
> http://git.altlinux.org/tasks/273059/logs/events.3.1.log
> 
> % curl -fsSL http://git.altlinux.org/tasks/273059/build/200/aarch64/log |
>    grep -F "Build files have been written to"
> [00:00:15] -- Build files have been written to: /usr/src/RPM/BUILD/libvxl-2.0.2/BUILD
> Нет зависимости от архитектуры.
> 
> 
Действительно. Даже так, документация для разных архитектур отличается. 
А для libaom этого хватало. Буду смотреть.

Re: [devel] I: cmake macros

[Dmitry V. Levin]

On Mon, May 31, 2021 at 01:23:42PM +0300, Aleksey Novodvorsky wrote:
[...]
> Думаю, что не стоит  ломать стабильный бранч. Да и тестирование такого
> задания не пройдет.

Насколько я понял, в p9 это значение остаётся прежним для обратной
совместимости, а мы тут обсуждаем изменение в Сизифе.


-- 
ldv

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 01:39:45PM +0300, Dmitry V. Levin wrote:
> On Mon, May 31, 2021 at 01:23:42PM +0300, Aleksey Novodvorsky wrote:
> [...]
> > Думаю, что не стоит  ломать стабильный бранч. Да и тестирование такого
> > задания не пройдет.
> 
> Насколько я понял, в p9 это значение остаётся прежним для обратной
> совместимости, а мы тут обсуждаем изменение в Сизифе.

Да, именно так.

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

Re: [devel] I: cmake macros

[Anton Farygin]

Как то не очень красиво получилось:

В Sisyphus:

$ rpm --eval %cmake_install
DESTDIR="/home/rider/RPM/TMP/%{name}-buildroot" cmake --install 
"x86_64-alt-linux-gnu" --verbose

в p9:
$ rpm --eval %cmake_install

     make INSTALL="/bin/install -p" -C BUILD



On 31.05.2021 12:20, Arseny Maslennikov wrote:
> Hi!
>
> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> Описание изменения и цели, которые оно должно было достигнуть, я
> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> обсудить подробности, это всё ещё можно сделать)
>
> Большинство пакетов, которые не собрались бы с cmake 3.19.7-alt3 по
> совсем тривиальным причинам, были обновлены в том же задании, но не все;
> далее о тех, кто остался.
>
> Судя по github.com/altlinux/specs, в сизифе есть несколько пакетов, в
> спеках которых есть "%cmake_build VERBOSE=1":
> % git grep -F '%cmake_build VERBOSE=1' | wc
>       32      68    1508
> Сейчас verbose передаётся по умолчанию (можно было так не делать, но
> спеков с VERBOSE=1 было больше, чем без этого флага — что говорит о
> предпочтении мейнтейнеров — поэтому и было принято такое решение).
>
> Их исправление сводится либо просто к убиранию VERBOSE=1, либо к явному
> вызову make с VERBOSE=0 или `cmake --build "%_cmake__builddir"' без
> опции --verbose, если вам так больше нравится. (Некоторые пакеты я успел
> исправить лично; к слову, там были накручены в виде makeflags либо
> вообще неактуальные переменные, либо ныне настраиваемые по-другому)
>
> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
> в задании 272559, совместимый и с текущими спеками в p9 на момент его
> составления, и с копируемыми спеками из Сизифа.
> Я сначала займусь этим заданием (потому что копирование спеков сейчас
> затруднено, уже были жалобы в личку), а после буду исправлять оставшиеся
> пакеты в сизифе, до которых не дойдут руки у мейнтейнеров.
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:
> Как то не очень красиво получилось:
> 
> В Sisyphus:
> 
> $ rpm --eval %cmake_install
> DESTDIR="/home/rider/RPM/TMP/%{name}-buildroot" cmake --install
> "x86_64-alt-linux-gnu" --verbose
> 
> в p9:
> $ rpm --eval %cmake_install
> 
>      make INSTALL="/bin/install -p" -C BUILD
http://git.altlinux.org/tasks/272559/

А действительно ли надо делать _cmake__builddir отличным от "BUILD" по 
умолчанию?

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Anton Farygin]

On 31.05.2021 15:09, Sergey V Turchin wrote:
> On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:
>> Как то не очень красиво получилось:
>>
>> В Sisyphus:
>>
>> $ rpm --eval %cmake_install
>> DESTDIR="/home/rider/RPM/TMP/%{name}-buildroot" cmake --install
>> "x86_64-alt-linux-gnu" --verbose
>>
>> в p9:
>> $ rpm --eval %cmake_install
>>
>>       make INSTALL="/bin/install -p" -C BUILD
> http://git.altlinux.org/tasks/272559/
>
> А действительно ли надо делать _cmake__builddir отличным от "BUILD" по
> умолчанию?
>
Я знаю про это задание, но в этом изменении слишком кардинально меняется 
содержимое макроса, что врятли приемлемо для stable репозитория.

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

Да и с BUILD непонятно зачем сделано. Было бы интересно услышать 
комментарии по этому поводу.

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> On 31.05.2021 15:09, Sergey V Turchin wrote:
> > On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:
> > > Как то не очень красиво получилось:
> > > 
> > > В Sisyphus:
> > > 
> > > $ rpm --eval %cmake_install
> > > DESTDIR="/home/rider/RPM/TMP/%{name}-buildroot" cmake --install
> > > "x86_64-alt-linux-gnu" --verbose
> > > 
> > > в p9:
> > > $ rpm --eval %cmake_install
> > > 
> > >       make INSTALL="/bin/install -p" -C BUILD
> > http://git.altlinux.org/tasks/272559/
> > 
> > А действительно ли надо делать _cmake__builddir отличным от "BUILD" по
> > умолчанию?

В p9 — точно себе дороже.

> > 
> Я знаю про это задание, но в этом изменении слишком кардинально меняется
> содержимое макроса, что вряд ли приемлемо для stable репозитория.
> 
> Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.

В 272559 все пакеты, явно использовавшие %cmake_install в его
(бесполезном, кмк) старом значении, исправлены.
> 
> Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> по этому поводу.

Одна из преследуемых целей — спеки не должны зависеть от конкретного
значения %_cmake__builddir, которое они не выставили явно, поэтому их
исправление там, где в них явно про некоторые файлы написано BUILD/*,
всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
список всех пакетов, нарушающих этот принцип.

Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
вероятности могут уже присутствовать в
/usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
`mkdir %_cmake__builddir'. В долгосрочной перспективе нам уместно
(медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
писать автоматически.

Остаётся только одно соображение в защиту имени BUILD: при ручном
вмешательстве человека с клавиатурой в хешерницу с результатом
почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и
tab-complete) придётся набирать руками. С этой точки зрения значение по
умолчанию "build-%_target_platform" или даже "build" было бы лучше, а
"BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с
/usr/src/RPM/BUILD.

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

Так оказалось, что %_target_platform довольно удобен:
конкретно %_target_platform уже используется у нас в макросах для meson,
например; никто не жаловался на возникающие сбои. Да и при чтении лога
семейство архитектур лишний раз бросается в глаза. В самих спеках
%_target_platform явно употребляться не будет, коллизия по имени с уже
существующими файлами маловероятна.

Константным выражением, на которое можно положиться в спеке, выступает
%_cmake__builddir; многие исправленные спеки в обсуждаемом сборочном
задании явно используют этот макрос там, где cmake --install не хватает
и надо руками залезть.

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

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[...]
> > > А действительно ли надо делать _cmake__builddir отличным от "BUILD" по
> > > умолчанию?
> 
> В p9 — точно себе дороже.
Я имел ввиду вообще. Кому оно надо? Может, он сам себе определит нужный 
_cmake__builddir?

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[...]
> > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать
> > комментарии по этому поводу.
> 
> Одна из преследуемых целей — спеки не должны зависеть от конкретного
> значения %_cmake__builddir,
Это может быть только при умолчательном значении "BUILD".

> которое они не выставили явно, поэтому их
> исправление там, где в них явно про некоторые файлы написано BUILD/*,
> всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> список всех пакетов, нарушающих этот принцип.
Только проделываемое, получается, противоречит цели.


[...]


-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 04:02:16PM +0300, Sergey V Turchin wrote:
> On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:
> 
> [...]
> > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать
> > > комментарии по этому поводу.
> > 
> > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > значения %_cmake__builddir,
> Это может быть только при умолчательном значении "BUILD".

Почему же?

Пока что в этом месте у вас аргументация противоречивая: спеки могут не
зависеть от значения _cmake__builddir по умолчанию только если оно
BUILD, но если оно _должно_ быть BUILD, то они на самом деле от него зависят.

Если следует сблизить гору и Магомета, то можно пододвинуть Магомета к
горе, а можно гору к Магомету.

Или, может, в sisyphus и p9 есть спеки, которых нет в
github.com/altlinux/specs и про которые я поэтому до сей поры не знаю, и
которые вообще нельзя никак изменить?

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

Re: [devel] I: cmake macros

[Anton Farygin]

On 31.05.2021 17:22, Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 04:02:16PM +0300, Sergey V Turchin wrote:
>> On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:
>>
>> [...]
>>>> Да и с BUILD непонятно зачем сделано. Было бы интересно услышать
>>>> комментарии по этому поводу.
>>> Одна из преследуемых целей — спеки не должны зависеть от конкретного
>>> значения %_cmake__builddir,
>> Это может быть только при умолчательном значении "BUILD".
> Почему же?
>
> Пока что в этом месте у вас аргументация противоречивая: спеки могут не
> зависеть от значения _cmake__builddir по умолчанию только если оно
> BUILD, но если оно _должно_ быть BUILD, то они на самом деле от него зависят.
>
> Если следует сблизить гору и Магомета, то можно пододвинуть Магомета к
> горе, а можно гору к Магомету.
>
> Или, может, в sisyphus и p9 есть спеки, которых нет в
> github.com/altlinux/specs и про которые я поэтому до сей поры не знаю, и
> которые вообще нельзя никак изменить?

тут есть ещё такой нюанс, что я как ментейнер могу не знать, для какого 
репозитория и кто захочет собрать мой спек.

Соответственно, вот в p9 вы, допустим, почините, а есть ещё некий c9f1 и 
c9f2

В ZoneMinder я выкрутился так:

%define zm_builddir 
%{?_cmake__builddir:%_cmake__builddir}%{!?_cmake__builddir:BUILD}

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 18:00:21 MSK Anton Farygin wrote:

[...]
> В ZoneMinder я выкрутился так:
> 
> %define zm_builddir
> %{?_cmake__builddir:%_cmake__builddir}%{!?_cmake__builddir:BUILD}
Можно просто
%define _cmake__builddir BUILD


-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Anton Farygin]

On 31.05.2021 18:04, Sergey V Turchin wrote:
> On Monday, 31 May 2021 18:00:21 MSK Anton Farygin wrote:
>
> [...]
>> В ZoneMinder я выкрутился так:
>>
>> %define zm_builddir
>> %{?_cmake__builddir:%_cmake__builddir}%{!?_cmake__builddir:BUILD}
> Можно просто
> %define _cmake__builddir BUILD
>
>
Я понимаю, но я хочу всё-таки задействовать изменения Арсения, а не 
откатить их.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 18:19:50 MSK Anton Farygin wrote:
> On 31.05.2021 18:04, Sergey V Turchin wrote:
> > On Monday, 31 May 2021 18:00:21 MSK Anton Farygin wrote:
> > 
> > [...]
> > 
> >> В ZoneMinder я выкрутился так:
> >> 
> >> %define zm_builddir
> >> %{?_cmake__builddir:%_cmake__builddir}%{!?_cmake__builddir:BUILD}
> > 
> > Можно просто
> > %define _cmake__builddir BUILD
> 
> Я понимаю, но я хочу всё-таки задействовать изменения Арсения, а не
> откатить их.
А они реально ничего не делают для конкретного пакета.

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 17:22:39 MSK Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 04:02:16PM +0300, Sergey V Turchin wrote:
> > On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:
> > 
> > [...]
> > 
> > > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать
> > > > комментарии по этому поводу.
> > > 
> > > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > > значения %_cmake__builddir,
> > Это может быть только при умолчательном значении "BUILD".
> Почему же?
Потому, что вы его зачем-то меняете, хотя они не должны зависеть и от "BUILD".
 
> Пока что в этом месте у вас аргументация противоречивая: спеки могут не
> зависеть от значения _cmake__builddir по умолчанию только если оно
> BUILD, но если оно _должно_ быть BUILD, то они на самом деле от него
> зависят.
Нет. Это показывает, что цели вы добились за большее число шагов(ненужных).

> Если следует сблизить гору и Магомета, то можно пододвинуть Магомета к
> горе, а можно гору к Магомету.
А вы двигаете обоих.

> Или, может, в sisyphus и p9 есть спеки, которых нет в
> github.com/altlinux/specs и про которые я поэтому до сей поры не знаю, и
> которые вообще нельзя никак изменить?
А зачем что-то менять без необходимости? Это ж не песочница для одного 
человека.

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[....]
> Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> вероятности могут уже присутствовать в
Когда после многих прошедших(уже) лет с незаметной вероятностью появившийся 
этот единственный пакет начнет использовать BUILD, для него, единственного и 
неповторимого, ведь, уже сделана ручка ввиде _cmake__builddir, а для всех 
остальных пусть останется "BUILD".

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[...]
> Остаётся только одно соображение в защиту имени BUILD:
У меня ни одного соображения против BUILD не остаётся.

> при ручном
> вмешательстве человека с клавиатурой в хешерницу с результатом
> почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и
> tab-complete) придётся набирать руками. С этой точки зрения значение по
> умолчанию "build-%_target_platform" или даже "build" было бы лучше, а
> "BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с
> /usr/src/RPM/BUILD.
Да делал я у себя в KDE уже "BUILD-%_target_platform", который тупо оказался 
не нужен и через несколько лет я даже ответить не смог, зачем оно.

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[...]
> Вот я и остановился перед выбором из четырёх:
> %_target_platform, build-%_target_platform, build, build-%name-%EVR и
> выбрал первое. Но я на своём варианте не настаиваю, и об этом умолчании
> можно договориться и поменять в сизифе в любой момент обозримого
> будущего, не сломав ни один спек.
Все эти варианты ненужные. Оставьте просто BUILD, ведь ни одного 
действительного аргумента приведено не было.

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 15:53:25 MSK Arseny Maslennikov wrote:

[...]
> Одна из преследуемых целей 
Собрать пачку багов "сломал сборку пакета", т.к. один из сценариев:
1. Починка сборки пакета строкой
%define _cmake__builddir BUILD
2. a) Появление через некоторое времени баги "сломал сборку моего пакета, чини 
свой cmake".
   б) Ничего не происходит.

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> > On 31.05.2021 15:09, Sergey V Turchin wrote:
> > > 
> > Я знаю про это задание, но в этом изменении слишком кардинально меняется
> > содержимое макроса, что вряд ли приемлемо для stable репозитория.
> > 
> > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.
> 
> В 272559 все пакеты, явно использовавшие %cmake_install в его
> (бесполезном, кмк) старом значении, исправлены.
> > 
> > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> > по этому поводу.
> 
> Одна из преследуемых целей — спеки не должны зависеть от конкретного
> значения %_cmake__builddir, которое они не выставили явно, поэтому их
> исправление там, где в них явно про некоторые файлы написано BUILD/*,
> всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> список всех пакетов, нарушающих этот принцип.
> 
> Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> вероятности могут уже присутствовать в
> /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
> неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
> `mkdir %_cmake__builddir'.

mkdir -p решает эту проблему в 99.999% случаев (теоретически
возможно, что BUILD — это файл или используетс апстримом для иных
нужд, но на практике такое вряд ли встречается).

> В долгосрочной перспективе нам уместно
> (медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
> писать автоматически.

Viy@ давно разработал и предлагает неплохие инструменты
автоматизации, но его идеи раз за разом отвергают. Чем данная
ситуация отличаются? У нас большая часть разработчиков считает, что
писать спеки нужно вручную. И в случае со сложными, нетривиальными
пакетами они правы. Но если и CPAN и т.п., где подход viy@ куда
более практичен.

> Остаётся только одно соображение в защиту имени BUILD: при ручном
> вмешательстве человека с клавиатурой в хешерницу с результатом
> почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и
> tab-complete) придётся набирать руками. С этой точки зрения значение по
> умолчанию "build-%_target_platform" или даже "build" было бы лучше, а
> "BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с
> /usr/src/RPM/BUILD.
> 
> Вот я и остановился перед выбором из четырёх:
> %_target_platform, build-%_target_platform, build, build-%name-%EVR и
> выбрал первое. Но я на своём варианте не настаиваю, и об этом умолчании
> можно договориться и поменять в сизифе в любой момент обозримого
> будущего, не сломав ни один спек.
> 
> Так оказалось, что %_target_platform довольно удобен:
> конкретно %_target_platform уже используется у нас в макросах для meson,
> например; никто не жаловался на возникающие сбои. Да и при чтении лога
> семейство архитектур лишний раз бросается в глаза. В самих спеках
> %_target_platform явно употребляться не будет, коллизия по имени с уже
> существующими файлами маловероятна.
> 
> Константным выражением, на которое можно положиться в спеке, выступает
> %_cmake__builddir; многие исправленные спеки в обсуждаемом сборочном
> задании явно используют этот макрос там, где cmake --install не хватает
> и надо руками залезть.

По-моему, ты перемудрил: решая несуществующую проблему с именем
BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
ты создал очень даже практическую проблему лишнего уровня
абстракции и реальной поломки сотен пакетов.

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote:
> > On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> > > On 31.05.2021 15:09, Sergey V Turchin wrote:
> > > > 
> > > Я знаю про это задание, но в этом изменении слишком кардинально меняется
> > > содержимое макроса, что вряд ли приемлемо для stable репозитория.
> > > 
> > > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.
> > 
> > В 272559 все пакеты, явно использовавшие %cmake_install в его
> > (бесполезном, кмк) старом значении, исправлены.
> > > 
> > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> > > по этому поводу.
> > 
> > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > значения %_cmake__builddir, которое они не выставили явно, поэтому их
> > исправление там, где в них явно про некоторые файлы написано BUILD/*,
> > всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> > список всех пакетов, нарушающих этот принцип.
> > 
> > Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> > вероятности могут уже присутствовать в
> > /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
> > неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
> > `mkdir %_cmake__builddir'.
> 
> mkdir -p решает эту проблему в 99.999% случаев (теоретически
> возможно, что BUILD — это файл или используетс апстримом для иных
> нужд, но на практике такое вряд ли встречается).

Я встречал 2 раза, это уже больше, чем 0.001%. :)

Например, в проектах на google c++-стеке встречаются сборочные скрипты
для Bazel, точка входа в которые называется именно BUILD.

В одном пакете я даже видел ln -s build BUILD.

> 
> > В долгосрочной перспективе нам уместно
> > (медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
> > писать автоматически.
> 
> Viy@ давно разработал и предлагает неплохие инструменты
> автоматизации, но его идеи раз за разом отвергают.

У меня сложилось впечатление, что основные причины недоверия — высокий
порог входа в эти инструменты других мейнтейнеров и непонятная
выпускающим менеджерам репозитория цепочка ответственности за разломы
этого репозитория.

По тем или иным причинам их не встраивают в рекомендуемый workflow,
например, новичка в ALT Linux Team; новички о них не знают, а матёрым
мейнтейнерам надо ехать, а не автомобиль проектировать.

> Чем данная
> ситуация отличаются? У нас большая часть разработчиков считает, что
> писать спеки нужно вручную. И в случае со сложными, нетривиальными
> пакетами они правы. Но если и CPAN и т.п., где подход viy@ куда
> более практичен.
> 
> > Остаётся только одно соображение в защиту имени BUILD: при ручном
> > вмешательстве человека с клавиатурой в хешерницу с результатом
> > почему-либо упавшей сборки %_target_platform (или первые 1-2 символа и
> > tab-complete) придётся набирать руками. С этой точки зрения значение по
> > умолчанию "build-%_target_platform" или даже "build" было бы лучше, а
> > "BUILD" — хуже этих двух, потому что shift надо нажимать и коллизия с
> > /usr/src/RPM/BUILD.
> > 
> > Вот я и остановился перед выбором из четырёх:
> > %_target_platform, build-%_target_platform, build, build-%name-%EVR и
> > выбрал первое. Но я на своём варианте не настаиваю, и об этом умолчании
> > можно договориться и поменять в сизифе в любой момент обозримого
> > будущего, не сломав ни один спек.
> > 
> > Так оказалось, что %_target_platform довольно удобен:
> > конкретно %_target_platform уже используется у нас в макросах для meson,
> > например; никто не жаловался на возникающие сбои. Да и при чтении лога
> > семейство архитектур лишний раз бросается в глаза. В самих спеках
> > %_target_platform явно употребляться не будет, коллизия по имени с уже
> > существующими файлами маловероятна.
> > 
> > Константным выражением, на которое можно положиться в спеке, выступает
> > %_cmake__builddir; многие исправленные спеки в обсуждаемом сборочном
> > задании явно используют этот макрос там, где cmake --install не хватает
> > и надо руками залезть.
> 
> По-моему, ты перемудрил: решая несуществующую проблему с именем
> BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> ты создал очень даже практическую проблему лишнего уровня
> абстракции и реальной поломки сотен пакетов.

Откуда же там сотни?
specs% git grep '%cmake_build [A-Z_a-z]' | wc  
     45      96    2162
Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 04:52:20PM +0300, Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > ты создал очень даже практическую проблему лишнего уровня
> > абстракции и реальной поломки сотен пакетов.
> 
> Откуда же там сотни?
> specs% git grep '%cmake_build [A-Z_a-z]' | wc  
>      45      96    2162
Так некоторые спеки подсчитаны более чем единожды.
 % git grep -l '%cmake_build [A-Z_a-z]' | wc
     33      33     802
> Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.


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

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote:
> > > On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> > > > On 31.05.2021 15:09, Sergey V Turchin wrote:
> > > > > 
> > > > Я знаю про это задание, но в этом изменении слишком кардинально меняется
> > > > содержимое макроса, что вряд ли приемлемо для stable репозитория.
> > > > 
> > > > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.
> > > 
> > > В 272559 все пакеты, явно использовавшие %cmake_install в его
> > > (бесполезном, кмк) старом значении, исправлены.
> > > > 
> > > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> > > > по этому поводу.
> > > 
> > > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > > значения %_cmake__builddir, которое они не выставили явно, поэтому их
> > > исправление там, где в них явно про некоторые файлы написано BUILD/*,
> > > всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> > > список всех пакетов, нарушающих этот принцип.
> > > 
> > > Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> > > вероятности могут уже присутствовать в
> > > /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
> > > неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
> > > `mkdir %_cmake__builddir'.
> > 
> > mkdir -p решает эту проблему в 99.999% случаев (теоретически
> > возможно, что BUILD — это файл или используетс апстримом для иных
> > нужд, но на практике такое вряд ли встречается).
> 
> Я встречал 2 раза, это уже больше, чем 0.001%. :)

И 2 пакета, это повод ломать более сотни? По-моему, проще и
правильнее решить проблему в этой паре пакетов и для остальных
оставить как есть.
 
> Например, в проектах на google c++-стеке встречаются сборочные скрипты
> для Bazel, точка входа в которые называется именно BUILD.
> 
> В одном пакете я даже видел ln -s build BUILD.
[...] 
> > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > ты создал очень даже практическую проблему лишнего уровня
> > абстракции и реальной поломки сотен пакетов.
> 
> Откуда же там сотни?
> specs% git grep '%cmake_build [A-Z_a-z]' | wc  
>      45      96    2162
> Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.

Откуда циферки?

$ git grep %cmake_build | wc -l
446

Потенциально сломаны они все.

Best regards,
Andrew Savchenko

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

Re: [devel] циферки (was: I: cmake macros)

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 05:39:54PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> > On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > > On Mon, 31 May 2021 15:53:25 +0300 Arseny Maslennikov wrote:
> > > > On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
> > > > > On 31.05.2021 15:09, Sergey V Turchin wrote:
> > > > > > 
> > > > > Я знаю про это задание, но в этом изменении слишком кардинально меняется
> > > > > содержимое макроса, что вряд ли приемлемо для stable репозитория.
> > > > > 
> > > > > Т.е. - условно говоря если раньше макрос ничего не делал, то теперь делает.
> > > > 
> > > > В 272559 все пакеты, явно использовавшие %cmake_install в его
> > > > (бесполезном, кмк) старом значении, исправлены.
> > > > > 
> > > > > Да и с BUILD непонятно зачем сделано. Было бы интересно услышать комментарии
> > > > > по этому поводу.
> > > > 
> > > > Одна из преследуемых целей — спеки не должны зависеть от конкретного
> > > > значения %_cmake__builddir, которое они не выставили явно, поэтому их
> > > > исправление там, где в них явно про некоторые файлы написано BUILD/*,
> > > > всё равно планировалось. Изменив BUILD на что-то ещё, легко узнать
> > > > список всех пакетов, нарушающих этот принцип.
> > > > 
> > > > Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
> > > > вероятности могут уже присутствовать в
> > > > /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
> > > > неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
> > > > `mkdir %_cmake__builddir'.
> > > 
> > > mkdir -p решает эту проблему в 99.999% случаев (теоретически
> > > возможно, что BUILD — это файл или используетс апстримом для иных
> > > нужд, но на практике такое вряд ли встречается).
> > 
> > Я встречал 2 раза, это уже больше, чем 0.001%. :)
> 
> И 2 пакета, это повод ломать более сотни? По-моему, проще и
> правильнее решить проблему в этой паре пакетов и для остальных
> оставить как есть.
>  
> > Например, в проектах на google c++-стеке встречаются сборочные скрипты
> > для Bazel, точка входа в которые называется именно BUILD.
> > 
> > В одном пакете я даже видел ln -s build BUILD.
> [...] 
> > > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > > ты создал очень даже практическую проблему лишнего уровня
> > > абстракции и реальной поломки сотен пакетов.
> > 
> > Откуда же там сотни?
> > specs% git grep '%cmake_build [A-Z_a-z]' | wc  
> >      45      96    2162
> > Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.
> 
> Откуда циферки?

По странице на альтвики:

%cmake_build VERBOSE=1 сломалось, и вообще любая передача make-флагов
сломалась. Правда, передача произвольных make-флагов была нужна только
в очень малом числе пакетов, которые все были исправлены вчера же. Как
выяснилось, эти make-флаги были не нужны либо ни одному из них, либо
только одному (имя пакета не помню, там передавали RUBY="ruby
-rvendor-specific", но, судя по всему, эту переменную окружения никто не
читал; я передал её на всякий случай как переменную окружения).
Видимо, апстримы переезжали на CMake в какой-то момент, и makeflags были
нужны до переезда.

%cmake_build t1 t2 t3 сломалось, потому что cmake --build принимает
имена целей после -t/--target.

Выражение выше вполне отражает эти два случая.

> 
> $ git grep %cmake_build | wc -l
> 446
> 
> Потенциально сломаны они все.

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

> 
> Best regards,
> Andrew Savchenko



> _______________________________________________
> 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] циферки (was: I: cmake macros)

[Andrey Savchenko]

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

On Mon, 31 May 2021 17:52:30 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 05:39:54PM +0300, Andrey Savchenko wrote:
> > On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> > > On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > > > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > > > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > > > ты создал очень даже практическую проблему лишнего уровня
> > > > абстракции и реальной поломки сотен пакетов.
> > > 
> > > Откуда же там сотни?
> > > specs% git grep '%cmake_build [A-Z_a-z]' | wc  
> > >      45      96    2162
> > > Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.
> > 
> > Откуда циферки?
> 
> По странице на альтвики:
> 
> %cmake_build VERBOSE=1 сломалось, и вообще любая передача make-флагов
> сломалась. Правда, передача произвольных make-флагов была нужна только
> в очень малом числе пакетов, которые все были исправлены вчера же.

Ну вот в трёх моих пакетах был задан VERBOSE=1 и они остаются
поломанными. Так что информация «все были исправлены вчера же» не
соответствует действительности.

> Как
> выяснилось, эти make-флаги были не нужны либо ни одному из них, либо
> только одному (имя пакета не помню, там передавали RUBY="ruby
> -rvendor-specific", но, судя по всему, эту переменную окружения никто не
> читал; я передал её на всякий случай как переменную окружения).
> Видимо, апстримы переезжали на CMake в какой-то момент, и makeflags были
> нужны до переезда.
> 
> %cmake_build t1 t2 t3 сломалось, потому что cmake --build принимает
> имена целей после -t/--target.
> 
> Выражение выше вполне отражает эти два случая.

По-моему, камень преткновения в уходе от BUILD. К остальному особых
вопросов нет.

Best regards,
Andrew Savchenko

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

Re: [devel] циферки (was: I: cmake macros)

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 05:57:28PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 17:52:30 +0300 Arseny Maslennikov wrote:
> > On Mon, May 31, 2021 at 05:39:54PM +0300, Andrey Savchenko wrote:
> > > On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> > > > On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > > > > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > > > > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > > > > ты создал очень даже практическую проблему лишнего уровня
> > > > > абстракции и реальной поломки сотен пакетов.
> > > > 
> > > > Откуда же там сотни?
> > > > specs% git grep '%cmake_build [A-Z_a-z]' | wc  
> > > >      45      96    2162
> > > > Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.
> > > 
> > > Откуда циферки?
> > 
> > По странице на альтвики:
> > 
> > %cmake_build VERBOSE=1 сломалось, и вообще любая передача make-флагов
> > сломалась. Правда, передача произвольных make-флагов была нужна только
> > в очень малом числе пакетов, которые все были исправлены вчера же.
> 
> Ну вот в трёх моих пакетах был задан VERBOSE=1 и они остаются
> поломанными. Так что информация «все были исправлены вчера же» не
> соответствует действительности.

VERBOSE=1 — это не произвольный make-флаг, а деталь реализации cmake.

> 
> > Как
> > выяснилось, эти make-флаги были не нужны либо ни одному из них, либо
> > только одному (имя пакета не помню, там передавали RUBY="ruby
> > -rvendor-specific", но, судя по всему, эту переменную окружения никто не
> > читал; я передал её на всякий случай как переменную окружения).
> > Видимо, апстримы переезжали на CMake в какой-то момент, и makeflags были
> > нужны до переезда.
> > 
> > %cmake_build t1 t2 t3 сломалось, потому что cmake --build принимает
> > имена целей после -t/--target.
> > 
> > Выражение выше вполне отражает эти два случая.
> 
> По-моему, камень преткновения в уходе от BUILD. К остальному особых
> вопросов нет.

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

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

Re: [devel] циферки (was: I: cmake macros)

[Andrey Savchenko]

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

On Mon, 31 May 2021 18:10:05 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 05:57:28PM +0300, Andrey Savchenko wrote:
> > On Mon, 31 May 2021 17:52:30 +0300 Arseny Maslennikov wrote:
> > > On Mon, May 31, 2021 at 05:39:54PM +0300, Andrey Savchenko wrote:
> > > > On Mon, 31 May 2021 16:52:20 +0300 Arseny Maslennikov wrote:
> > > > > On Mon, May 31, 2021 at 04:28:31PM +0300, Andrey Savchenko wrote:
> > > > > > По-моему, ты перемудрил: решая несуществующую проблему с именем
> > > > > > BUILD по-умолчанию и теоретически (и только!) возможной коллизии,
> > > > > > ты создал очень даже практическую проблему лишнего уровня
> > > > > > абстракции и реальной поломки сотен пакетов.
> > > > > 
> > > > > Откуда же там сотни?
> > > > > specs% git grep '%cmake_build [A-Z_a-z]' | wc  
> > > > >      45      96    2162
> > > > > Случаи, не входящие сюда, могут быть рассмотрены в единичном порядке.
> > > > 
> > > > Откуда циферки?
> > > 
> > > По странице на альтвики:
> > > 
> > > %cmake_build VERBOSE=1 сломалось, и вообще любая передача make-флагов
> > > сломалась. Правда, передача произвольных make-флагов была нужна только
> > > в очень малом числе пакетов, которые все были исправлены вчера же.
> > 
> > Ну вот в трёх моих пакетах был задан VERBOSE=1 и они остаются
> > поломанными. Так что информация «все были исправлены вчера же» не
> > соответствует действительности.
> 
> VERBOSE=1 — это не произвольный make-флаг, а деталь реализации cmake.

Это частный случай произвольного флага.

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 08:48:41PM +0300, Скрылевъ Малъ wrote:
> <div> </div><div> </div><div>31.05.2021, 15:53, "Arseny Maslennikov" &lt;arseny@altlinux.org&gt;:</div><blockquote><p>On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:</p><blockquote> On 31.05.2021 15:09, Sergey V Turchin wrote:<br /> &gt; On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:<br /> &gt; &gt; Как то не очень красиво получилось:<br /> </blockquote><p><br />Файловые объекты с "простым" именем BUILD, build, ... с заметной долей<br />вероятности могут уже присутствовать в<br />/usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний<br />неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на<br />`mkdir %_cmake__builddir'. В долгосрочной перспективе нам уместно<br />(медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%<br />писать автоматически.</p></blockquote><div>А почему нельзя было определять на лету, есть ли предопределённый BUILD и при наличии оного перенастраивать целевую сборочную папку?</div><div>Я скажем видел такой файл кое-где потому приходилось обходить костылями...</div><div>Но зато решение более менее гибким бы было.</div><div>-- </div><div>С уважением,<br />Скрылевъ Малъ</div><div>+79055245451</div><div> </div>

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

On Mon, May 31, 2021 at 08:48:41PM +0300, Скрылевъ Малъ wrote:
> А почему нельзя было определять на лету, есть ли предопределённый BUILD и при наличии оного перенастраивать целевую сборочную папку?
> Я скажем видел такой файл кое-где потому приходилось обходить костылями...
> Но зато решение более менее гибким бы было.

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

Если перенастраивать, то на что именно? Если на те же %_target_platform
или build-%name-%EVR, то почему бы сразу так не назвать?

> _______________________________________________
> 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] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 21:07:04 MSK Arseny Maslennikov wrote:

[...]
> > А почему нельзя было определять на лету, есть ли предопределённый BUILD и
> > при наличии оного перенастраивать целевую сборочную папку? Я скажем видел
> > такой файл кое-где потому приходилось обходить костылями... Но зато
> > решение более менее гибким бы было.
> 
> Подозреваю, такой вариант коллегам бы ещё меньше понравился тем, что
> искать сборочный каталог вручную сложнее.
> 
> Если перенастраивать, то на что именно?
На "BUILD-%_target_platform", если "BUILD" уже присутствует.

> Если на те же %_target_platform
> или build-%name-%EVR, то почему бы сразу так не назвать?
Чтоб мненьше сломать.

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Mikhail Novosyolov]

31.05.2021 20:48, Скрылевъ Малъ пишет:
>  
>  
> 31.05.2021, 15:53, "Arseny Maslennikov" <arseny@altlinux.org>:
>
>     On Mon, May 31, 2021 at 03:13:54PM +0300, Anton Farygin wrote:
>
>          On 31.05.2021 15:09, Sergey V Turchin wrote:
>          > On Monday, 31 May 2021 15:02:55 MSK Anton Farygin wrote:
>          > > Как то не очень красиво получилось:
>          
>
>
>     Файловые объекты с "простым" именем BUILD, build, ... с заметной долей
>     вероятности могут уже присутствовать в
>     /usr/src/RPM/BUILD/$tarball_root, что вносит в подготовку спека лишний
>     неавтоматизируемый шаг по корректной/удобной починке ошибки EEXIST на
>     `mkdir %_cmake__builddir'. В долгосрочной перспективе нам уместно
>     (медленно, но верно) стремиться к тому, чтобы спеки можно было на ~~90%
>     писать автоматически.
>
> А почему нельзя было определять на лету, есть ли предопределённый BUILD и при наличии оного перенастраивать целевую сборочную папку?
>
RPM запускает скрипт %build и скрипт %install отдельно. Между ними это имя должно быть согласовано. На эатпе раскрытия макросов доступа к содержимому исходников нет. Обойти можно, делая в %build некий файл внутри исходников, куда записывать принятое автоугадайкой решение, а затем его читать в %install, но выглдяит как переусложнение. Можно же просто в таких уникальных случаях переназначить макрос с именем сборочной директории.

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 12:20:20 +0300 Arseny Maslennikov wrote:
> Hi!
> 
> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> Описание изменения и цели, которые оно должно было достигнуть, я
> поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> обсудить подробности, это всё ещё можно сделать)

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

Предлагаю откатить все проделанные по cmake изменения, тщательно
обсудить все за и против и лишь после этого реализовывать
согласованные сообществом изменения.

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 12:20:20 +0300 Arseny Maslennikov wrote:
> > Hi!
> > 
> > Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> > Описание изменения и цели, которые оно должно было достигнуть, я
> > поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> > чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> > обсудить подробности, это всё ещё можно сделать)
> 
> На мой взгляд правильным было бы сперва обсудить предложенный
> подход, а лишь затем отправлять его в Сизиф. А так всё разломано
> и мейнтенеры ставятся перед свершившимся фактом.

С одной стороны, это честно.
С другой же, _анонс_ _предлагаемых_, а не проводимых изменений в devel@
— это сообщение одновременно для всех и ни для кого, на которое
большинство участников не обратит внимания ("развели тут разговоров на
130 писем, лучше бы что-то полезное сделали"), а остальные в лучшем
случае не смогут договориться, а в худшем — устроят филиал секции
комментариев лора/опеннета (прецеденты были).

Я пошёл на смешанный вариант: обсудить с участниками alt team, кто
попался под руку, по мере работы над заданием обсудить с теми, кому
одобрять задание по EPERM, а с широкой публикой — в финальной стадии в
devel@, которая сейчас и происходит.

> 
> Предлагаю откатить все проделанные по cmake изменения, тщательно
> обсудить все за и против и лишь после этого реализовывать
> согласованные сообществом изменения.

У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
так, мы ещё полгода будем этот вопрос выяснять — это при том, что
сизиф-то движется.

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

Re: [devel] I: cmake macros

[Anton Farygin]

On 31.05.2021 18:29, Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
>
>> Предлагаю откатить все проделанные по cmake изменения, тщательно
>> обсудить все за и против и лишь после этого реализовывать
>> согласованные сообществом изменения.
> У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
> так, мы ещё полгода будем этот вопрос выяснять — это при том, что
> сизиф-то движется.

Вообще процедура есть.

https://www.altlinux.org/Policy_Policy

Re: [devel] I: cmake macros

[Grigory Ustinov]

31.05.2021 18:38, Anton Farygin пишет:
> On 31.05.2021 18:29, Arseny Maslennikov wrote:
>> On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
>>
>>> Предлагаю откатить все проделанные по cmake изменения, тщательно
>>> обсудить все за и против и лишь после этого реализовывать
>>> согласованные сообществом изменения.
>> У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
>> так, мы ещё полгода будем этот вопрос выяснять — это при том, что
>> сизиф-то движется.
>
> Вообще процедура есть.
>
> https://www.altlinux.org/Policy_Policy
Оффтоп-вопрос: а не подскажете, какой последний вопрос был решён 
согласно такому полиси?
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 18:43:55 +0300 Grigory Ustinov wrote:
> 
> 31.05.2021 18:38, Anton Farygin пишет:
> > On 31.05.2021 18:29, Arseny Maslennikov wrote:
> >> On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
> >>
> >>> Предлагаю откатить все проделанные по cmake изменения, тщательно
> >>> обсудить все за и против и лишь после этого реализовывать
> >>> согласованные сообществом изменения.
> >> У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
> >> так, мы ещё полгода будем этот вопрос выяснять — это при том, что
> >> сизиф-то движется.
> >
> > Вообще процедура есть.
> >
> > https://www.altlinux.org/Policy_Policy
> Оффтоп-вопрос: а не подскажете, какой последний вопрос был решён 
> согласно такому полиси?

«Ответственный за проведение политики в жизнь — куда-то смылся.»
https://www.altlinux.org/Policy_Policy

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 18:29:48 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
> > On Mon, 31 May 2021 12:20:20 +0300 Arseny Maslennikov wrote:
> > > Hi!
> > > 
> > > Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> > > Описание изменения и цели, которые оно должно было достигнуть, я
> > > поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> > > чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> > > обсудить подробности, это всё ещё можно сделать)
> > 
> > На мой взгляд правильным было бы сперва обсудить предложенный
> > подход, а лишь затем отправлять его в Сизиф. А так всё разломано
> > и мейнтенеры ставятся перед свершившимся фактом.
> 
> С одной стороны, это честно.
> С другой же, _анонс_ _предлагаемых_, а не проводимых изменений в devel@
> — это сообщение одновременно для всех и ни для кого, на которое
> большинство участников не обратит внимания ("развели тут разговоров на
> 130 писем, лучше бы что-то полезное сделали"), а остальные в лучшем
> случае не смогут договориться, а в худшем — устроят филиал секции
> комментариев лора/опеннета (прецеденты были).
> 
> Я пошёл на смешанный вариант: обсудить с участниками alt team, кто
> попался под руку, по мере работы над заданием обсудить с теми, кому
> одобрять задание по EPERM, а с широкой публикой — в финальной стадии в
> devel@, которая сейчас и происходит.

Для меня, как для попавшего в «широкую публику», это выглядит как
фирменное издевательство: «я решил сделать вот так вот, теперь
живите с этим».

С одной стороны, меня как мейнтенера Сизифа это не особо
затронуло, т.к. у меня пакетов мало. С другой стороны, на
эльбрусовой сборочнице рабочий процесс уже нарушен из-за этой
проблемы: получился split brain по cmake/graphviz и пока не будет
наведён порядок в Сизифе, нет возможности полноценно продолжать
разработку на e2k.

> > Предлагаю откатить все проделанные по cmake изменения, тщательно
> > обсудить все за и против и лишь после этого реализовывать
> > согласованные сообществом изменения.
> 
> У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
> так, мы ещё полгода будем этот вопрос выяснять — это при том, что
> сизиф-то движется.

Давайте разработаем такую процедуру. Можно хоть condorset voting
сделать, можно всех уравнять, можно чьим-то голосам больший вес
дать. Я бы предпочёл первый вариант.

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Mon, May 31, 2021 at 06:51:04PM +0300, Andrey Savchenko wrote:
> On Mon, 31 May 2021 18:29:48 +0300 Arseny Maslennikov wrote:
> > On Mon, May 31, 2021 at 06:01:53PM +0300, Andrey Savchenko wrote:
> > > On Mon, 31 May 2021 12:20:20 +0300 Arseny Maslennikov wrote:
> > > > Hi!
> > > > 
> > > > Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> > > > Описание изменения и цели, которые оно должно было достигнуть, я
> > > > поместил на страничку https://www.altlinux.org/CMakeMigration2021,
> > > > чтобы не разводить тут простыню. (Если кому-то интересно конструктивно
> > > > обсудить подробности, это всё ещё можно сделать)
> > > 
> > > На мой взгляд правильным было бы сперва обсудить предложенный
> > > подход, а лишь затем отправлять его в Сизиф. А так всё разломано
> > > и мейнтенеры ставятся перед свершившимся фактом.
> > 
> > С одной стороны, это честно.
> > С другой же, _анонс_ _предлагаемых_, а не проводимых изменений в devel@
> > — это сообщение одновременно для всех и ни для кого, на которое
> > большинство участников не обратит внимания ("развели тут разговоров на
> > 130 писем, лучше бы что-то полезное сделали"), а остальные в лучшем
> > случае не смогут договориться, а в худшем — устроят филиал секции
> > комментариев лора/опеннета (прецеденты были).
> > 
> > Я пошёл на смешанный вариант: обсудить с участниками alt team, кто
> > попался под руку, по мере работы над заданием обсудить с теми, кому
> > одобрять задание по EPERM, а с широкой публикой — в финальной стадии в
> > devel@, которая сейчас и происходит.
> 
> Для меня, как для попавшего в «широкую публику», это выглядит как
> фирменное издевательство: «я решил сделать вот так вот, теперь
> живите с этим».

Андрей, я точно помню, что с твоим участием обсуждали, засовывать ли
--verbose в %cmake_build/%cmake_install по умолчанию или нет.
Ты тогда вообще предлагал выдвинуть policy по обязательному включению
полного лога во всех спеках.

При тебе же обсуждали остальное, но, может, ты внимания не обращал; это
не страшно.

> 
> С одной стороны, меня как мейнтенера Сизифа это не особо
> затронуло, т.к. у меня пакетов мало. С другой стороны, на
> эльбрусовой сборочнице рабочий процесс уже нарушен из-за этой
> проблемы: получился split brain по cmake/graphviz и пока не будет
> наведён порядок в Сизифе, нет возможности полноценно продолжать
> разработку на e2k.
> 
> > > Предлагаю откатить все проделанные по cmake изменения, тщательно
> > > обсудить все за и против и лишь после этого реализовывать
> > > согласованные сообществом изменения.
> > 
> > У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
> > так, мы ещё полгода будем этот вопрос выяснять — это при том, что
> > сизиф-то движется.
> 
> Давайте разработаем такую процедуру. Можно хоть condorset voting
> сделать, можно всех уравнять, можно чьим-то голосам больший вес
> дать. Я бы предпочёл первый вариант.

Да, надо бы об этом подумать.
Можно, кстати, комбинировать некоторые или все эти варианты.

Ещё одна проблема — обеспечение явки.

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

Re: [devel] I: cmake macros

[Andrey Savchenko]

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

On Mon, 31 May 2021 19:15:39 +0300 Arseny Maslennikov wrote:
> On Mon, May 31, 2021 at 06:51:04PM +0300, Andrey Savchenko wrote:
> > On Mon, 31 May 2021 18:29:48 +0300 Arseny Maslennikov wrote:
> > > Я пошёл на смешанный вариант: обсудить с участниками alt team, кто
> > > попался под руку, по мере работы над заданием обсудить с теми, кому
> > > одобрять задание по EPERM, а с широкой публикой — в финальной стадии в
> > > devel@, которая сейчас и происходит.
> > 
> > Для меня, как для попавшего в «широкую публику», это выглядит как
> > фирменное издевательство: «я решил сделать вот так вот, теперь
> > живите с этим».
> 
> Андрей, я точно помню, что с твоим участием обсуждали, засовывать ли
> --verbose в %cmake_build/%cmake_install по умолчанию или нет.
> Ты тогда вообще предлагал выдвинуть policy по обязательному включению
> полного лога во всех спеках.

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

> При тебе же обсуждали остальное, но, может, ты внимания не обращал; это
> не страшно.

Вообще, то место я рассматриваю исключительно как средство болтовни
на околорабочие темы, либо как средство сделать ping нужному
человеку. Рассматривать закрытый чатик, куда в принципе часть
членов team не смогут попасть, как средство принятия политики
я считаю неверным. Обсудить идеи, предложения и способы реализации
— пожалуйста, но не принимать решения, касающиеся всего team.

> > > > Предлагаю откатить все проделанные по cmake изменения, тщательно
> > > > обсудить все за и против и лишь после этого реализовывать
> > > > согласованные сообществом изменения.
> > > 
> > > У нас нет процедуры выработки решения сообщества. Поэтому, если сделать
> > > так, мы ещё полгода будем этот вопрос выяснять — это при том, что
> > > сизиф-то движется.
> > 
> > Давайте разработаем такую процедуру. Можно хоть condorset voting
> > сделать, можно всех уравнять, можно чьим-то голосам больший вес
> > дать. Я бы предпочёл первый вариант.
> 
> Да, надо бы об этом подумать.
> Можно, кстати, комбинировать некоторые или все эти варианты.

Как выяснилось, у нас уже есть policy policy, поэтому следует её
лишь задействовать.

> Ещё одна проблема — обеспечение явки.

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

Best regards,
Andrew Savchenko

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

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 20:11:09 MSK Andrey Savchenko wrote:

[...]
> Рассматривать закрытый чатик, куда в принципе часть
> членов team не смогут попасть, как средство принятия политики
> я считаю неверным. Обсудить идеи, предложения и способы реализации
> — пожалуйста, но не принимать решения, касающиеся всего team.
На самом деле там были решены более кардинальные проблемы до попадания в 
репозиторий. :-)

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey V Turchin]

On Monday, 31 May 2021 12:20:20 MSK Arseny Maslennikov wrote:
> Hi!
> 
> Вчера прошло задание 269879 с cmake 3.19.7-alt3.
> Описание изменения и цели, которые оно должно было достигнуть,
Пока оно только всё разломало.
Просьба внести такие изменения, чтобы в совместимость с p9 не была сломана 
сейчас.
Т.е. в Sisyphus необходимые изменения внесите сразу _после_ попадания соотв. 
задания в p9.

[...]

-- 
Regards, Sergey.

Re: [devel] I: cmake macros

[Sergey Afonin]

On Monday 31 May 2021, Arseny Maslennikov wrote:

> Что же касается p9, туда сегодня будет отправлен вариант макросов cmake
> в задании 272559, совместимый и с текущими спеками в p9 на момент его
> составления, и с копируемыми спеками из Сизифа.

А не стоит ли тому, что не копируется из Сизифа, добавлять M90P, как во
времена p6/p7/p8?

-- 
С уважением, Сергей Афонин.

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Tue, Jun 15, 2021 at 08:26:29PM +0300, Mikhail Novosyolov wrote:
> 
> А в чем цель отказа от Unix Makefiles и перехода на cmake --build?

cmake сама не собирает и не инсталлирует артефакты, а генерирует файлы для
некоторого исполнителя сборочных правил (бекенда, см.
cmake-generators(7)). Команда «cmake --build $builddir» не зависит от
используемого бекенда, поэтому её можно использовать с любыми бекендами.

Никакого «отказа от Unix Makefiles» я не предлагаю, несмотря на
тот факт, что make(1) на роль исполнителя генератных сборочных правил
годится так себе по ряду причин[*]. Но, если пакет по той или иной
причине зависит от некоторого конкретного генератора правил, лучше его
явно в спеке передать с -G.

> В таблице по ссылке на вики приведено " %makeinstall_std -C BUILD" в качестве рекомендуемого макроса.Вы хотите отказаться отпривязки к BUILD и тут же предлагаете прямо в спек ее прописывать?

В таблице в левом столбце описаны разные выражения в старых макросах,
которые встречаются (или встречались) в спеках, и аналогичные выражения
в новых. Она предназначена для случая, если кому-то неохота или некогда
прочесть файл с макросами[1], но хочется понять, что изменилось.

> Рассматривался ли вариант cmake --install?

Сейчас %cmake_install именно в эту команду и раскрывается и
рекомендуется для типичных случаев. Предыдущий %cmake_install был просто
бесполезен.

> В общем , прочитав тред, не понял, зачем эти изменения. В audacity.spec [1] сейчас так:
> 
> %cmake \
>   -Daudacity_lib_preference:STRING=system \
>   -Daudacity_use_ffmpeg:STRING=linked \
>   -Daudacity_use_lame:STRING=system \
>   -Daudacity_use_libflac:STRING=system \
>   -Daudacity_use_libid3tag:STRING=system \
>   -Daudacity_use_libsndfile:STRING=system \
>   -Daudacity_use_libsoxr:STRING=system \
>   -Daudacity_use_libtwolame:STRING=system \
>   -Daudacity_use_libvamp:STRING=system \
>   -Daudacity_use_libvorbis:STRING=system \
>   -Daudacity_use_libv2:STRING=system \
>   -Daudacity_use_sbsms:STRING=system \
>   -Daudacity_use_soundtouch:STRING=system \
>   -Daudacity_use_portaudio:STRING=local \
>   -Daudacity_use_midi:STRING=local \
>   -DAUDACITY_SUFFIX:STRING=""
> 
> %cmake_build
> 
> %install
> %cmakeinstall_std
> 
> Нужно ли здесь что-то менять?

Разве что %cmakeinstall_std на %cmake_install.

В целом, здесь достаточно тривиальный случай, поэтому и адаптировать
ничего не пришлось.

Изначально я задумывался о том, чтобы убрать %cmakeinstall_std вообще,
но очень много спеков сизифа его используют, а часть из них не сломались
после task 269879, как audacity. Поэтому (только после того, как в p9
пройдёт задание 272559) планируется снабдить его %warning-ом и
пояснительной надписью и потихоньку вытеснять.

[1] http://git.altlinux.org/people/arseny/packages/cmake.git?p=cmake.git;a=blob;f=.gear/cmake.macros;h=e9bc3f055dc25457d2072748e5b7dc5e5b7db812;hb=33e1f9d741a2439266bb2e72c5a763b58ae112f4
[*] JT: Вообще, если адаптировать Unix Haters' handbook к современности,
то make(1) будет главным уродом в программе цирка.

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

Re: [devel] I: cmake macros

[Mikhail Novosyolov]

15.06.2021 21:26, Arseny Maslennikov пишет:
> On Tue, Jun 15, 2021 at 08:26:29PM +0300, Mikhail Novosyolov wrote:
>> А в чем цель отказа от Unix Makefiles и перехода на cmake --build?
> cmake сама не собирает и не инсталлирует артефакты, а генерирует файлы для
> некоторого исполнителя сборочных правил (бекенда, см.
> cmake-generators(7)). Команда «cmake --build $builddir» не зависит от
> используемого бекенда, поэтому её можно использовать с любыми бекендами.
>
> Никакого «отказа от Unix Makefiles» я не предлагаю, несмотря на
> тот факт, что make(1) на роль исполнителя генератных сборочных правил
> годится так себе по ряду причин[*]. Но, если пакет по той или иной
> причине зависит от некоторого конкретного генератора правил, лучше его
> явно в спеке передать с -G.

Здесь более интересен вопрос - а чем Unix Makefiles плохи в масштабах дистрибутива. Я как-то задавался таким вопросом, глубоко тему не изучал, но сходу ничего толкового не придумал. Makefile-ы понятны, предсказуемы, их можно грязно похакать при необходимости, чего не скажешь о cmake в целом. Случаев, когда они бы не справлялись со сборкой пакета, не встречал.

Подозреваю, что большое разнообразие вариантов запуска cmake в спеках Альта следствие не того, что стандартные макросы плохи и не подходят для конкретного случая, а следствие слабости их документирования, трудности поиска примеров, желания изобрести велосипед. Или я не прав?

>
>> В таблице по ссылке на вики приведено " %makeinstall_std -C BUILD" в качестве рекомендуемого макроса.Вы хотите отказаться отпривязки к BUILD и тут же предлагаете прямо в спек ее прописывать?
> В таблице в левом столбце описаны разные выражения в старых макросах,
> которые встречаются (или встречались) в спеках, и аналогичные выражения
> в новых. Она предназначена для случая, если кому-то неохота или некогда
> прочесть файл с макросами[1], но хочется понять, что изменилось.
>
>> Рассматривался ли вариант cmake --install?
> Сейчас %cmake_install именно в эту команду и раскрывается и
> рекомендуется для типичных случаев. Предыдущий %cmake_install был просто
> бесполезен.
>
>> В общем , прочитав тред, не понял, зачем эти изменения. В audacity.spec [1] сейчас так:
>>
>> %cmake \
>>   -Daudacity_lib_preference:STRING=system \
>>   -Daudacity_use_ffmpeg:STRING=linked \
>>   -Daudacity_use_lame:STRING=system \
>>   -Daudacity_use_libflac:STRING=system \
>>   -Daudacity_use_libid3tag:STRING=system \
>>   -Daudacity_use_libsndfile:STRING=system \
>>   -Daudacity_use_libsoxr:STRING=system \
>>   -Daudacity_use_libtwolame:STRING=system \
>>   -Daudacity_use_libvamp:STRING=system \
>>   -Daudacity_use_libvorbis:STRING=system \
>>   -Daudacity_use_libv2:STRING=system \
>>   -Daudacity_use_sbsms:STRING=system \
>>   -Daudacity_use_soundtouch:STRING=system \
>>   -Daudacity_use_portaudio:STRING=local \
>>   -Daudacity_use_midi:STRING=local \
>>   -DAUDACITY_SUFFIX:STRING=""
>>
>> %cmake_build
>>
>> %install
>> %cmakeinstall_std
>>
>> Нужно ли здесь что-то менять?
> Разве что %cmakeinstall_std на %cmake_install.
Спасибо.
>
> В целом, здесь достаточно тривиальный случай, поэтому и адаптировать
> ничего не пришлось.
>
> Изначально я задумывался о том, чтобы убрать %cmakeinstall_std вообще,
> но очень много спеков сизифа его используют, а часть из них не сломались
> после task 269879, как audacity. Поэтому (только после того, как в p9
> пройдёт задание 272559) планируется снабдить его %warning-ом и
> пояснительной надписью и потихоньку вытеснять.

Макросов %make* столько, что, с учетом знания их вариаций в других дистрибутивах, в них очень легко запутаться, теперь и здесь стопицот вариантов... Но без этого не перейти на новые, более логичные и соответствующие современному функционалу cmake, макросы.

%cmake, %cmake_build и %cmake_install выглядят логично и аналогичны %meson, %meson_build и %meson_install, а также %make, %make_build, %make_install , только вот в %make_install DESTDIR не задается.

>
> [1] http://git.altlinux.org/people/arseny/packages/cmake.git?p=cmake.git;a=blob;f=.gear/cmake.macros;h=e9bc3f055dc25457d2072748e5b7dc5e5b7db812;hb=33e1f9d741a2439266bb2e72c5a763b58ae112f4
> [*] JT: Вообще, если адаптировать Unix Haters' handbook к современности,
> то make(1) будет главным уродом в программе цирка.
Уж лучше автокрап и мейкфайлы и даже meson, чем cmake. ИМХО. Очень не люблю его. Документация непонятная. И, интересно, как разруливается кольцевая сборочная зависимость cmake<->libuv при бутстрапе на новые архитектуры.

Re: [devel] I: cmake macros

[Vladislav Zavjalov]

On Wed, Jun 16, 2021 at 10:00:54PM +0300, Mikhail Novosyolov wrote:
> Здесь более интересен вопрос - а чем Unix Makefiles плохи в масштабах дистрибутива. Я как-то задавался таким вопросом, глубоко тему не изучал, но сходу ничего толкового не придумал. Makefile-ы понятны, предсказуемы, их можно грязно похакать при необходимости, чего не скажешь о cmake в целом. Случаев, когда они бы не справлялись со сборкой пакета, не встречал.

Make обладает тем же свойством, что sed, awk, shell, m4 и т.п. языки.
Он очень хорош в простых случаях, но как только собираемый проект
усложняется, надо во-время сбежать на что-то другое типа scons, или
использовать обертки типа autotools, или как-то еще выкручиваться.
Соответственно, все сколь-нибудь большие проекты это и делают.

В масштабах дистрибутива разные пакеты используют разные системы сборки,
и все их можно запустить из соответствующей секции spec-файла. Из этого
не следует, что "make плох в масштабах дистрибутива".

Re: [devel] I: cmake macros

[Michael Shigorin]

On Tue, Jun 15, 2021 at 09:26:43PM +0300, Arseny Maslennikov wrote:
> [*] JT: Вообще, если адаптировать Unix Haters' handbook к современности,
> то make(1) будет главным уродом в программе цирка.

Может, просто gnu make manual стоит почитать?
Он неплохо написан (и читается), с юморком местами.

PS: заглянул в поисках источника _smp_build_ncpus
и лишний раз "порадовался", что "неуродский" cmake
писали те, которые ни одной задницей не подумали,
что уметь традиционный -jN было бы неплохо.

PPS: cmake(1), в смысле man-странички, тоже не вижу.
Не могу с тобою согласиться насчёт главного урода
даже в узкой номинации сборочного инструментария.

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

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Tue, Jun 22, 2021 at 08:24:34AM +0300, Michael Shigorin wrote:
> On Tue, Jun 15, 2021 at 09:26:43PM +0300, Arseny Maslennikov wrote:
> > [*] JT: Вообще, если адаптировать Unix Haters' handbook к современности,
> > то make(1) будет главным уродом в программе цирка.
> 
> Может, просто gnu make manual стоит почитать?
> Он неплохо написан (и читается), с юморком местами.
> 
> PS: заглянул в поисках источника _smp_build_ncpus
> и лишний раз "порадовался", что "неуродский" cmake

Я его так не называл.

> писали те, которые ни одной задницей не подумали,
> что уметь традиционный -jN было бы неплохо.
> 
> PPS: cmake(1), в смысле man-странички, тоже не вижу.
> Не могу с тобою согласиться насчёт главного урода
> даже в узкой номинации сборочного инструментария.

cmake не войдёт в программу unix haters' handbook; ему в этом смысле
повезло. :)

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

Re: [devel] I: cmake macros

[Sergey Afonin]

On Monday 31 May 2021, Arseny Maslennikov wrote:

> Что же касается p9, туда сегодня будет отправлен вариант
> макросов cmake в задании 272559

Какие с этим прогнозы?

-- 
С уважением, Сергей Афонин.

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Wed, Jun 23, 2021 at 02:55:22PM +0400, Sergey Afonin wrote:
> On Monday 31 May 2021, Arseny Maslennikov wrote:
> 
> > Что же касается p9, туда сегодня будет отправлен вариант
> > макросов cmake в задании 272559
> 
> Какие с этим прогнозы?

Задание проходит через отдел тестирования; когда не проходит, я
оперативно реагирую. Я думаю, что все присутствующие грабли
уже или собраны, или предвидены, но зарекаться по-любому не привык.

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

Re: [devel] I: cmake macros

[Nikolai Kostrigin]

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

23.06.2021 14:21, Arseny Maslennikov пишет:
> On Wed, Jun 23, 2021 at 02:55:22PM +0400, Sergey Afonin wrote:
>> On Monday 31 May 2021, Arseny Maslennikov wrote:
>>
>>> Что же касается p9, туда сегодня будет отправлен вариант
>>> макросов cmake в задании 272559
>>
>> Какие с этим прогнозы?
> 
> Задание проходит через отдел тестирования; когда не проходит, я
> оперативно реагирую. Я думаю, что все присутствующие грабли
> уже или собраны, или предвидены, но зарекаться по-любому не привык.
> 
> 

Имеем следующую картину для "-DWITH_BOOST=boost/boost_1_73_0 \" в spec
MySQL:

- cmake из Sisyphus (_cmake__builddir = x86_64-alt-linux) ищет и находит
(не без помощи Вашего патча [1], конечно)

-- Local boost dir /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0
-- Found
/usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0/boost/version.hpp
-- BOOST_VERSION_NUMBER is #define BOOST_VERSION 107300
-- BOOST_INCLUDE_DIR /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0


- в то же время, для p9, c тем же спеком (_cmake__builddir = BUILD)

не находит:

-- WITH_BOOST=/usr/src/RPM/BUILD/MySQL-8.0.25/BUILD/boost/boost_1_73_0
-- BOOST_INCLUDE_DIR
-- LOCAL_BOOST_DIR LOCAL_BOOST_DIR-NOTFOUND
-- LOCAL_BOOST_ZIP LOCAL_BOOST_ZIP-NOTFOUND
-- Could not find (the correct version of) boost.
-- MySQL currently requires boost_1_73_0

CMake Error at cmake/boost.cmake:107 (MESSAGE):
  You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>

Видим, что ищет он в BUILD/boost/boost_1_73_0, а не в
boost/boost_1_73_0, как версия из Сизифа.

Это ожидаемое поведение и каждый должен городить костыли (чего не
хотелось бы, конечно) или Вы поправите поведение макросов в p9?

[1]
http://git.altlinux.org/gears/M/MySQL.git?p=MySQL.git;a=commitdiff;h=1758a2882ac622119f9bed8a2d163b2de998e26b
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

-- 
Best regards,
Nikolai Kostrigin
+ echo 'CMAKE BUILDDIR=[BUILD]'
CMAKE BUILDDIR=[BUILD]

+ echo 'CMAKE BUILDDIR=[x86_64-alt-linux]'
CMAKE BUILDDIR=[x86_64-alt-linux]

Re: [devel] MySQL в p9 (was: I: cmake macros)

[Arseny Maslennikov]

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

On Wed, Jul 07, 2021 at 01:37:25PM +0300, Nikolai Kostrigin wrote:
> Здравствуйте!
> 
> Имеем следующую картину для "-DWITH_BOOST=boost/boost_1_73_0 \" в spec
> MySQL:
> 
> - cmake из Sisyphus (_cmake__builddir = x86_64-alt-linux) ищет и находит
> (не без помощи Вашего патча [1], конечно)
> 
> -- Local boost dir /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0
> -- Found
> /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0/boost/version.hpp
> -- BOOST_VERSION_NUMBER is #define BOOST_VERSION 107300
> -- BOOST_INCLUDE_DIR /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0
> 
> 
> - в то же время, для p9, c тем же спеком (_cmake__builddir = BUILD)
> 
> не находит:
> 
> -- WITH_BOOST=/usr/src/RPM/BUILD/MySQL-8.0.25/BUILD/boost/boost_1_73_0
> -- BOOST_INCLUDE_DIR
> -- LOCAL_BOOST_DIR LOCAL_BOOST_DIR-NOTFOUND
> -- LOCAL_BOOST_ZIP LOCAL_BOOST_ZIP-NOTFOUND
> -- Could not find (the correct version of) boost.
> -- MySQL currently requires boost_1_73_0
> 
> CMake Error at cmake/boost.cmake:107 (MESSAGE):
>   You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
> 
> Видим, что ищет он в BUILD/boost/boost_1_73_0, а не в
> boost/boost_1_73_0, как версия из Сизифа.
> 
> Это ожидаемое поведение и каждый должен городить костыли (чего не
> хотелось бы, конечно) или Вы поправите поведение макросов в p9?
> 

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

Пробую воспроизвести описанный вами случай; взял ветку sisyphus из
git.altlinux.org/gears/M/MySQL.git и собираю в окружении p9:

% cat ~/p9-apt/apt.conf    
Dir::Etc::main "/dev/null";
Dir::Etc::parts "/var/empty";
Dir::Etc::SourceParts "/var/empty";
Dir::Etc::SourceList "/home/user/p9-apt/sources.list";
% cat ~/p9-apt/sources.list
rpm [p9] http://ftp.altlinux.org/pub/distributions/ALTLinux p9/branch/x86_64 classic
rpm [p9] http://ftp.altlinux.org/pub/distributions/ALTLinux p9/branch/noarch classic

Заканчивается сборка следующим образом:

hsh-rebuild: pkg.tar: installed source file.
hsh-rebuild: pkg.tar: fetched build dependencies.
hsh-rebuild: pkg.tar: calculated build dependencies: 
'/usr/bin/hsh-buildreq-filter' -> 'chroot/.host/hsh-buildreq-filter'
warning: Macro %cmake not found
warning: Macro %cmake_build not found
warning: Macro %cmakeinstall_std not found
hsh-rebuild: pkg.tar: fetched build dependencies.
hsh-rebuild: pkg.tar: calculated build dependencies: ccmake chrooted gcc-c++ libaio-devel libedit-devel libevent-devel liblz4-devel libncurses-devel libssl-devel zlib-devel libsystemd-devel protobuf-compiler libprotobuf-lite-devel libtirpc-devel rpcgen
hsh-install: changed working directory to `/home/user/hasher-cmake-p9'
Reading Package Lists...
Building Dependency Tree...
E: Couldn't find package rpcgen
hsh-install: Failed to calculate package file list.
hsh-install: Failed to generate package file list.
gear --hasher -- hsh --apt-config=/home/user/p9-apt/apt.conf -v --lazy-cleanup   27,45s user 18,14s system 64% cpu 1:11,09 total 750k maxrss

До rpmbuild -bb даже не доходит. Т. е. этот спек непригоден для p9 по
независимым от cmake причинам.

Если я что-то делаю не так, то подскажите, пожалуйста, что именно.

> [1]
> http://git.altlinux.org/gears/M/MySQL.git?p=MySQL.git;a=commitdiff;h=1758a2882ac622119f9bed8a2d163b2de998e26b

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

Re: [devel] MySQL в p9 (was: I: cmake macros)

[Nikolai Kostrigin]

07.07.2021 14:35, Arseny Maslennikov пишет:
> On Wed, Jul 07, 2021 at 01:37:25PM +0300, Nikolai Kostrigin wrote:
>> Здравствуйте!
>>
>> Имеем следующую картину для "-DWITH_BOOST=boost/boost_1_73_0 \" в spec
>> MySQL:
>>
[...]
>>
>> Видим, что ищет он в BUILD/boost/boost_1_73_0, а не в
>> boost/boost_1_73_0, как версия из Сизифа.
>>
>> Это ожидаемое поведение и каждый должен городить костыли (чего не
>> хотелось бы, конечно) или Вы поправите поведение макросов в p9?
>>
> 
> Здравствуйте!
> 
> Пробую воспроизвести описанный вами случай; взял ветку sisyphus из
> git.altlinux.org/gears/M/MySQL.git и собираю в окружении p9:
> 
[...]
> E: Couldn't find package rpcgen

Вот причина и она решается либо добавлением патча [2] для
универсальности спека,
либо временным удалением для p9 из BR:
 BuildRequires: libtirpc-devel
 BuildRequires: rpcgen

> hsh-install: Failed to calculate package file list.
> hsh-install: Failed to generate package file list.
> До rpmbuild -bb даже не доходит. Т. е. этот спек непригоден для p9 по
> независимым от cmake причинам.
> 
> Если я что-то делаю не так, то подскажите, пожалуйста, что именно.
> 
>> [1]
>> http://git.altlinux.org/gears/M/MySQL.git?p=MySQL.git;a=commitdiff;h=1758a2882ac622119f9bed8a2d163b2de998e26b
>>
[2]
http://git.altlinux.org/people/nickel/packages/?p=MySQL.git;a=commitdiff;h=128fede0efefd989294bfc7f0aab2046349e8f30
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] I: cmake macros

[Arseny Maslennikov]

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

On Wed, Jul 07, 2021 at 01:37:25PM +0300, Nikolai Kostrigin wrote:
> Здравствуйте!
> 
> Имеем следующую картину для "-DWITH_BOOST=boost/boost_1_73_0 \" в spec
> MySQL:
> 
> - cmake из Sisyphus (_cmake__builddir = x86_64-alt-linux) ищет и находит
> (не без помощи Вашего патча [1], конечно)
> 
> -- Local boost dir /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0
> -- Found
> /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0/boost/version.hpp
> -- BOOST_VERSION_NUMBER is #define BOOST_VERSION 107300
> -- BOOST_INCLUDE_DIR /usr/src/RPM/BUILD/MySQL-8.0.25/boost/boost_1_73_0
> 
> 
> - в то же время, для p9, c тем же спеком (_cmake__builddir = BUILD)
> 
> не находит:
> 
> -- WITH_BOOST=/usr/src/RPM/BUILD/MySQL-8.0.25/BUILD/boost/boost_1_73_0
> -- BOOST_INCLUDE_DIR
> -- LOCAL_BOOST_DIR LOCAL_BOOST_DIR-NOTFOUND
> -- LOCAL_BOOST_ZIP LOCAL_BOOST_ZIP-NOTFOUND
> -- Could not find (the correct version of) boost.
> -- MySQL currently requires boost_1_73_0
> 
> CMake Error at cmake/boost.cmake:107 (MESSAGE):
>   You can download it with -DDOWNLOAD_BOOST=1 -DWITH_BOOST=<directory>
> 
> Видим, что ищет он в BUILD/boost/boost_1_73_0, а не в
> boost/boost_1_73_0, как версия из Сизифа.

Спасибо за репорт!

> Это ожидаемое поведение и каждый должен городить костыли (чего не

Нет, конечно.
RPM из содержимого секций формирует скрипты для sh -e, это надо
учитывать, а макрос в cmake 3.16.3-alt2 не учитывает (точнее, не
полностью, но не полностью — не считается).

> хотелось бы, конечно) или Вы поправите поведение макросов в p9?

См. задание 277546.

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

Re: [devel] I: cmake macros

[Nikolai Kostrigin]

07.07.2021 19:18, Arseny Maslennikov пишет:
> On Wed, Jul 07, 2021 at 01:37:25PM +0300, Nikolai Kostrigin wrote:
[...]
> 
>> Это ожидаемое поведение и каждый должен городить костыли (чего не
> 
> Нет, конечно.
> RPM из содержимого секций формирует скрипты для sh -e, это надо
> учитывать, а макрос в cmake 3.16.3-alt2 не учитывает (точнее, не
> полностью, но не полностью — не считается).
> 
>> хотелось бы, конечно) или Вы поправите поведение макросов в p9?
> 
> См. задание 277546.

Спасибо.
Подтверждаю работоспособность исправленного cmake.macros для локальной
сборки MySQL в p9.
Надеюсь на скорейшее обновление cmake в стабильном бранче репозитория.
> 
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
> 

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] I: cmake macros already in p9

[Arseny Maslennikov]

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

On Wed, Jun 23, 2021 at 02:55:22PM +0400, Sergey Afonin wrote:
> On Monday 31 May 2021, Arseny Maslennikov wrote:
> 
> > Что же касается p9, туда сегодня будет отправлен вариант
> > макросов cmake в задании 272559
> 
> Какие с этим прогнозы?

2021-Jun-25 13:47:34 :: task #272559 for p9 DONE

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

Re: [devel] I: cmake macros already in p9

[Sergey Afonin]

On Friday 25 June 2021, Arseny Maslennikov wrote:

> > > Что же касается p9, туда сегодня будет отправлен вариант
> > > макросов cmake в задании 272559
> > 
> > Какие с этим прогнозы?
> 
> 2021-Jun-25 13:47:34 :: task #272559 for p9 DONE

Что-то не очень работает. Есть задание 272445. Оно не факт, что
когда-нибудь будет отправлено в p9 из-за rpm-build-python3, но 
mysql-workbench-community там не собирается без замены %cmake_install
на make -C BUILD install DESTDIR=%buildroot. Ещё там, правда, надо
BuildRequires rpm-macros-python3 добавить.

-- 
С уважением, Сергей Афонин.

[devel] MySQL + mysql-workbench-community в p9 (was Re: I: cmake macros already in p9)

[Nikolai Kostrigin]

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

06.07.2021 09:22, Sergey Afonin пишет:
> On Friday 25 June 2021, Arseny Maslennikov wrote:
> 
>>>> Что же касается p9, туда сегодня будет отправлен вариант
>>>> макросов cmake в задании 272559
>>>
>>> Какие с этим прогнозы?
>>
>> 2021-Jun-25 13:47:34 :: task #272559 for p9 DONE
> 
> Что-то не очень работает. Есть задание 272445. Оно не факт, что
> когда-нибудь будет отправлено в p9 из-за rpm-build-python3,
Сергей,
"BuildRequires(pre): rpm-build-python3" действительно не хватает.
При этом не обязательно тащить его из Sisyphus в p9.
У меня локально сборка нормально прошла с версией из p9
(rpm-build-python3-0.1.13.1-alt2.noarch.rpm)
А задание это очень хотелось бы видеть в стабильном бранче, т.к. без
него туда не может попасть MySQL-8.0.24+ (ломается пересборка workbench).

> но 
> mysql-workbench-community там не собирается без замены %cmake_install
> на make -C BUILD install DESTDIR=%buildroot. Ещё там, правда, надо
> BuildRequires rpm-macros-python3 добавить.
> 

В качестве проверки создал задание #277424. Оно расшаренное.
На Ваше усмотрение (если ничего не взорвется) можно отправить на
тестирование как есть или удалить подзадание с mysql-workbench-community
и заменить на исправленное Вами для Sisyphus и скопированное в p9.
-- 
Best regards,
Nikolai Kostrigin

Re: [devel] MySQL + mysql-workbench-community в p9 (was Re: I: cmake macros already in p9)

[Nikolai Kostrigin]

06.07.2021 12:31, Nikolai Kostrigin пишет:
> Здравствуйте!
> 
> 06.07.2021 09:22, Sergey Afonin пишет:
>> [...] Есть задание 272445. Оно не факт, что
>> когда-нибудь будет отправлено в p9 из-за rpm-build-python3,
> Сергей,
> "BuildRequires(pre): rpm-build-python3" действительно не хватает.
> При этом не обязательно тащить его из Sisyphus в p9.
> У меня локально сборка нормально прошла с версией из p9
> (rpm-build-python3-0.1.13.1-alt2.noarch.rpm)

Я поторопился с выводами... все-таки оно взорвалось:
x86_64: NEW unmet dependencies detected:
 mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(grt)
 mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(mforms)
 mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(wb_common)



> А задание это очень хотелось бы видеть в стабильном бранче, т.к. без
> него туда не может попасть MySQL-8.0.24+ (ломается пересборка workbench).
[...]
> 
> В качестве проверки создал задание #277424. Оно расшаренное.
> На Ваше усмотрение (если ничего не взорвется) можно отправить на
> тестирование как есть или удалить подзадание с mysql-workbench-community
> и заменить на исправленное Вами для Sisyphus и скопированное в p9.
> 


-- 
Best regards,
Nikolai Kostrigin

Re: [devel] MySQL + mysql-workbench-community в p9 (was Re: I: cmake macros already in p9)

[Nikolai Kostrigin]

06.07.2021 12:51, Nikolai Kostrigin пишет:
> 
> 
> 06.07.2021 12:31, Nikolai Kostrigin пишет:
>> Здравствуйте!
>>
>> 06.07.2021 09:22, Sergey Afonin пишет:
>>> [...] Есть задание 272445. Оно не факт, что
>>> когда-нибудь будет отправлено в p9 из-за rpm-build-python3,
>> Сергей,
>> "BuildRequires(pre): rpm-build-python3" действительно не хватает.
>> При этом не обязательно тащить его из Sisyphus в p9.
>> У меня локально сборка нормально прошла с версией из p9
>> (rpm-build-python3-0.1.13.1-alt2.noarch.rpm)
> 
> Я поторопился с выводами... все-таки оно взорвалось:
> x86_64: NEW unmet dependencies detected:
>  mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(grt)
>  mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(mforms)
>  mysql-workbench-community-data#8.0.25-alt0.M90P.1:p9+277424.540.2.1@1625563331  python2.7(wb_common)
> 
> 
Вроде допилил.

#277424 TESTED #5 [shared] [test-only] p9 MySQL.git=8.0.24-alt0.M90P.1
mysql-connector-odbc.git=8.0.25-alt1 libssh.git=0.9.5-alt1
libantlr4.git=4.8-alt1 mysql-workbench-community.git=8.0.25-alt0.M90P.1
> 
>> А задание это очень хотелось бы видеть в стабильном бранче, т.к. без
>> него туда не может попасть MySQL-8.0.24+ (ломается пересборка workbench).
> [...]
>>
>> В качестве проверки создал задание #277424. Оно расшаренное.
>> На Ваше усмотрение (если ничего не взорвется) можно отправить на
>> тестирование как есть или удалить подзадание с mysql-workbench-community
>> и заменить на исправленное Вами для Sisyphus и скопированное в p9.
>>
> 
> 

-- 
Best regards,
Nikolai Kostrigin

Re: [devel] MySQL + mysql-workbench-community в p9 (was Re: I: cmake macros already in p9)

[Sergey Y. Afonin]

On Tuesday 06 July 2021, Nikolai Kostrigin wrote:

> Вроде допилил.

У меня вчера родился хак в виде

%ifdef add_python_req_skip
%add_python_req_skip _mforms grt mforms
%add_python_req_skip wb workbench cairo_utils wb_common
%endif

что, кажется, не должно помешать сборке в Сизифе без второго Питона.
Но я не понял, почему %cmake_install у меня не отработал локально, раз 
277424 собралось.

-- 
С уважением, Сергей Афонин