[devel] И еще про одну архитектуру

[devel] И еще про одну архитектуру

[Aleksey Novodvorsky]

Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
это e2k (Эльбрус). Она распространена в госструктурах России.
К сожалению, до сих пор доступ к исходникам ее базовой системы
ограничен NDA с МЦСТ.
Если и как только это печальное ограничение будет снято, можно
рассмотреть вопрос о ее включении в основную сборку. Патчи
совместимости для нее активно разрабатываются и посылаются в апстрим.
Иногда принимаются.

Rgrds, Алексей

Re: [devel] И еще про одну архитектуру

[Ilya Kurdyukov]

On 11/23/23 14:08, Aleksey Novodvorsky wrote:
> Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
> это e2k (Эльбрус). Она распространена в госструктурах России.
> К сожалению, до сих пор доступ к исходникам ее базовой системы
> ограничен NDA с МЦСТ.
> Если и как только это печальное ограничение будет снято, можно
> рассмотреть вопрос о ее включении в основную сборку. Патчи
> совместимости для нее активно разрабатываются и посылаются в апстрим.
> Иногда принимаются.

Так как я и делаю эти патчи, то скажу что больше всего патчей на 
совместимость с EDG фронтендом на котором построен компилятор для 
Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи 
обходят баги EDG связанные с C++.

Re: [devel] И еще про одну архитектуру

[Anton Farygin]

On 23.11.2023 10:23, Ilya Kurdyukov wrote:
> On 11/23/23 14:08, Aleksey Novodvorsky wrote:
>> Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
>> это e2k (Эльбрус). Она распространена в госструктурах России.
>> К сожалению, до сих пор доступ к исходникам ее базовой системы
>> ограничен NDA с МЦСТ.
>> Если и как только это печальное ограничение будет снято, можно
>> рассмотреть вопрос о ее включении в основную сборку. Патчи
>> совместимости для нее активно разрабатываются и посылаются в апстрим.
>> Иногда принимаются.
>
> Так как я и делаю эти патчи, то скажу что больше всего патчей на 
> совместимость с EDG фронтендом на котором построен компилятор для 
> Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи 
> обходят баги EDG связанные с C++.

И да, если эта архитектура вдруг въедет в основную сборочницу - то при 
текущей схеме сборки пакетов все ментейнеры массово столкнуться с 
необходимостью исправления своих пакетов под этот проприетарный компилятор.

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 10:28:32 MSK Anton Farygin wrote:
> On 23.11.2023 10:23, Ilya Kurdyukov wrote:
> > On 11/23/23 14:08, Aleksey Novodvorsky wrote:
> >> Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
> >> это e2k (Эльбрус).

[...]
> И да, если эта архитектура вдруг въедет в основную сборочницу - то при
> текущей схеме сборки пакетов все ментейнеры массово столкнуться с
> необходимостью исправления своих пакетов под этот проприетарный компилятор.
Как обычно будут просто делать ExcludeArch, что повлияет на остальные пакеты. 
А ещё хуже -- ExclusiveArch. Плавали -- знаем.

-- 
Regards, Sergey.

Re: [devel] И еще про одну архитектуру

[Anton Farygin]

On 23.11.2023 11:20, Sergey V Turchin wrote:
> On Thursday, 23 November 2023 10:28:32 MSK Anton Farygin wrote:
>> On 23.11.2023 10:23, Ilya Kurdyukov wrote:
>>> On 11/23/23 14:08, Aleksey Novodvorsky wrote:
>>>> Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
>>>> это e2k (Эльбрус).
> [...]
>> И да, если эта архитектура вдруг въедет в основную сборочницу - то при
>> текущей схеме сборки пакетов все ментейнеры массово столкнуться с
>> необходимостью исправления своих пакетов под этот проприетарный компилятор.
> Как обычно будут просто делать ExcludeArch, что повлияет на остальные пакеты.
> А ещё хуже -- ExclusiveArch. Плавали -- знаем.

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

что бы легче было исключать пачками.

Впрочем, это всё легко скриптуется и появление очередного костыля как 
было с rpm-macros-ubt при таком подходе неминуемо.

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 11:22:49 MSK Anton Farygin wrote:

[...]
> > Как обычно будут просто делать ExcludeArch, что повлияет на остальные
> > пакеты. А ещё хуже -- ExclusiveArch. Плавали -- знаем.
> 
> Я бы предложил сделать сразу макрос "слегка поддерживаемые архитектуры"
> и "полностью поддерживаемые архитектуры".
> 
> что бы легче было исключать пачками.
Это само по себе проблема.
Нужно всё дерево пакетов исключать при выпадании одной библиотеки.

[...]

-- 
Regards, Sergey.

Re: [devel] И еще про одну архитектуру

[Anton Farygin]

On 23.11.2023 11:58, Sergey V Turchin wrote:
> On Thursday, 23 November 2023 11:22:49 MSK Anton Farygin wrote:
>
> [...]
>>> Как обычно будут просто делать ExcludeArch, что повлияет на остальные
>>> пакеты. А ещё хуже -- ExclusiveArch. Плавали -- знаем.
>> Я бы предложил сделать сразу макрос "слегка поддерживаемые архитектуры"
>> и "полностью поддерживаемые архитектуры".
>>
>> что бы легче было исключать пачками.
> Это само по себе проблема.
> Нужно всё дерево пакетов исключать при выпадании одной библиотеки.

поэтому придётся максимально упросить эту процедуру.

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

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 12:01:16 MSK Anton Farygin wrote:
> On 23.11.2023 11:58, Sergey V Turchin wrote:
> > On Thursday, 23 November 2023 11:22:49 MSK Anton Farygin wrote:
> > 
> > [...]
> > 
> >>> Как обычно будут просто делать ExcludeArch, что повлияет на остальные
> >>> пакеты. А ещё хуже -- ExclusiveArch. Плавали -- знаем.
> >> 
> >> Я бы предложил сделать сразу макрос "слегка поддерживаемые архитектуры"
> >> и "полностью поддерживаемые архитектуры".
> >> 
> >> что бы легче было исключать пачками.
> > 
> > Это само по себе проблема.
> > Нужно всё дерево пакетов исключать при выпадании одной библиотеки.
> 
> поэтому придётся максимально упросить эту процедуру.
> 
> Да, это будет сложно, и получится какой-то костыль, но я другого пути не
> вижу.
Не. Там всё хуже.
Нужно все пакеты из дерева пропатчить, собрать без библиотеки, оторвать какие-
то зависимости специально для этой архитектуры и т.д. Автоматом без работы над 
пакетами будет ещё хуже.

-- 
Regards, Sergey.

Re: [devel] И еще про одну архитектуру

[Anton Farygin]

On 23.11.2023 12:05, Sergey V Turchin wrote:
> On Thursday, 23 November 2023 12:01:16 MSK Anton Farygin wrote:
>> On 23.11.2023 11:58, Sergey V Turchin wrote:
>>> On Thursday, 23 November 2023 11:22:49 MSK Anton Farygin wrote:
>>>
>>> [...]
>>>
>>>>> Как обычно будут просто делать ExcludeArch, что повлияет на остальные
>>>>> пакеты. А ещё хуже -- ExclusiveArch. Плавали -- знаем.
>>>> Я бы предложил сделать сразу макрос "слегка поддерживаемые архитектуры"
>>>> и "полностью поддерживаемые архитектуры".
>>>>
>>>> что бы легче было исключать пачками.
>>> Это само по себе проблема.
>>> Нужно всё дерево пакетов исключать при выпадании одной библиотеки.
>> поэтому придётся максимально упросить эту процедуру.
>>
>> Да, это будет сложно, и получится какой-то костыль, но я другого пути не
>> вижу.
> Не. Там всё хуже.
> Нужно все пакеты из дерева пропатчить, собрать без библиотеки, оторвать какие-
> то зависимости специально для этой архитектуры и т.д. Автоматом без работы над
> пакетами будет ещё хуже.

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

Т.е. - сделать макрос что-то вроде "%supported_architectures" и делать 
ExclusiveArch для них.

Этот макрос упаковать в какой-то rpm-macros пакет.

Догоняющим архитектурам будет проще - поправил один пакет и сразу будет 
видно ошибки сборки.

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

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 12:13:27 MSK Anton Farygin wrote:

[...]
> >> Да, это будет сложно, и получится какой-то костыль, но я другого пути не
> >> вижу.
> > 
> > Не. Там всё хуже.
> > Нужно все пакеты из дерева пропатчить, собрать без библиотеки, оторвать
> > какие- то зависимости специально для этой архитектуры и т.д. Автоматом
> > без работы над пакетами будет ещё хуже.
> 
> Поэтому лично я уже принял для себя решение - в случае появления новых
> странных архитектур в основной сборочнице  исключать полностью _из
> всех_  своих пакетов такие архитектуры из сборки.
> 
> Т.е. - сделать макрос что-то вроде "%supported_architectures" и делать
> ExclusiveArch для них.
Ааа понял. Распихивать это по всем своим пакетам, а потом сделать ещё раз, 
т.к. админ сборочницы это похерил.
 
> Этот макрос упаковать в какой-то rpm-macros пакет.

[...]

-- 
Regards, Sergey.

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 11:22:49 MSK Anton Farygin wrote:

[...]
> rpm-macros-ubt
Между прочим, функциональность этой табуретки до сих пор не превзойдена. ;-)

-- 
Regards, Sergey.

Re: [devel] И еще про одну архитектуру

[Andrey Savchenko]

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

On Thu, 23 Nov 2023 10:28:32 +0300 Anton Farygin wrote:
> On 23.11.2023 10:23, Ilya Kurdyukov wrote:
> > On 11/23/23 14:08, Aleksey Novodvorsky wrote:
> >> Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
> >> это e2k (Эльбрус). Она распространена в госструктурах России.
> >> К сожалению, до сих пор доступ к исходникам ее базовой системы
> >> ограничен NDA с МЦСТ.
> >> Если и как только это печальное ограничение будет снято, можно
> >> рассмотреть вопрос о ее включении в основную сборку. Патчи
> >> совместимости для нее активно разрабатываются и посылаются в апстрим.
> >> Иногда принимаются.
> >
> > Так как я и делаю эти патчи, то скажу что больше всего патчей на 
> > совместимость с EDG фронтендом на котором построен компилятор для 
> > Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи 
> > обходят баги EDG связанные с C++.
> 
> И да, если эта архитектура вдруг въедет в основную сборочницу - то при 
> текущей схеме сборки пакетов все ментейнеры массово столкнуться с 
> необходимостью исправления своих пакетов под этот проприетарный компилятор.

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

Но там не только с компилятором проблемы: по ядру и тулчейну (тот
же binutils) сильно другие версии, не получится всё
синхронизировать. Это тоже будет приводить к разъездам пакетов.

Best regards,
Andrew Savchenko

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

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 13:29:25 MSK Andrey Savchenko wrote:

[...]
> Но там не только с компилятором проблемы:
Вот именно. Например, для моих пакетов отсутвтвие chromium -- большая 
проблема.

[...]

-- 
Regards, Sergey.

Re: [devel] И еще про одну архитектуру

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 10:23, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>
> On 11/23/23 14:08, Aleksey Novodvorsky wrote:
> > Есть еще одна архитектура, поддерживаемая "Базальт СПО", но не тим --
> > это e2k (Эльбрус). Она распространена в госструктурах России.
> > К сожалению, до сих пор доступ к исходникам ее базовой системы
> > ограничен NDA с МЦСТ.
> > Если и как только это печальное ограничение будет снято, можно
> > рассмотреть вопрос о ее включении в основную сборку. Патчи
> > совместимости для нее активно разрабатываются и посылаются в апстрим.
> > Иногда принимаются.
>
> Так как я и делаю эти патчи, то скажу что больше всего патчей на
> совместимость с EDG фронтендом на котором построен компилятор для
> Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи
> обходят баги EDG связанные с C++.

Да, МЦСТ еше лет 5-7 лет назад собирался перейти на llvm.

Rgrds, Алексей
>

Re: [devel] И еще про одну архитектуру

[Ilya Kurdyukov]

On 11/23/23 14:29, Aleksey Novodvorsky wrote:
>> Так как я и делаю эти патчи, то скажу что больше всего патчей на
>> совместимость с EDG фронтендом на котором построен компилятор для
>> Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи
>> обходят баги EDG связанные с C++.
> Да, МЦСТ еше лет 5-7 лет назад собирался перейти на llvm.

И я им об этом периодически напоминаю. Порт LLVM у них есть, но там свои 
проблемы.

Кстати добавлять сборку всего через Clang будет тем же мучением, разве 
чуть меньшим. Периодически встречаю код, где EDG не справляется, 
проверяю на Clang - он тоже не собирает, а всё потому что авторы кода 
проверяли свой код только на GCC и отошли от стандартов С++. Не говоря 
уже о любителях расширений языка, что доступны только в GCC, например 
nested functions, которые не поддерживаются ни в EDG, ни в Clang.

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

Re: [devel] И еще про одну архитектуру

[Ilya Kurdyukov]

>
>> И да, если эта архитектура вдруг въедет в основную сборочницу - то 
>> при текущей схеме сборки пакетов все ментейнеры массово столкнуться с 
>> необходимостью исправления своих пакетов под этот проприетарный 
>> компилятор.
>>
> Вещь не из приятных. Часть пакетов так и нельзя собрать под Эльбрус 
> или слишком сложно, придётся исключать архитектуру в спеке. Если 
> только доработать систему чтобы ошибки сборки под некоторые 
> архитектуры не приводили в отклонению таска.
>
И проблем тут даже еще больше, потому что все столкнутся с тем, что 
задания будут в несколько раз дольше собираться, все будут ждать когда 
сборка на e2k закончится.

Re: [devel] И еще про одну архитектуру -> girar к этому не до конца готов

[Anton Farygin]

On 23.11.2023 10:49, Ilya Kurdyukov wrote:
>
>>
>>> И да, если эта архитектура вдруг въедет в основную сборочницу - то 
>>> при текущей схеме сборки пакетов все ментейнеры массово столкнуться 
>>> с необходимостью исправления своих пакетов под этот проприетарный 
>>> компилятор.
>>>
>> Вещь не из приятных. Часть пакетов так и нельзя собрать под Эльбрус 
>> или слишком сложно, придётся исключать архитектуру в спеке. Если 
>> только доработать систему чтобы ошибки сборки под некоторые 
>> архитектуры не приводили в отклонению таска.
>>
> И проблем тут даже еще больше, потому что все столкнутся с тем, что 
> задания будут в несколько раз дольше собираться, все будут ждать когда 
> сборка на e2k закончится. 

да, и не работающий --fail-late на сборочнице не облегчает работу с 
большими заданиями на этих странных архитектурах:

https://bugzilla.altlinux.org/48484


Кстати, там уже целая пачка багов на girar накопилась, решение которых 
немного облегчит участь тех, кто пытается собрать что-то большое для 
всех архитектур одновременно:

https://bugzilla.altlinux.org/42552

https://bugzilla.altlinux.org/42552

https://bugzilla.altlinux.org/48485  (эта ошибка частично будет 
нивелирована обновлениями в packages.altlinux.org, но для этого надо 
удалить старые FAILED и EPERM задания)

https://bugzilla.altlinux.org/48479

[devel] Re: И еще про одну архитектуру

[Sergey V Turchin]

On Thursday, 23 November 2023 10:40:43 MSK Ilya Kurdyukov wrote:
> On 11/23/23 14:29, Aleksey Novodvorsky wrote:
> >> Так как я и делаю эти патчи, то скажу что больше всего патчей на
> >> совместимость с EDG фронтендом на котором построен компилятор для
> >> Эльбруса, а не архитектурой Эльбруса как таковой. И чаще всего патчи
> >> обходят баги EDG связанные с C++.
> > 
> > Да, МЦСТ еше лет 5-7 лет назад собирался перейти на llvm.
> 
> И я им об этом периодически напоминаю.
Видимо, это никак и ничего не решает.

[...]

-- 
Regards, Sergey.