[devel] Статус архитектур после бранчевания

[devel] Статус архитектур после бранчевания

[Evgeny Sinelnikov]

Доброй ночи,

хочу дополнить тему "[devel] armh EOL":
https://lists.altlinux.org/pipermail/devel/2023-November/218066.html

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

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

Для бранча p11 принято решение отказаться от архитектур ppc64le и
armh, а также ограничить сопровождение некоторых пользовательских
приложений для i586:
- для ppc64le потеряны перспективы для появления доступных аппаратных средств;
- для armh утрачивается смысл и ценность бранча - все больше и больше
актуальных технологий и проектов отказываются от поддержки 32-битных
процессоров, а почти все новые одноплатные компьютеры - это уже ARMv8,
то есть aarch64;
- для i586 сохраняется ниша поддержки 32-битных библиотек для biarch
на x86 через arepo, при этом некоторые пакеты либо перестанут
сопровождаться и будут удалены, либо будут сопровождаться на более
старых версиях.

Исключение ppc64le и armh из сизифа планируется после завершения
поддержки последнего бранча p10.

Кроме постепенного завершения поддержки устаревающих архитектур мы
планируем добавить в сизиф две новых архитектуры - riscv64 и
loongarch64, которые сейчас сопровождаются в "догонящем" режиме:
- https://en.altlinux.org/Ports/riscv64
- https://en.altlinux.org/Ports/loongarch64

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

Присоединиться к сопровождению riscv64 и/или loongarch64 можно по
запросу в этой рассылке, а также предлагаю возобновить отдельную
рассылку devel-ports@:
- https://lists.altlinux.org/mailman/listinfo/devel-ports

Кроме того, обращаю ваше внимание, что для aarch64 действует отдельная рассылка:
- https://lists.altlinux.org/mailman/listinfo/arm64-baikalm
для riscv64 - тоже:
- https://lists.altlinux.org/mailman/listinfo/riscv-devel
как и для тематики одноплатных компьютеров:
- https://lists.altlinux.org/mailman/listinfo/devel-sbc


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> к тому, чтобы стать ещё одной основной архитектурой в течении
> следующего года. Поживём-посмотрим.

Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?

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

Re: [devel] Статус архитектур после бранчевания

[Evgeny Sinelnikov]

чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> > Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> > серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> > к тому, чтобы стать ещё одной основной архитектурой в течении
> > следующего года. Поживём-посмотрим.
>
> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
>
> Необоснованное включение непопулярных архитектур в сборочницу
> значительно усложняет процессы сопровождения пакетов.

Покой нам только снится. Необоснованное не включение новых архитектур
не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
пользователей)".

Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
не только. А сложности там тоже есть. Нет таких сложностей только на
x86_64. Ну, мы же не отказываемся от новых архитектур. А для
loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
чтобы они не пошли по пути создания множества несовместимых прошивок.
Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
том числе и для нас.


-- 
Sin (Sinelnikov Evgeny)

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
>>> к тому, чтобы стать ещё одной основной архитектурой в течении
>>> следующего года. Поживём-посмотрим.
>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
>>
>> Необоснованное включение непопулярных архитектур в сборочницу
>> значительно усложняет процессы сопровождения пакетов.
> Покой нам только снится. Необоснованное не включение новых архитектур
> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> пользователей)".
>
> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> не только. А сложности там тоже есть. Нет таких сложностей только на
> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> чтобы они не пошли по пути создания множества несовместимых прошивок.
> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> том числе и для нас.

Да, я эти же истории слышал неоднократно про PowerPC и другие 
многообещающие архитектуры.

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

Тратить кучу времени на разборки почему тот или иной софт не собирается 
на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 09:09, Evgeny Sinelnikov <sin@altlinux.org>:
>
> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
> >
> > On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> > > Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> > > серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> > > к тому, чтобы стать ещё одной основной архитектурой в течении
> > > следующего года. Поживём-посмотрим.
> >
> > Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
> >
> > Необоснованное включение непопулярных архитектур в сборочницу
> > значительно усложняет процессы сопровождения пакетов.
>
> Покой нам только снится. Необоснованное не включение новых архитектур
> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> пользователей)".
>
> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> не только. А сложности там тоже есть. Нет таких сложностей только на
> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> чтобы они не пошли по пути создания множества несовместимых прошивок.
> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> том числе и для нас.

+1

Мы сейчас ограничены покупкой серверов только в РФ и Китае
.
Две основных мировых архиткктуры -- x86_64 и aarch64. Еще две, на
которые делает ставку Китай -- RISC-V и Loongarch.

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 09:17, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
> > чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
> >> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> >>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> >>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> >>> к тому, чтобы стать ещё одной основной архитектурой в течении
> >>> следующего года. Поживём-посмотрим.
> >> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
> >>
> >> Необоснованное включение непопулярных архитектур в сборочницу
> >> значительно усложняет процессы сопровождения пакетов.
> > Покой нам только снится. Необоснованное не включение новых архитектур
> > не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> > том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> > пользователей)".
> >
> > Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> > не только. А сложности там тоже есть. Нет таких сложностей только на
> > x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> > loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> > чтобы они не пошли по пути создания множества несовместимых прошивок.
> > Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> > том числе и для нас.
>
> Да, я эти же истории слышал неоднократно про PowerPC и другие
> многообещающие архитектуры.
>
> Предлагаю тогда сразу сделать макрос с этими экспериментальными
> архитектурами, я по умолчанию во все свои пакеты буду его включать как
> ExcludeArch.
>
> Тратить кучу времени на разборки почему тот или иной софт не собирается
> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.

Сейчас RISC-V и Loongarch догоняющие. Но весьма быстро и успешно. По
мере обзаведения серверами для сборочницы и решения немногих
оставшихся проблем со сборкой будем решать вопрос об их добавлении к
основной сборочнице.
Проблемы будут не с ними, а с i586 и вопрос удаление из сборки пакетов
этой архитектуры надо решить.
До сих пор самой проблемной была armh, ее предлагается удалить.
ppc64le имела низкий спрос у наших пользователей во многом по внешним
причинам, которые мы вряд ли могли предвидеть.
Мы все же должны смотреть вперед.

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Evgeny Sinelnikov]

чт, 23 нояб. 2023 г. в 10:17, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
> > чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
> >> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> >>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> >>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> >>> к тому, чтобы стать ещё одной основной архитектурой в течении
> >>> следующего года. Поживём-посмотрим.
> >> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
> >>
> >> Необоснованное включение непопулярных архитектур в сборочницу
> >> значительно усложняет процессы сопровождения пакетов.
> > Покой нам только снится. Необоснованное не включение новых архитектур
> > не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> > том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> > пользователей)".
> >
> > Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> > не только. А сложности там тоже есть. Нет таких сложностей только на
> > x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> > loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> > чтобы они не пошли по пути создания множества несовместимых прошивок.
> > Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> > том числе и для нас.
>
> Да, я эти же истории слышал неоднократно про PowerPC и другие
> многообещающие архитектуры.
>
> Предлагаю тогда сразу сделать макрос с этими экспериментальными
> архитектурами, я по умолчанию во все свои пакеты буду его включать как
> ExcludeArch.
>
> Тратить кучу времени на разборки почему тот или иной софт не собирается
> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.

Это очень странная, контрпродуктивная идея. Стоит проверить, для
начала среди перечня уже собранных пакетов те, которые собраны не
"один в один", то есть уже с исправлениями, и забрать их себе:
http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/

$ curl -s http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
| sed 's/^<a href="\(.*\)<\/a>.*/\1/' | grep "port\.src\.rpm$" | wc -l
152
(можно свои "нагрепать")

Ну, то есть странные опасения. Мы занимаемся портированием и уже
оказываем помощь для важных пакетов, которые точно не имеет смысла
эксклюдить.


-- 
Sin (Sinelnikov Evgeny)

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:

[...]
> Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
Надеюсь, у них Chromium есть под обе архитектуры?

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Grigory Ustinov]

23.11.2023 9:39, Evgeny Sinelnikov пишет:
> чт, 23 нояб. 2023 г. в 10:17, Anton Farygin <rider@basealt.ru>:
>> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
>>> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
>>>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
>>>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
>>>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
>>>>> к тому, чтобы стать ещё одной основной архитектурой в течении
>>>>> следующего года. Поживём-посмотрим.
>>>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
>>>>
>>>> Необоснованное включение непопулярных архитектур в сборочницу
>>>> значительно усложняет процессы сопровождения пакетов.
>>> Покой нам только снится. Необоснованное не включение новых архитектур
>>> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
>>> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
>>> пользователей)".
>>>
>>> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
>>> не только. А сложности там тоже есть. Нет таких сложностей только на
>>> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
>>> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
>>> чтобы они не пошли по пути создания множества несовместимых прошивок.
>>> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
>>> том числе и для нас.
>> Да, я эти же истории слышал неоднократно про PowerPC и другие
>> многообещающие архитектуры.
>>
>> Предлагаю тогда сразу сделать макрос с этими экспериментальными
>> архитектурами, я по умолчанию во все свои пакеты буду его включать как
>> ExcludeArch.
>>
>> Тратить кучу времени на разборки почему тот или иной софт не собирается
>> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.
> Это очень странная, контрпродуктивная идея.

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

>   Стоит проверить, для
> начала среди перечня уже собранных пакетов те, которые собраны не
> "один в один", то есть уже с исправлениями, и забрать их себе:
> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
>
> $ curl -s http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
> | sed 's/^<a href="\(.*\)<\/a>.*/\1/' | grep "port\.src\.rpm$" | wc -l
> 152
> (можно свои "нагрепать")
>
> Ну, то есть странные опасения. Мы занимаемся портированием и уже
> оказываем помощь для важных пакетов, которые точно не имеет смысла
> эксклюдить.
>
>

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 09:37, Aleksey Novodvorsky wrote:
> чт, 23 нояб. 2023 г. в 09:17, Anton Farygin <rider@basealt.ru>:
>> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
>>> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
>>>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
>>>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
>>>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
>>>>> к тому, чтобы стать ещё одной основной архитектурой в течении
>>>>> следующего года. Поживём-посмотрим.
>>>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
>>>>
>>>> Необоснованное включение непопулярных архитектур в сборочницу
>>>> значительно усложняет процессы сопровождения пакетов.
>>> Покой нам только снится. Необоснованное не включение новых архитектур
>>> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
>>> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
>>> пользователей)".
>>>
>>> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
>>> не только. А сложности там тоже есть. Нет таких сложностей только на
>>> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
>>> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
>>> чтобы они не пошли по пути создания множества несовместимых прошивок.
>>> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
>>> том числе и для нас.
>> Да, я эти же истории слышал неоднократно про PowerPC и другие
>> многообещающие архитектуры.
>>
>> Предлагаю тогда сразу сделать макрос с этими экспериментальными
>> архитектурами, я по умолчанию во все свои пакеты буду его включать как
>> ExcludeArch.
>>
>> Тратить кучу времени на разборки почему тот или иной софт не собирается
>> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.
> Сейчас RISC-V и Loongarch догоняющие. Но весьма быстро и успешно. По
> мере обзаведения серверами для сборочницы и решения немногих
> оставшихся проблем со сборкой будем решать вопрос об их добавлении к
> основной сборочнице.
> Проблемы будут не с ними, а с i586 и вопрос удаление из сборки пакетов
> этой архитектуры надо решить.
> До сих пор самой проблемной была armh, ее предлагается удалить.


В моих пакетах armh и i586 доставляют наименьшее количество проблем, 
хотя они там тоже случаются.

Самое проблемное - это powerpc (из того, что есть на основной сборочнице).

Я про ExcludeArch не шучу - историю с безалаберным добавлением новых 
архитектур в основную сборочницу надо прекращать.

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 09:39, Evgeny Sinelnikov wrote:
> чт, 23 нояб. 2023 г. в 10:17, Anton Farygin <rider@basealt.ru>:
>> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
>>> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
>>>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
>>>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
>>>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
>>>>> к тому, чтобы стать ещё одной основной архитектурой в течении
>>>>> следующего года. Поживём-посмотрим.
>>>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
>>>>
>>>> Необоснованное включение непопулярных архитектур в сборочницу
>>>> значительно усложняет процессы сопровождения пакетов.
>>> Покой нам только снится. Необоснованное не включение новых архитектур
>>> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
>>> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
>>> пользователей)".
>>>
>>> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
>>> не только. А сложности там тоже есть. Нет таких сложностей только на
>>> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
>>> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
>>> чтобы они не пошли по пути создания множества несовместимых прошивок.
>>> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
>>> том числе и для нас.
>> Да, я эти же истории слышал неоднократно про PowerPC и другие
>> многообещающие архитектуры.
>>
>> Предлагаю тогда сразу сделать макрос с этими экспериментальными
>> архитектурами, я по умолчанию во все свои пакеты буду его включать как
>> ExcludeArch.
>>
>> Тратить кучу времени на разборки почему тот или иной софт не собирается
>> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.
> Это очень странная, контрпродуктивная идея. Стоит проверить, для
> начала среди перечня уже собранных пакетов те, которые собраны не
> "один в один", то есть уже с исправлениями, и забрать их себе:
> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
>
> $ curl -s http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
> | sed 's/^<a href="\(.*\)<\/a>.*/\1/' | grep "port\.src\.rpm$" | wc -l
> 152
> (можно свои "нагрепать")
>
> Ну, то есть странные опасения. Мы занимаемся портированием и уже
> оказываем помощь для важных пакетов, которые точно не имеет смысла
> эксклюдить.

С powerpc было так-же и до какого-то времени была отличная поддержка 
ментейнерам со стороны сопровождающей команды. А потом она кончилась.

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 10:16, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 09:39, Evgeny Sinelnikov wrote:
> > чт, 23 нояб. 2023 г. в 10:17, Anton Farygin <rider@basealt.ru>:
> >> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
> >>> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
> >>>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> >>>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> >>>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> >>>>> к тому, чтобы стать ещё одной основной архитектурой в течении
> >>>>> следующего года. Поживём-посмотрим.
> >>>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
> >>>>
> >>>> Необоснованное включение непопулярных архитектур в сборочницу
> >>>> значительно усложняет процессы сопровождения пакетов.
> >>> Покой нам только снится. Необоснованное не включение новых архитектур
> >>> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> >>> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> >>> пользователей)".
> >>>
> >>> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> >>> не только. А сложности там тоже есть. Нет таких сложностей только на
> >>> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> >>> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> >>> чтобы они не пошли по пути создания множества несовместимых прошивок.
> >>> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> >>> том числе и для нас.
> >> Да, я эти же истории слышал неоднократно про PowerPC и другие
> >> многообещающие архитектуры.
> >>
> >> Предлагаю тогда сразу сделать макрос с этими экспериментальными
> >> архитектурами, я по умолчанию во все свои пакеты буду его включать как
> >> ExcludeArch.
> >>
> >> Тратить кучу времени на разборки почему тот или иной софт не собирается
> >> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.
> > Это очень странная, контрпродуктивная идея. Стоит проверить, для
> > начала среди перечня уже собранных пакетов те, которые собраны не
> > "один в один", то есть уже с исправлениями, и забрать их себе:
> > http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
> >
> > $ curl -s http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/loongarch64/Sisyphus/loongarch64/SRPMS.classic/
> > | sed 's/^<a href="\(.*\)<\/a>.*/\1/' | grep "port\.src\.rpm$" | wc -l
> > 152
> > (можно свои "нагрепать")
> >
> > Ну, то есть странные опасения. Мы занимаемся портированием и уже
> > оказываем помощь для важных пакетов, которые точно не имеет смысла
> > эксклюдить.
>
> С powerpc было так-же и до какого-то времени была отличная поддержка
> ментейнерам со стороны сопровождающей команды. А потом она кончилась.

Еще и поэтому мы с ней прощаемся.

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 10:09, Sergey V Turchin wrote:
> On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:
>
> [...]
>> Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> Надеюсь, у них Chromium есть под обе архитектуры?
>
Кроме chromium есть ещё масса пакетов, апстримы которых вообще никаким 
образом не ожидают то, что их разработку будут собирать на отличной от 
списка поддерживаемых архитектур.

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

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

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 10:18, Aleksey Novodvorsky wrote:
>> С powerpc было так-же и до какого-то времени была отличная поддержка
>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.
> Еще и поэтому мы с ней прощаемся.

А можно было и не здороваться.

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

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 10:20, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:
> >> С powerpc было так-же и до какого-то времени была отличная поддержка
> >> ментейнерам со стороны сопровождающей команды. А потом она кончилась.
> > Еще и поэтому мы с ней прощаемся.
>
> А можно было и не здороваться.

Когда мы принимали это решение, поставки серверов Power  росли.
И поддержка архитектуры была во всех международных проектах.

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 10:09, Sergey V Turchin <zerg@altlinux.org>:
>
> On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:
>
> [...]
> > Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> Надеюсь, у них Chromium есть под обе архитектуры?

Есть свежий firefox.
Ориентироваться на Google, -- так себе идея.

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 10:26, Aleksey Novodvorsky wrote:
> чт, 23 нояб. 2023 г. в 10:20, Anton Farygin<rider@basealt.ru>:
>> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:
>>>> С powerpc было так-же и до какого-то времени была отличная поддержка
>>>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.
>>> Еще и поэтому мы с ней прощаемся.
>> А можно было и не здороваться.
> Когда мы принимали это решение, поставки серверов Power  росли.
> И поддержка архитектуры была во всех международных проектах.

Так она и сейчас есть, намного лучше чем e2k или loongarch.

Но вопрос не в наличии поддержки в апстриме, а в наличии железа у 
ментейнеров и _желания_ с ним возиться.

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 10:51, Anton Farygin <rider@basealt.ru>:
>
> On 23.11.2023 10:26, Aleksey Novodvorsky wrote:
> > чт, 23 нояб. 2023 г. в 10:20, Anton Farygin<rider@basealt.ru>:
> >> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:
> >>>> С powerpc было так-же и до какого-то времени была отличная поддержка
> >>>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.
> >>> Еще и поэтому мы с ней прощаемся.
> >> А можно было и не здороваться.
> > Когда мы принимали это решение, поставки серверов Power  росли.
> > И поддержка архитектуры была во всех международных проектах.
>
> Так она и сейчас есть, намного лучше чем e2k или loongarch.

loongarch быстро прогрессирует, благодаря коллегам из Саратова. Уже
более 16000 пакетов.
>
> Но вопрос не в наличии поддержки в апстриме, а в наличии железа у
> ментейнеров и _желания_ с ним возиться.

Это вопрос оценки перспективы. Мне кажется, что лучше быть готовыми к
недалекому будущему  заранее, а не спохватываться, когда оно уже
наступит.
Перспективы RISC-V и Loongarch в Китае уже оценили и быстро развивают.
В США и Европе развивают RISC-V.
Стоит ли нам тормозить?
Как ни крути, Sisyphus -- один из немногих крупных международных
проектов со своей открытой инфраструктурой, продукты на основе
которого ориентированы на все категории пользователей.

Rgrds, Алексей

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

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 10:19:47 MSK Anton Farygin wrote:

[...]
> при любых более-менее серьёзных проблемах с архитектурами
> надо или загружаться в проблему полностью (включая железо с этой
> архитектурой) или просто исключать её из сборки.
👍

-- 
Regards, Sergey.

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 10:40:00 MSK Aleksey Novodvorsky wrote:
[...]
> > > Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> > Надеюсь, у них Chromium есть под обе архитектуры?
> Есть свежий firefox.
Это ниочём. У нас много пакетов зависит от движка chromium.
Я полгода выпиливал его из KDE, когда выкинули из ppc64.

> Ориентироваться на Google, -- так себе идея.
Это сейчас апстрим. На основе него всё, а на основе firefox ничего.

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/23/23 15:05, Aleksey Novodvorsky wrote:
> Перспективы RISC-V и Loongarch в Китае уже оценили и быстро развивают.

А можно неудобный вопрос, зачем нам Loongarch, который официально 
запрещено вывозить из Китая. Или предполагается распространять Альт на 
китайском рынке?

> В США и Европе развивают RISC-V.

Не нужен там никому этот RISC-V, больше всего надежд на него у Китая и 
Индии. У США и Европы есть свои x86 и ARM.

Кстати, не заметил чтобы "открытость" RISC-V как-то сказалась на цене 
девелоперских плат, ARM так и остался дешевле. А казалось бы, ведь ARM 
еще за лицензию платят.

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 11:05, Aleksey Novodvorsky wrote:
>> Но вопрос не в наличии поддержки в апстриме, а в наличии железа у
>> ментейнеров и_желания_  с ним возиться.
> Это вопрос оценки перспективы. Мне кажется, что лучше быть готовыми к
> недалекому будущему  заранее, а не спохватываться, когда оно уже
> наступит.

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

А вот в виде основной сборочницы - пожалуйта, когда перспектива уже 
наступит.

Re: [devel] Статус архитектур после бранчевания

[Anton Zhukharev]

On 11/23/23 10:26, Aleksey Novodvorsky wrote:
> чт, 23 нояб. 2023 г. в 10:20, Anton Farygin <rider@basealt.ru>:
>>
>> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:
>>>> С powerpc было так-же и до какого-то времени была отличная поддержка
>>>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.
>>> Еще и поэтому мы с ней прощаемся.
>>
>> А можно было и не здороваться.
> 
> Когда мы принимали это решение, поставки серверов Power  росли.
> И поддержка архитектуры была во всех международных проектах.
Предлагаю не спешить налетать на те же грабли и просто перевести пока 
что следующие архитектуры в догоняющие:

* ppc64le (ИМХО: поспешно попала в ряды основных архитектур)
* armh (устарела)

Писали также, что растут поставки riscv64 и loongarch64, но не повторят 
ли они судьбу ppc64le (вообще, как мне кажется, это "более удачные" 
архитектуры по множеству параметров, нежели ppc64le и e2k)?

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

Идея же догоняющих сборочниц, на мой взгляд, довольно удачная.

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

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 10:18:34 MSK Aleksey Novodvorsky wrote:

[...]
> > С powerpc было так-же и до какого-то времени была отличная поддержка
> > ментейнерам со стороны сопровождающей команды. А потом она кончилась.
> Еще и поэтому мы с ней прощаемся.
Это надо было делать именно в тот момент, иначе это подстава для мантейнеров.

Например, зачем я полгода расхлёбывал это до сих пор несвершившееся прощание?

-- 
Regards, Sergey.

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 10:26:40 MSK Aleksey Novodvorsky wrote:

[...]
> Когда мы принимали это решение, поставки серверов Power  росли.
> И поддержка архитектуры была во всех международных проектах.
Но это не означает необходимость включения в основную сборку.

-- 
Regards, Sergey.

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 11:05:40 MSK Aleksey Novodvorsky wrote:

[...]
> Стоит ли нам тормозить?
А мы готовы полностью поддерживать до момента убирания обратно в догоняющие?

[...]

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/23/23 15:27, Anton Zhukharev wrote:
> Можно также ввести понятие догоняющих-сборочниц-кандидатов-в-основные: 
> просто присылать письма (по желанию) о результатах сборки заданий на 
> этих архитектурах владельцу заданий (на основных) без влияния на 
> успешность сборки на последних (конкретному мейнтенеру; я бы не хотел 
> видеть это в виде списка рассылки).
Ни на что не повлияет, потому что если у мейнтейнера нет допуска к 
машинам на этой архитектуре, чтобы поэкспериментировать с решением 
проблемы - то ничего он не решит.

Re: [devel] Статус архитектур после бранчевания

[Anton Zhukharev]

On 11/23/23 11:34, Ilya Kurdyukov wrote:
> On 11/23/23 15:27, Anton Zhukharev wrote:
>> Можно также ввести понятие догоняющих-сборочниц-кандидатов-в-основные: 
>> просто присылать письма (по желанию) о результатах сборки заданий на 
>> этих архитектурах владельцу заданий (на основных) без влияния на 
>> успешность сборки на последних (конкретному мейнтенеру; я бы не хотел 
>> видеть это в виде списка рассылки).
> Ни на что не повлияет, потому что если у мейнтейнера нет допуска к 
> машинам на этой архитектуре, чтобы поэкспериментировать с решением 
> проблемы - то ничего он не решит.
Когда ppc64le добавляли (аж сразу в основные архитектуры), то, видимо, у 
каждого мейнтейнера был доступ к таким машинам? :)

Если такой логикой руководствоваться и дальше, то можно вообще оставить 
только x86_64 и i586 (тот же aarch64 не у всех найдётся по разным причинам).

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 11:43, Aleksey Novodvorsky wrote:
>
>     Например, зачем я полгода расхлёбывал это до сих пор
>     несвершившееся прощание?
>
>
> Если знать где упасть...
проблема в том, что не знаешь где упасть ты, а падаем мы (ментейнеры).
>
> Мало кто мог предвидеть нынешние изменения.
> Если бы всё было как раньше, то у нас сейчас были бы PPC и даже 
> китайцы не развивали бы Loongarch

Схема работы над архитектурами с догонящими сборочницами всем устраивает 
и отвечает всем запросам.

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

Re: [devel] Статус архитектур после бранчевания

[Антон Мидюков]

23.11.2023 15:17, Ilya Kurdyukov пишет:
> Кстати, не заметил чтобы "открытость" RISC-V как-то сказалась на цене девелоперских плат, ARM так и остался дешевле. А казалось бы, ведь ARM еще за лицензию платят.
> 

Побуду капитаном Очевидность.
Выгода от бесплатности и открытости архитектуры RISC-V может быть только для разработчиков микроархитектур на его основе (ядер процессоров).
При чём все эти разработки проприетарными будут, разумеется.
На цену конечных устройств это влиять не будет (слишком много факторов ценообразования, и в конце концов никто не мешает выгоду распределить по цепочке, минуя потребителя).

-- 
С уважением, Антон Мидюков <antohami@altlinux.org>

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 11:47, Anton Zhukharev wrote:
> On 11/23/23 11:34, Ilya Kurdyukov wrote:
>> On 11/23/23 15:27, Anton Zhukharev wrote:
>>> Можно также ввести понятие 
>>> догоняющих-сборочниц-кандидатов-в-основные: просто присылать письма 
>>> (по желанию) о результатах сборки заданий на этих архитектурах 
>>> владельцу заданий (на основных) без влияния на успешность сборки на 
>>> последних (конкретному мейнтенеру; я бы не хотел видеть это в виде 
>>> списка рассылки).
>> Ни на что не повлияет, потому что если у мейнтейнера нет допуска к 
>> машинам на этой архитектуре, чтобы поэкспериментировать с решением 
>> проблемы - то ничего он не решит.
> Когда ppc64le добавляли (аж сразу в основные архитектуры), то, видимо, 
> у каждого мейнтейнера был доступ к таким машинам? :)
>
> Если такой логикой руководствоваться и дальше, то можно вообще 
> оставить только x86_64 и i586 (тот же aarch64 не у всех найдётся по 
> разным причинам). 

У debian есть такой сервис:

https://wiki.debian.org/RISC-V#Porterboxes

https://wiki.debian.org/PorterBoxHowToUse

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

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/23/23 15:39, Aleksey Novodvorsky wrote:
>
> Можно было бы обсудить создание групп членов тим, которым интересна 
> работа над этими архитектурами.
>
Я просил доступ к машинам RISC-V и Loongarch, поэкспериментировать с 
SIMD, про RISC-V отписывались что всё занято 24/7 и вообще железа мало 
чтобы кого-то пускать. Ну и SIMD инструкций на доступном железе нет. А 
про Loongarch меня просто проигнорировали.

Интересно, а на Loongarch Базальту выдали полную документацию? А то я 
только огрызок документации на ISA видел в свободном доступе, там только 
базовые команды перечислены, SIMD команды не документированы.

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 11:54, Aleksey Novodvorsky wrote:
>
>     До момента наступления момента счастья (популяризации архитектуры)
>
>
> Я уже писал, что этот момент надо определить до того, как отставание 
> станет неизбежным.

В догоняющих сборочницах неизбежное отставание невозможно.

Re: [devel] Статус архитектур после бранчевания

[Paul Wolneykien]

В Thu, 23 Nov 2023 10:51:00 +0300
Anton Farygin <rider@basealt.ru> пишет:

> On 23.11.2023 10:26, Aleksey Novodvorsky wrote:
> > чт, 23 нояб. 2023 г. в 10:20, Anton Farygin<rider@basealt.ru>:  
> >> On 23.11.2023 10:18, Aleksey Novodvorsky wrote:  
> >>>> С powerpc было так-же и до какого-то времени была отличная поддержка
> >>>> ментейнерам со стороны сопровождающей команды. А потом она кончилась.  
> >>> Еще и поэтому мы с ней прощаемся.  
> >> А можно было и не здороваться.  
> > Когда мы принимали это решение, поставки серверов Power  росли.
> > И поддержка архитектуры была во всех международных проектах.  
> 
> Так она и сейчас есть, намного лучше чем e2k или loongarch.
> 
> Но вопрос не в наличии поддержки в апстриме, а в наличии железа у 
> ментейнеров и _желания_ с ним возиться.

  А мы не можем решить этот вопрос как-то аналогично ACL?

  Допустим, мне интересно, чтобы мой пакет собирался на догоняющей
архитектуре follow_archXX. И допустим я хочу принимать в отношении
данного пакета живое участие в сборке его на archXX, а не просто
надеяться на команду портирующих. И для этого я добавляю в ACL
пакета что-то вроде @follow_archXX. После этого сборочные задания
с этим пакетом начинают зеркалиться на догоняющую сборочницу, а мне
начинают приходить письма от неё. Если (когда) мне надоедает заниматься
archXX, я удаляю из ACL @follow_archXX. Письма от догоняющей сборочницы
перестают приходить. А вот что должно происходить с пакетом в догоняющем
репозитории? Наверное, если им не будут заниматься и он будет FTBFS, то
он должен быть автоматически оттуда удалён.

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/23/23 16:36, Paul Wolneykien wrote:
> И допустим я хочу принимать в отношении
> данного пакета живое участие в сборке его на archXX, а не просто
> надеяться на команду портирующих.

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


> А вот что должно происходить с пакетом в догоняющем
> репозитории? Наверное, если им не будут заниматься и он будет FTBFS, то
> он должен быть автоматически оттуда удалён.

Он будет оставаться той версии, в которой еще собирался. Или никакой не 
будет, если никакой вариант не собирался.

Re: [devel] Статус архитектур после бранчевания

[Paul Wolneykien]

В Thu, 23 Nov 2023 16:54:45 +0700
Ilya Kurdyukov <ilyakurdyukov@basealt.ru> пишет:

> On 11/23/23 16:36, Paul Wolneykien wrote:
> > И допустим я хочу принимать в отношении
> > данного пакета живое участие в сборке его на archXX, а не просто
> > надеяться на команду портирующих.  
> 
> Портирующие вас сами найдут и предложат патчи или попросят помочь с 
> решением, потому что каждый раз перенакладывать патчи неудобно. Также 
> люди постоянно работающие с архитектурой чаще сами знают какие на ней 
> проблемы и как лучше их решать.

  Вы хотите сказать, что в догоняющую сборку попадают абсолютно все
пакеты из Сизифа? Если даже и так то, вероятно, не все собираются
(в противном случае все догоняющие архитектуры у нас догоняли бы на
100%, то есть небыли бы догоняющими). И у портирующих могут не скоро
руки дойти до исправления, а я даже и не знаю статус своего пакета на
догоняющей сборочнице (как посмотреть?) Поэтому я предлагаю сделать
какую-то простую ручку (не в спеке!), чтобы можно было обозначить, что
я хочу отслеживать статус пакета P на догоняющей сборочнице F.


> > А вот что должно происходить с пакетом в догоняющем
> > репозитории? Наверное, если им не будут заниматься и он будет FTBFS, то
> > он должен быть автоматически оттуда удалён.  
> 
> Он будет оставаться той версии, в которой еще собирался. Или никакой не 
> будет, если никакой вариант не собирался.
> 
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Статус архитектур после бранчевания

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 01:06:26PM +0300, Paul Wolneykien wrote:
> В Thu, 23 Nov 2023 16:54:45 +0700
> Ilya Kurdyukov <ilyakurdyukov@basealt.ru> пишет:
> 
> > On 11/23/23 16:36, Paul Wolneykien wrote:
> > > И допустим я хочу принимать в отношении
> > > данного пакета живое участие в сборке его на archXX, а не просто
> > > надеяться на команду портирующих.  
> > 
> > Портирующие вас сами найдут и предложат патчи или попросят помочь с 
> > решением, потому что каждый раз перенакладывать патчи неудобно. Также 
> > люди постоянно работающие с архитектурой чаще сами знают какие на ней 
> > проблемы и как лучше их решать.
> 
>   Вы хотите сказать, что в догоняющую сборку попадают абсолютно все
> пакеты из Сизифа?

Да.

> Если даже и так то, вероятно, не все собираются

Да.

> (в противном случае все догоняющие архитектуры у нас догоняли бы на
> 100%, то есть небыли бы догоняющими).

Разница между основными и догоняющими не в этом.

> И у портирующих могут не скоро
> руки дойти до исправления, а я даже и не знаю статус своего пакета на
> догоняющей сборочнице (как посмотреть?)

sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
нет, но всегда можно просто посмотреть, есть ли соответствующаяя
srpm в репозитории.

http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/


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

Пока по поводу riscv64 и loongarch64 можно писать мне; если
внезапно такое будет интересно многим, что нибудь придумаем.

-- 
  wbr,
    iv m.

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/23/23 17:06, Paul Wolneykien wrote:
>    Вы хотите сказать, что в догоняющую сборку попадают абсолютно все
> пакеты из Сизифа?

Да, что соберётся - то соберётся. Самое важное портируют мейнтейнеры 
догоняющей архитектуры.

> И у портирующих могут не скоро руки дойти до исправления

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

> а я даже и не знаю статус своего пакета на догоняющей сборочнице (как посмотреть?)

Посмотреть можно тут: https://packages.altlinux.org/en/sisyphus/

Re: [devel] Статус архитектур после бранчевания

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 03:57:44PM +0700, Ilya Kurdyukov wrote:
> On 11/23/23 15:39, Aleksey Novodvorsky wrote:
> > 
> > Можно было бы обсудить создание групп членов тим, которым интересна
> > работа над этими архитектурами.
> > 
> Я просил доступ к машинам RISC-V и Loongarch, поэкспериментировать с SIMD,
> про RISC-V отписывались что всё занято 24/7 и вообще железа мало чтобы
> кого-то пускать. Ну и SIMD инструкций на доступном железе нет.

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


>  А про Loongarch меня просто проигнорировали.

Не помню такого запроса. Помню флейм о том, можно ли называть loongarch64
"новой". К тому же, на тот момент емнип ещё не было поддержки SIMD
в нашем тулчейне; сейчас она есть, так что если какой-то доступ ещё
интересен, можем попробовать договориться.

-- 
  wbr,
    iv m.

Re: [devel] Статус архитектур после бранчевания

[Andrey Savchenko]

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

On Thu, 23 Nov 2023 09:05:22 +0400 Evgeny Sinelnikov wrote:
> Кроме того, обращаю ваше внимание, что для aarch64 действует отдельная рассылка:
> - https://lists.altlinux.org/mailman/listinfo/arm64-baikalm

Немного странное название для общих aarch64 обсуждений.
Может, переименовать?

Best regards,
Andrew Savchenko

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

Re: [devel] Статус архитектур после бранчевания

[Sergey Bolshakov]

>>>>> "Andrey" == Andrey Savchenko <bircoph-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org> writes:

 > On Thu, 23 Nov 2023 09:05:22 +0400 Evgeny Sinelnikov wrote:
 >> Кроме того, обращаю ваше внимание, что для aarch64 действует отдельная рассылка:
 >> - https://lists.altlinux.org/mailman/listinfo/arm64-baikalm

 > Немного странное название для общих aarch64 обсуждений.
 > Может, переименовать?

Три сообщения за этот год -- переименование точно поможет.

-- 

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 23.11.2023 13:17, Ivan A. Melnikov wrote:
> sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
> нет, но всегда можно просто посмотреть, есть ли соответствующаяя
> srpm в репозитории.
>
> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/

Если надо добавить loongarch  на packages.altlinux.org - повесьте на 
меня задачу во внутреннем трекере, пожалуйста.

Re: [devel] Статус архитектур после бранчевания

[manowar]

23 ноября 2023 г. 13:17:27 GMT+03:00, "Ivan A. Melnikov" <iv@altlinux.org> пишет:
>On Thu, Nov 23, 2023 at 01:06:26PM +0300, Paul Wolneykien wrote:
>> В Thu, 23 Nov 2023 16:54:45 +0700
>> Ilya Kurdyukov <ilyakurdyukov@basealt.ru> пишет:
>> 
>> > On 11/23/23 16:36, Paul Wolneykien wrote:
>> > > И допустим я хочу принимать в отношении
>> > > данного пакета живое участие в сборке его на archXX, а не просто
>> > > надеяться на команду портирующих.  
>> > 
>> > Портирующие вас сами найдут и предложат патчи или попросят помочь с 
>> > решением, потому что каждый раз перенакладывать патчи неудобно. Также 
>> > люди постоянно работающие с архитектурой чаще сами знают какие на ней 
>> > проблемы и как лучше их решать.
>> 
>>   Вы хотите сказать, что в догоняющую сборку попадают абсолютно все
>> пакеты из Сизифа?
>
>Да.
>
>> Если даже и так то, вероятно, не все собираются
>
>Да.
>
>> (в противном случае все догоняющие архитектуры у нас догоняли бы на
>> 100%, то есть небыли бы догоняющими).
>
>Разница между основными и догоняющими не в этом.

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

>
>> И у портирующих могут не скоро
>> руки дойти до исправления, а я даже и не знаю статус своего пакета на
>> догоняющей сборочнице (как посмотреть?)
>
>sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
>нет, но всегда можно просто посмотреть, есть ли соответствующаяя
>srpm в репозитории.
>
>http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/

Я имел в виду немного другое: как посмотреть неуспешные сборочные задания и логи сборки? На PAO только DONE можно найти по имени пакета.

>> Поэтому я предлагаю сделать какую-то простую ручку (не в спеке!)
>> чтобы можно было обозначить, что  я хочу отслеживать статус
>> пакета P на догоняющей сборочнице F.
>
>Пока по поводу riscv64 и loongarch64 можно писать мне; если
>внезапно такое будет интересно многим, что нибудь придумаем.

Тут по соседству обсуждают раннюю подписку на devel@.  Мол, так вовлечённость будет выше. Моё предложение можно рассмотреть как идею раннего подписывания на догоняющие сборочницы. Возможно, что так тоже вовлечённость повысится.

Re: [devel] Статус архитектур после бранчевания

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 02:39:28PM +0300, manowar@altlinux.org wrote:
> 
> 
> 23 ноября 2023 г. 13:17:27 GMT+03:00, "Ivan A. Melnikov" <iv@altlinux.org> пишет:
> >On Thu, Nov 23, 2023 at 01:06:26PM +0300, Paul Wolneykien wrote:
> >> В Thu, 23 Nov 2023 16:54:45 +0700
> >> Ilya Kurdyukov <ilyakurdyukov@basealt.ru> пишет:
> >> 
> >> > On 11/23/23 16:36, Paul Wolneykien wrote:
> >> > > И допустим я хочу принимать в отношении
> >> > > данного пакета живое участие в сборке его на archXX, а не просто
> >> > > надеяться на команду портирующих.  
> >> > 
> >> > Портирующие вас сами найдут и предложат патчи или попросят помочь с 
> >> > решением, потому что каждый раз перенакладывать патчи неудобно. Также 
> >> > люди постоянно работающие с архитектурой чаще сами знают какие на ней 
> >> > проблемы и как лучше их решать.
> >> 
> >>   Вы хотите сказать, что в догоняющую сборку попадают абсолютно все
> >> пакеты из Сизифа?
> >
> >Да.
> >
> >> Если даже и так то, вероятно, не все собираются
> >
> >Да.
> >
> >> (в противном случае все догоняющие архитектуры у нас догоняли бы на
> >> 100%, то есть небыли бы догоняющими).
> >
> >Разница между основными и догоняющими не в этом.
> 
> А мне кажется, что в этом. На мой взгляд, главным критерием включения
> архитектуры в основную сборочницу должно быть именно количество
> синхронизированных пакетов. Конечно, есть ещё известные аппаратные
> (медленная сборка) и этические (Эльбрус) проблемы. Но главный, всё-таки,
> количество пакетов. Почему нет?

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

> >> И у портирующих могут не скоро
> >> руки дойти до исправления, а я даже и не знаю статус своего пакета на
> >> догоняющей сборочнице (как посмотреть?)
> >
> >sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
> >нет, но всегда можно просто посмотреть, есть ли соответствующаяя
> >srpm в репозитории.
> >
> >http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/

> Я имел в виду немного другое: как посмотреть неуспешные сборочные
> задания и логи сборки? На PAO только DONE можно найти по имени пакета.

Для riscv64 есть https://lists.altlinux.org/pipermail/riscv-reports/,
для loongarch64 организовать такую пока руки не дошли, надо сделать.

> >> Поэтому я предлагаю сделать какую-то простую ручку (не в спеке!)
> >> чтобы можно было обозначить, что  я хочу отслеживать статус
> >> пакета P на догоняющей сборочнице F.
> >
> >Пока по поводу riscv64 и loongarch64 можно писать мне; если
> >внезапно такое будет интересно многим, что нибудь придумаем.

> Тут по соседству обсуждают раннюю подписку на devel@.  Мол, так
> вовлечённость будет выше. Моё предложение можно рассмотреть как идею
> раннего подписывания на догоняющие сборочницы. Возможно, что так тоже
> вовлечённость повысится.

Мысль интересная, надо подумать что и как можно сделать.

-- 
  wbr,
    iv m.

Re: [devel] об артефактах догоняющих сборочниц

[Anton Farygin]

On 23.11.2023 14:39, manowar@altlinux.org wrote:
>> sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
>> нет, но всегда можно просто посмотреть, есть ли соответствующаяя
>> srpm в репозитории.
>>
>> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/
> Я имел в виду немного другое: как посмотреть неуспешные сборочные задания и логи сборки? На PAO только DONE можно найти по имени пакета.

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

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

У меня по этому поводу висит такой FR на основную сборочницу:
https://bugzilla.altlinux.org/47105

Возможно для них нужно поднимать не только свой girar, но и всю 
остальную инфраструктуру packages.altlinux.org

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Thursday, 23 November 2023 12:36:39 MSK Paul Wolneykien wrote:

[...]
> Наверное, если им не будут заниматься и он будет FTBFS, то
> он должен быть автоматически оттуда удалён.
Со всей бородой из 200 пакетов? ;-)

-- 
Regards, Sergey.

[devel] Re: об артефактах догоняющих сборочниц

[Sergey V Turchin]

On Thursday, 23 November 2023 15:21:08 MSK Aleksey Novodvorsky wrote:

[...]
> > К тому же мы принципиально разошлись в том, как должна быть устроена
> > догоняющая сборочница с точки зрения синхронизации с основной.
> > У меня по этому поводу висит такой FR на основную сборочницу:
> > https://bugzilla.altlinux.org/47105
> > Возможно для них нужно поднимать не только свой girar, но и всю
> > остальную инфраструктуру packages.altlinux.org
> Да. Стоит ли игра свеч при уже 16000 с хвостом пакетах loongarch, если
> будет мощный сервер?
> Мне кажется, что надо купить серверы, отладить репозитории ports и принять
> окончательное решение ближе к осени.
> До осени поддерживается p10 и потому нам придётся терпеть нынешние
> архитектуры.
По крайней мере, при отлаженном решении можно будет быстро отделить какую-то 
архитектуру в стабильном бранче от основной сборки.

-- 
Regards, Sergey.

[devel] Re: об артефактах догоняющих сборочниц

[Sergey V Turchin]

On Thursday, 23 November 2023 15:33:13 MSK Aleksey Novodvorsky wrote:

[...]
> > По крайней мере, при отлаженном решении можно будет быстро отделить
> > какую-то
> > архитектуру в стабильном бранче от основной сборки.
> Единаясборочница,  при всех её проблемах, это наш плюс. Её фрагментация
> потребует ресурсов, особенно людских. С которыми сейчас непросто.
Она уже фрагментирована догоняющими сборками. "Сумма не меняется".

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Paul Wolneykien]

В Thu, 23 Nov 2023 15:17:53 +0300
Sergey V Turchin <zerg@altlinux.org> пишет:

> On Thursday, 23 November 2023 12:36:39 MSK Paul Wolneykien wrote:
> 
> [...]
> > Наверное, если им не будут заниматься и он будет FTBFS, то
> > он должен быть автоматически оттуда удалён.  
> Со всей бородой из 200 пакетов? ;-)

  Да не: так же, как делаются попытки удаления FTBFS из
основного Сизифа.

Re: [devel] об артефактах догоняющих сборочниц

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 15:38, Sergey V Turchin <zerg@altlinux.org>:
>
> On Thursday, 23 November 2023 15:33:13 MSK Aleksey Novodvorsky wrote:
>
> [...]
> > > По крайней мере, при отлаженном решении можно будет быстро отделить
> > > какую-то
> > > архитектуру в стабильном бранче от основной сборки.
> > Единаясборочница,  при всех её проблемах, это наш плюс. Её фрагментация
> > потребует ресурсов, особенно людских. С которыми сейчас непросто.
> Она уже фрагментирована догоняющими сборками. "Сумма не меняется".

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

Rgrds, Алексей

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

Re: [devel] об артефактах догоняющих сборочниц

[Anton Farygin]

On 23.11.2023 15:52, Aleksey Novodvorsky wrote:
> Нет, если догоняющие сборки постепенно переносить в основную
> сборочницу. Сейчас над догоняющими сборками непосредственно работают
> два героических человека в Саратове. Это и сейчас мало, но делать для
> этих архитектур новую свою инфраструктуру -- совсем другие людские
> ресурсы..

А ты хочешь что бы героически работали все ментейнеры.

[devel] Re: об артефактах догоняющих сборочниц

[Sergey V Turchin]

On Thursday, 23 November 2023 15:52:33 MSK Aleksey Novodvorsky wrote:
> чт, 23 нояб. 2023 г. в 15:38, Sergey V Turchin <zerg@altlinux.org>:
> 
> >
> >
> > On Thursday, 23 November 2023 15:33:13 MSK Aleksey Novodvorsky wrote:
> >
> >
> >
> > [...]
> > 
> > > > По крайней мере, при отлаженном решении можно будет быстро отделить
> > > > какую-то
> > > > архитектуру в стабильном бранче от основной сборки.
> > > 
> > > Единаясборочница,  при всех её проблемах, это наш плюс. Её фрагментация
> > > потребует ресурсов, особенно людских. С которыми сейчас непросто.
> > 
> > Она уже фрагментирована догоняющими сборками. "Сумма не меняется".
> 
> 
> Нет, если догоняющие сборки постепенно переносить в основную
> сборочницу. 
Еще раз повторяю, что когда будет налажено, станет проще переместить какую-то 
архитектуру в стабильном бранче в статус догоняющей. И в такой ситуации не 
придётся "терпеть нынешние архитектуры".

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

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 12:36:39PM +0300, Paul Wolneykien wrote:
> В Thu, 23 Nov 2023 10:51:00 +0300
>   Допустим, мне интересно, чтобы мой пакет собирался на догоняющей
> архитектуре follow_archXX. И допустим я хочу принимать в отношении
> данного пакета живое участие в сборке его на archXX, а не просто
> надеяться на команду портирующих.

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

> И для этого я добавляю в ACL
> пакета что-то вроде @follow_archXX. После этого сборочные задания
> с этим пакетом начинают зеркалиться на догоняющую сборочницу, а мне
> начинают приходить письма от неё.

Как я писал рядом, все задания копируются на догоняющую сборочницу.
И если пакет уже есть в репозитории, то такое задание точно будет
отправлено на сборку.

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

[...]
> А вот что должно происходить с пакетом в догоняющем
> репозитории? Наверное, если им не будут заниматься и он будет FTBFS, то
> он должен быть автоматически оттуда удалён.

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

-- 
  wbr,
    iv m.

Re: [devel] об артефактах догоняющих сборочниц

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky wrote:
> чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> До осени поддерживается p10 и потому нам придётся терпеть нынешние
> архитектуры.

Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
терпеть, а при чём тут Сизиф?

-- 
  wbr,
    iv m.

Re: [devel] об артефактах догоняющих сборочниц

[Aleksey Novodvorsky]

чт, 23 нояб. 2023 г. в 16:50, Ivan A. Melnikov <iv@altlinux.org>:
>
> On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky wrote:
> > чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> > До осени поддерживается p10 и потому нам придётся терпеть нынешние
> > архитектуры.
>
> Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
> терпеть, а при чём тут Сизиф?

Как выяснилось, так устроена сборочница и исправить это сложно.

Rgrds, Алексей

>
> --
>   wbr,
>     iv m.
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] про ppc64le и armh в Сизифе

[Dmitry V. Levin]

On Thu, Nov 23, 2023 at 05:50:07PM +0400, Ivan A. Melnikov wrote:
> On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky wrote:
> > чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> > До осени поддерживается p10 и потому нам придётся терпеть нынешние
> > архитектуры.
> 
> Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
> терпеть, а при чём тут Сизиф?

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

armh это ограничение не касается, поскольку в качестве сборочных узлов
для armh используются сборочные узлы на aarch64.


-- 
ldv

Re: [devel] про ppc64le и armh в Сизифе

[Sergey V Turchin]

On Thursday, 23 November 2023 17:00:09 MSK Dmitry Levin wrote:

[...]
> Пока нужен хотя бы один сборочный узел на ppc64le, нужна и ppc64le в
> Сизифе с софтом для сборочных узлов.
Т.е. достаточноо переместить этот софт для p10 в p10?

-- 
Regards, Sergey.

Re: [devel] про ppc64le и armh в Сизифе

[Dmitry V. Levin]

On Thu, Nov 23, 2023 at 05:05:44PM +0300, Sergey V Turchin wrote:
> On Thursday, 23 November 2023 17:00:09 MSK Dmitry Levin wrote:
> 
> [...]
> > Пока нужен хотя бы один сборочный узел на ppc64le, нужна и ppc64le в
> > Сизифе с софтом для сборочных узлов.
> Т.е. достаточноо переместить этот софт для p10 в p10?

Этот софт не для p10, этот софт для сборочных узлов на всех архитектурах,
на которых работают эти сборочные узлы.  И этот софт в Сизифе, конечно,
где же ему ещё быть.


-- 
ldv

Re: [devel] об артефактах догоняющих сборочниц

[Evgeny Sinelnikov]

чт, 23 нояб. 2023 г. в 17:52, Aleksey Novodvorsky <aen@basealt.ru>:
>
> чт, 23 нояб. 2023 г. в 16:50, Ivan A. Melnikov <iv@altlinux.org>:
> >
> > On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky wrote:
> > > чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> > > До осени поддерживается p10 и потому нам придётся терпеть нынешние
> > > архитектуры.
> >
> > Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
> > терпеть, а при чём тут Сизиф?
>
> Как выяснилось, так устроена сборочница и исправить это сложно.

ldv@ давал пояснение. Сама сборочница на сборочных узлах работает на
сизифе. Чтобы собирать под p10, всё равно, нужно иметь сизиф.



-- 
Sin (Sinelnikov Evgeny)

Re: [devel] про ppc64le и armh в Сизифе

[Ivan A. Melnikov]

On Thu, Nov 23, 2023 at 04:00:09PM +0200, Dmitry V. Levin wrote:
> On Thu, Nov 23, 2023 at 05:50:07PM +0400, Ivan A. Melnikov wrote:
> > On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky wrote:
> > > чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> > > До осени поддерживается p10 и потому нам придётся терпеть нынешние
> > > архитектуры.
> > 
> > Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
> > терпеть, а при чём тут Сизиф?
> 
> Речь, очевидно, только про ppc64le, которая нужна в Сизифе как минимум для
> того, чтобы поддерживать сборочные узлы для этой архитектуры.  Пока есть
> хотя бы один репозиторий с ppc64le, нужен и сборочный узел для ppc64le.
> Пока нужен хотя бы один сборочный узел на ppc64le, нужна и ppc64le в
> Сизифе с софтом для сборочных узлов.
> 
> armh это ограничение не касается, поскольку в качестве сборочных узлов
> для armh используются сборочные узлы на aarch64.

Теперь понятно, спасибо.

-- 
  wbr,
    iv m.

Re: [devel] про ppc64le и armh в Сизифе

[Denis Medvedev]

On Thu, 23 Nov 2023 23:00:58 +0400
"Ivan A. Melnikov" <iv@altlinux.org> wrote:

> On Thu, Nov 23, 2023 at 04:00:09PM +0200, Dmitry V. Levin wrote:
> > On Thu, Nov 23, 2023 at 05:50:07PM +0400, Ivan A. Melnikov wrote:
> > > On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky
> > > wrote:
> > > > чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
> > > > До осени поддерживается p10 и потому нам придётся терпеть
> > > > нынешние архитектуры.
> > > 
> > > Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
> > > терпеть, а при чём тут Сизиф?
> > 
> > Речь, очевидно, только про ppc64le, которая нужна в Сизифе как
> > минимум для того, чтобы поддерживать сборочные узлы для этой
> > архитектуры.  Пока есть хотя бы один репозиторий с ppc64le, нужен и
> > сборочный узел для ppc64le. Пока нужен хотя бы один сборочный узел
> > на ppc64le, нужна и ppc64le в Сизифе с софтом для сборочных узлов.
Интересно, а у нас есть ли ЗИП и возможность замены ppc64le сборочных
узлов если что-то случится?
> > 
> > armh это ограничение не касается, поскольку в качестве сборочных
> > узлов для armh используются сборочные узлы на aarch64.
> 
> Теперь понятно, спасибо.
> 

Re: [devel] про ppc64le и armh в Сизифе

[Anton Farygin]

On 23.11.2023 23:31, Denis Medvedev wrote:
> On Thu, 23 Nov 2023 23:00:58 +0400
> "Ivan A. Melnikov" <iv@altlinux.org> wrote:
>
>> On Thu, Nov 23, 2023 at 04:00:09PM +0200, Dmitry V. Levin wrote:
>>> On Thu, Nov 23, 2023 at 05:50:07PM +0400, Ivan A. Melnikov wrote:
>>>> On Thu, Nov 23, 2023 at 03:21:08PM +0300, Aleksey Novodvorsky
>>>> wrote:
>>>>> чт, 23 нояб. 2023 г., 15:01 Anton Farygin <rider@basealt.ru>:
>>>>> До осени поддерживается p10 и потому нам придётся терпеть
>>>>> нынешние архитектуры.
>>>> Не очень понимаю, какая здесь связь. То есть, в p10 да, придётся
>>>> терпеть, а при чём тут Сизиф?
>>> Речь, очевидно, только про ppc64le, которая нужна в Сизифе как
>>> минимум для того, чтобы поддерживать сборочные узлы для этой
>>> архитектуры.  Пока есть хотя бы один репозиторий с ppc64le, нужен и
>>> сборочный узел для ppc64le. Пока нужен хотя бы один сборочный узел
>>> на ppc64le, нужна и ppc64le в Сизифе с софтом для сборочных узлов.
> Интересно, а у нас есть ли ЗИП и возможность замены ppc64le сборочных
> узлов если что-то случится?

Хороший интересный вопрос.

Вот лог вчерашнего падения тестов на одном из пакетов задания с 
обновлением ocaml:

[00:00:07] @@ -52,16 +53,20 @@
[00:00:07]  # let q : int Queue.t = Queue.create();;
[00:00:07]  val q : int Queue.t = <abstr>
[00:00:07]  # Iter.( 1 -- 10 |> to_queue q);;
[00:00:07] -- : unit = ()
[00:00:07] +File "_none_", line 1:
[00:00:07] +Error: I/O error: /usr/src/RPM/BUILD/ocaml-iter-1.7/_build/install/default/lib/iter/iter.cmi: No such file or directory
[00:00:07]  # Iter.of_queue q |> Iter.to_list ;;
[00:00:07] -- : int list = [1; 2; 3; 4; 5; 6; 7; 8; 9; 10]
[00:00:07] +File "_none_", line 1:
[00:00:07] +Error: I/O error: /usr/src/RPM/BUILD/ocaml-iter-1.7/_build/install/default/lib/iter/iter.cmi: No such file or directory
[00:00:07]

Локально естественно не воспроизводится.

Re: [devel] про ppc64le и armh в Сизифе

[Sergey V Turchin]

On Thursday, 23 November 2023 17:13:16 MSK Dmitry Levin wrote:
> On Thu, Nov 23, 2023 at 05:05:44PM +0300, Sergey V Turchin wrote:
> > On Thursday, 23 November 2023 17:00:09 MSK Dmitry Levin wrote:
> > 
> > [...]
> > 
> > > Пока нужен хотя бы один сборочный узел на ppc64le, нужна и ppc64le в
> > > Сизифе с софтом для сборочных узлов.
> > 
> > Т.е. достаточноо переместить этот софт для p10 в p10?
> 
> Этот софт не для p10, этот софт для сборочных узлов на всех архитектурах,
> на которых работают эти сборочные узлы.  И этот софт в Сизифе, конечно,
> где же ему ещё быть.
Я вроде в прошлом письме написал.

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Andrey Savchenko]

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

On Thu, 23 Nov 2023 10:12:49 +0300 Grigory Ustinov wrote:
> 23.11.2023 9:39, Evgeny Sinelnikov пишет:
> > чт, 23 нояб. 2023 г. в 10:17, Anton Farygin <rider@basealt.ru>:
> >> On 23.11.2023 09:10, Evgeny Sinelnikov wrote:
> >>> чт, 23 нояб. 2023 г. в 09:43, Anton Farygin <rider@basealt.ru>:
> >>>> On 23.11.2023 08:05, Evgeny Sinelnikov wrote:
> >>>>> Архитектура riscv64 ограничена сейчас отсутствием достаточно мощных
> >>>>> серверных узлов для сборочницы, а loongarch64 - полным ходом движется
> >>>>> к тому, чтобы стать ещё одной основной архитектурой в течении
> >>>>> следующего года. Поживём-посмотрим.
> >>>> Успехи powerpc не дают покоя и надо добавить ещё работы ментейнерам ?
> >>>>
> >>>> Необоснованное включение непопулярных архитектур в сборочницу
> >>>> значительно усложняет процессы сопровождения пакетов.
> >>> Покой нам только снится. Необоснованное не включение новых архитектур
> >>> не даёт возможности их полноценно развивать. Тут, как всегда, вопрос в
> >>> том: "А будет ли железо? (Ну, и сопутствующие коммерческие интересы у
> >>> пользователей)".
> >>>
> >>> Я думаю, что для loongarch64 всё будет. По крайней мере, в России. И
> >>> не только. А сложности там тоже есть. Нет таких сложностей только на
> >>> x86_64. Ну, мы же не отказываемся от новых архитектур. А для
> >>> loongarch64 все достаточно хорошо развивается. Очень хорошо. Главное,
> >>> чтобы они не пошли по пути создания множества несовместимых прошивок.
> >>> Сейчас в этой теме мы практически первые и это тоже очень хорошо. В
> >>> том числе и для нас.
> >> Да, я эти же истории слышал неоднократно про PowerPC и другие
> >> многообещающие архитектуры.
> >>
> >> Предлагаю тогда сразу сделать макрос с этими экспериментальными
> >> архитектурами, я по умолчанию во все свои пакеты буду его включать как
> >> ExcludeArch.
> >>
> >> Тратить кучу времени на разборки почему тот или иной софт не собирается
> >> на архитектуре, пользователей у которой нет и не ожидается - я не собираюсь.
> > Это очень странная, контрпродуктивная идея.
> 
> Не все апстримы поддерживают наш новаторский подход. У многих просто нет 
> доступа ко всем архитектурам на свете.

Но ведь это совсем не проблема, было бы желание:
https://portal.cfarm.net/machines/list/

Однако, почти все проблемы возникают из-за нестандартного, кривого
кода, который слепо завязывается на особенности или железа, или
программного стека, используемом автором на этом железе. Чего
только печально известные nested functions стоят.

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

А ещё можно не велосипедить и посмотреть как другие дистрибутивы
поддерживают этот пакет на нужной архитектуре: тот же Debian,
Gentoo и многие другие многоархитектурники.

Best regards,
Andrew Savchenko

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

Re: [devel] об артефактах догоняющих сборочниц

[Danil Shein]

Развернуть нужную инфраструктуру для догоняющей архитектуры совсем даже 
не сложно.

Весь комплект:
1. хост, на котором будет работать загрузчик требует только монтирования 
рабочей директории и архива сборочницы
2. хост, на котором будет БД ClickHouse
3. хост, на котором будут запущены API и фронт (сайт) - оба запускаются 
в докере
4. доступ к существующему или запуск собственного сервера (кластера) 
RabbitMQ

Все роли из пп. 1-3  спокойно решаются и на одном хосте - так мы уже 
разворачивали инфру для тестовой сборочницы.

23.11.2023 15:01, Anton Farygin пишет:
> On 23.11.2023 14:39, manowar@altlinux.org wrote:
>>> sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
>>> нет, но всегда можно просто посмотреть, есть ли соответствующаяя
>>> srpm в репозитории.
>>>
>>> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/
>> Я имел в виду немного другое: как посмотреть неуспешные сборочные 
>> задания и логи сборки? На PAO только DONE можно найти по имени пакета.
>
> Мы немного поговорили о том, как устроены догоняющие сборочницы и 
> вместе пришли к выводу что публикация каких-то артефактов из заданий 
> догоняющих сборочниц не имеет смысла - без полного доступа к архивам 
> этих самых сборочниц.
>
> К тому же мы принципиально разошлись в том, как должна быть устроена 
> догоняющая сборочница с точки зрения синхронизации с основной.
>
> У меня по этому поводу висит такой FR на основную сборочницу:
> https://bugzilla.altlinux.org/47105
>
> Возможно для них нужно поднимать не только свой girar, но и всю 
> остальную инфраструктуру packages.altlinux.org
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
-- 

*Данил Шеин / Danil Shein*

dshein@altlinux.org
dshein@basealt.ru

Re: [devel] об артефактах догоняющих сборочниц

[Danil Shein]

Если уж надо реализовать прям срочно, то можно поднять инфраструктуру 
(ALTRepo DB + ALTRepo API + ALTRepo Front) отдельно для каждой 
догоняющей архитектуры.
Интегрировать это в основной p.a.o вполне можно через редиректы на 
субдомены вида riscv64.packages.altlinux.org и т.п.

Мы таким образом можем убрать вообще всю информацию о портах с основного 
сайта кроме ссылок, включая загрузку репозиториев портов в основную БД, 
при этом получив одинаковый функционал для всех архитектур - как 
существующих, так и новых (если таковые появятся).

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

Единой точкой отказа может стать лишь использование одного кластера 
RAbbitMQ  на всех, но никто не запрещает запустить его локально - это 
просто транспорт сообщений между сборочницей  и сервисом ALTRepo DB.

Отображение версий пакетов в репозиториях догоняющих архитектур (левое 
меню на р.а.о) для быстрой навигации, легко можно получать через АПИ.

28.11.2023 15:44, Danil Shein пишет:
> Развернуть нужную инфраструктуру для догоняющей архитектуры совсем 
> даже не сложно.
>
> Весь комплект:
> 1. хост, на котором будет работать загрузчик требует только 
> монтирования рабочей директории и архива сборочницы
> 2. хост, на котором будет БД ClickHouse
> 3. хост, на котором будут запущены API и фронт (сайт) - оба 
> запускаются в докере
> 4. доступ к существующему или запуск собственного сервера (кластера) 
> RabbitMQ
>
> Все роли из пп. 1-3  спокойно решаются и на одном хосте - так мы уже 
> разворачивали инфру для тестовой сборочницы.
>
> 23.11.2023 15:01, Anton Farygin пишет:
>> On 23.11.2023 14:39, manowar@altlinux.org wrote:
>>>> sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
>>>> нет, но всегда можно просто посмотреть, есть ли соответствующаяя
>>>> srpm в репозитории.
>>>>
>>>> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/
>>> Я имел в виду немного другое: как посмотреть неуспешные сборочные 
>>> задания и логи сборки? На PAO только DONE можно найти по имени пакета.
>>
>> Мы немного поговорили о том, как устроены догоняющие сборочницы и 
>> вместе пришли к выводу что публикация каких-то артефактов из заданий 
>> догоняющих сборочниц не имеет смысла - без полного доступа к архивам 
>> этих самых сборочниц.
>>
>> К тому же мы принципиально разошлись в том, как должна быть устроена 
>> догоняющая сборочница с точки зрения синхронизации с основной.
>>
>> У меня по этому поводу висит такой FR на основную сборочницу:
>> https://bugzilla.altlinux.org/47105
>>
>> Возможно для них нужно поднимать не только свой girar, но и всю 
>> остальную инфраструктуру packages.altlinux.org
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
-- 

*Данил Шеин / Danil Shein*

dshein@altlinux.org
dshein@basealt.ru

Re: [devel] об артефактах догоняющих сборочниц

[Anton Farygin]

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

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


On 28.11.2023 16:14, Danil Shein wrote:
> Если уж надо реализовать прям срочно, то можно поднять инфраструктуру 
> (ALTRepo DB + ALTRepo API + ALTRepo Front) отдельно для каждой 
> догоняющей архитектуры.
> Интегрировать это в основной p.a.o вполне можно через редиректы на 
> субдомены вида riscv64.packages.altlinux.org и т.п.
>
> Мы таким образом можем убрать вообще всю информацию о портах с 
> основного сайта кроме ссылок, включая загрузку репозиториев портов в 
> основную БД, при этом получив одинаковый функционал для всех 
> архитектур - как существующих, так и новых (если таковые появятся).
>
> При этом платой будет лишь по одной виртуалке, с достаточной 
> производительностью, на каждую такую архитектуру.
>
> Единой точкой отказа может стать лишь использование одного кластера 
> RAbbitMQ  на всех, но никто не запрещает запустить его локально - это 
> просто транспорт сообщений между сборочницей  и сервисом ALTRepo DB.
>
> Отображение версий пакетов в репозиториях догоняющих архитектур (левое 
> меню на р.а.о) для быстрой навигации, легко можно получать через АПИ.
>
> 28.11.2023 15:44, Danil Shein пишет:
>> Развернуть нужную инфраструктуру для догоняющей архитектуры совсем 
>> даже не сложно.
>>
>> Весь комплект:
>> 1. хост, на котором будет работать загрузчик требует только 
>> монтирования рабочей директории и архива сборочницы
>> 2. хост, на котором будет БД ClickHouse
>> 3. хост, на котором будут запущены API и фронт (сайт) - оба 
>> запускаются в докере
>> 4. доступ к существующему или запуск собственного сервера (кластера) 
>> RabbitMQ
>>
>> Все роли из пп. 1-3  спокойно решаются и на одном хосте - так мы уже 
>> разворачивали инфру для тестовой сборочницы.
>>
>> 23.11.2023 15:01, Anton Farygin пишет:
>>> On 23.11.2023 14:39, manowar@altlinux.org wrote:
>>>>> sisyphus_riscv64 есть на packages.altlinux.org; loongarch64 пока
>>>>> нет, но всегда можно просто посмотреть, есть ли соответствующаяя
>>>>> srpm в репозитории.
>>>>>
>>>>> http://ftp.altlinux.org/pub/distributions/ALTLinux/ports/
>>>> Я имел в виду немного другое: как посмотреть неуспешные сборочные 
>>>> задания и логи сборки? На PAO только DONE можно найти по имени пакета.
>>>
>>> Мы немного поговорили о том, как устроены догоняющие сборочницы и 
>>> вместе пришли к выводу что публикация каких-то артефактов из заданий 
>>> догоняющих сборочниц не имеет смысла - без полного доступа к архивам 
>>> этих самых сборочниц.
>>>
>>> К тому же мы принципиально разошлись в том, как должна быть устроена 
>>> догоняющая сборочница с точки зрения синхронизации с основной.
>>>
>>> У меня по этому поводу висит такой FR на основную сборочницу:
>>> https://bugzilla.altlinux.org/47105
>>>
>>> Возможно для них нужно поднимать не только свой girar, но и всю 
>>> остальную инфраструктуру packages.altlinux.org
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel@lists.altlinux.org
>>> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] Статус архитектур после бранчевания

[mikhailnov]

23.11.2023 10:09, Sergey V Turchin пишет:
> On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:
>
> [...]
>> Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> Надеюсь, у них Chromium есть под обе архитектуры?

Под LoongArch Chromium есть, но проприетарный, без исходников, собранный под old world ABI, однако работает шустро.

http://pkg.loongnix.cn/loongnix/pool/main/l/lbrowser/

То есть теоретически можно ожидать появления поддержки loongarch в хотя бы QtWebEgine.

Re: [devel] Статус архитектур после бранчевания

[Aleksey Novodvorsky]

ср, 29 нояб. 2023 г. в 04:20, mikhailnov <mikhailnov@altlinux.org>:
>
>
> 23.11.2023 10:09, Sergey V Turchin пишет:
> > On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:
> >
> > [...]
> >> Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> > Надеюсь, у них Chromium есть под обе архитектуры?
>
> Под LoongArch Chromium есть, но проприетарный, без исходников, собранный под old world ABI, однако работает шустро.
>
> http://pkg.loongnix.cn/loongnix/pool/main/l/lbrowser/
>
А вот RISC-V:

https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/chromium?expand=1

Rgrds, Алексей

Re: [devel] Статус архитектур после бранчевания

[Ilya Kurdyukov]

On 11/29/23 12:45, Aleksey Novodvorsky wrote:
>> Под LoongArch Chromium есть, но проприетарный, без исходников, собранный под old world ABI, однако работает шустро.
>>
>> http://pkg.loongnix.cn/loongnix/pool/main/l/lbrowser/
>>
> А вот RISC-V:
>
> https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/chromium?expand=1
Обе архитектуры являются клонами MIPS - там по сути что требуется это 
просто скопировать весь код для MIPS под другим именем и поменять 
бинарную кодировку инструкций. Только для единичных инструкций не 
найдётся эквивалента и придётся изменить чуть дальше бинарной кодировки.

Re: [devel] Статус архитектур после бранчевания

[Ivan A. Melnikov]

On Wed, Nov 29, 2023 at 04:20:26AM +0300, mikhailnov wrote:
> 
> 23.11.2023 10:09, Sergey V Turchin пишет:
> > On Thursday, 23 November 2023 09:19:09 MSK Aleksey Novodvorsky wrote:
> >
> > [...]
> >> Еще две, на которые делает ставку Китай -- RISC-V и Loongarch.
> > Надеюсь, у них Chromium есть под обе архитектуры?
> 
> Под LoongArch Chromium есть, но проприетарный, без исходников, собранный под old world ABI, однако работает шустро.
> 
> http://pkg.loongnix.cn/loongnix/pool/main/l/lbrowser/
> 
> То есть теоретически можно ожидать появления поддержки loongarch в хотя бы QtWebEgine.

Основная сложность портирования chromium под новую архитектуру -- это v8,
и она решена, node и под loongarch64 и под riscv64 достаточно быстр
и стабилен, причём вполне апстримный.

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

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

Для riscv64 здесь перспективы самые светлые, поскольку Google
вместе с китайскими коллегами хотят сделать riscv64 одной из
основных архитектур андроида.

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

-- 
  wbr,
    iv m.

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Wednesday, 29 November 2023 10:50:07 MSK Ivan Melnikov wrote:

[...]
> Основная проблема с здесь в том, что однажды сделанной поддержки
> недостаточно, нужно ещё эти патчи поддерживать -- то есть, обновлять
> с каждым новым релизом, и апстримить. Для ppc64le в какой-то момент
> оказалось, что заниматься этим некому, и от этого собственно
> проблемы и начались.
Как здесь уже высказывались, основная задача -- решить это до, а не после.

[...]

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Anton Farygin]

On 29.11.2023 11:00, Sergey V Turchin wrote:
> On Wednesday, 29 November 2023 10:50:07 MSK Ivan Melnikov wrote:
>
> [...]
>> Основная проблема с здесь в том, что однажды сделанной поддержки
>> недостаточно, нужно ещё эти патчи поддерживать -- то есть, обновлять
>> с каждым новым релизом, и апстримить. Для ppc64le в какой-то момент
>> оказалось, что заниматься этим некому, и от этого собственно
>> проблемы и начались.
> Как здесь уже высказывались, основная задача -- решить это до, а не после.
>

В смысле ? Основная задача - решать это всё время.

[devel] Re: Статус архитектур после бранчевания

[Sergey V Turchin]

On Wednesday, 29 November 2023 14:10:47 MSK Anton Farygin wrote:
> On 29.11.2023 11:00, Sergey V Turchin wrote:
> > On Wednesday, 29 November 2023 10:50:07 MSK Ivan Melnikov wrote:
> > 
> > [...]
> > 
> >> Основная проблема с здесь в том, что однажды сделанной поддержки
> >> недостаточно, нужно ещё эти патчи поддерживать -- то есть, обновлять
> >> с каждым новым релизом, и апстримить. Для ppc64le в какой-то момент
> >> оказалось, что заниматься этим некому, и от этого собственно
> >> проблемы и начались.
> > 
> > Как здесь уже высказывались, основная задача -- решить это до, а не после.
> 
> В смысле ? Основная задача - решать это всё время.
Сначала решить "загружаться в проблему полностью (включая железо с этой 
архитектурой) или просто исключать её из сборки", а не включать в основные 
неглядя, а потом "терпеть нынешние архитектуры".

-- 
Regards, Sergey.

Re: [devel] Статус архитектур после бранчевания

[Yuri Sedunov]

В Чт, 30/11/2023 в 00:05 +0400, Георгий Быстренин пишет:
> 
> 
> чт, 23 нояб. 2023 г., 12:26 Aleksey Novodvorsky <aen@basealt.ru>:
> > 
> > 
> > чт, 23 нояб. 2023 г., 11:18 Ilya Kurdyukov
> > <ilyakurdyukov@basealt.ru>:
> > > On 11/23/23 15:05, Aleksey Novodvorsky wrote:
> > > > Перспективы RISC-V и Loongarch в Китае уже оценили и быстро
> > > > развивают.
> > > 
> > > А можно неудобный вопрос, зачем нам Loongarch, который официально
> > > запрещено вывозить из Китая. Или предполагается распространять
> > > Альт на китайском рынке?
> > 
> > Меньше читайте газеты. 
> 
> Вот и в газетах подъехали новости
> https://3dnews.ru/1096642/kitayskaya-loongson-vipustila-noviy-protsessor-3a6000-s-pokazatelem-ipc-kak-u-intel-core-i514600k


И в кино
https://www.youtube.com/watch?v=LhDAZDArWWo

> > 

-- 
Yuri N. Sedunov