Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Vladimir D. Seleznev]

Hi, devel@!

On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> 
> subtask  name     aarch64    armh  i586  ppc64le  x86_64
>    #300  crtools     1:31  failed     -     1:27      49
> 
> 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> #100 removed
> #200 removed
> #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> 2022-Jan-17 11:27:30 :: #300: force rebuild
> 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request

А кто знает как такое чинить?

> 2022-Jan-17 11:29:03 :: [armh] crtools.git 3.16.1-alt1: remote: build failed
> 2022-Jan-17 11:29:03 :: [armh] #300 crtools.git 3.16.1-alt1: build FAILED
> 2022-Jan-17 11:29:03 :: [armh] requesting cancellation of task processing
> 2022-Jan-17 11:29:03 :: [armh] build FAILED
> 2022-Jan-17 11:29:03 :: task #291551 for sisyphus FAILED

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-24 18:54:54 +0300, Vladimir D. Seleznev wrote:

 >> [armh] either the file containing the function 'code_syscall'
 >> or the file containing the function '' is not compiled with
 >> -fpic/-fPIC
 >> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found:
 >> 0x00000000
 >> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint
 >> by request
 > А кто знает как такое чинить?

ExclusiveArch: x86_64 aarch64


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey V Turchin]

On Tuesday, 25 January 2022 01:51:57 MSK Alexey V wrote:
> On 2022-01-24 18:54:54 +0300, Vladimir D. Seleznev wrote:
>  >> [armh] either the file containing the function 'code_syscall'
>  >> or the file containing the function '' is not compiled with
>  >> -fpic/-fPIC
>  >> [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found:
>  >> 0x00000000
>  >> [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint
>  >> by request
>  > 
>  > А кто знает как такое чинить?
> 
> ExclusiveArch: x86_64 aarch64
Если бы посмотрели хоть changelog, не писали бы ерунды.

Вообще, лучше не ExclusiveArch, а ExcludeArch, чтоб заранее не ущемлять любые 
другие архитектуры.

-- 
Regards, Sergey.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey V Turchin]

On Monday, 24 January 2022 18:54:54 MSK Vladimir D wrote:
> Hi, devel@!
> 
> On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > 
> > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > 
> >    #300  crtools     1:31  failed     -     1:27      49
> > 
> > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by
> > vseleznv: #100 removed
> > #200 removed
> > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched
> > at 2021-Dec-07 06:54:54 2022-Jan-17 11:27:30 :: #300: force rebuild
> > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build
> > start
> > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build
> > start
> > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> > [armh] either the file containing the function 'code_syscall' or the file
> > containing the function '' is not compiled with -fpic/-fPIC [armh]
> > verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by
> > request
> А кто знает как такое чинить?
Если ключами компилятора не чинится, то отключать ассемблерные вставки, если 
возможно.

> 
> > 2022-Jan-17 11:29:03 :: [armh] crtools.git 3.16.1-alt1: remote: build
> > failed 2022-Jan-17 11:29:03 :: [armh] #300 crtools.git 3.16.1-alt1: build
> > FAILED 2022-Jan-17 11:29:03 :: [armh] requesting cancellation of task
> > processing 2022-Jan-17 11:29:03 :: [armh] build FAILED
> > 2022-Jan-17 11:29:03 :: task #291551 for sisyphus FAILED


-- 
Regards, Sergey.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

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

On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> Hi, devel@!
> 
> On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > 
> > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> >    #300  crtools     1:31  failed     -     1:27      49
> > 
> > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > #100 removed
> > #200 removed
> > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK

У нас по умолчанию GCC генерит position independent code (то есть сборка
неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
к существенному снижению производительности (x86) и/или меняет ABI,
вот как здесь:

> > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> 
> А кто знает как такое чинить?

*По уму* чинить это надо в GCC, а именно: не генерить position independent,
если никто об этом не просил. Хотя бы на тех архитектурах, где это
сильно мешает. Пока GCC не починили (и даже не собираются), придётся вручную
в $CFLAGS передавать `-fno-pic -fno-PIC -fno-pie -fno-PIE`.

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Gleb Fotengauer-Malinovskiy]

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

Hi,

On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > Hi, devel@!
> > 
> > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > 
> > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > >    #300  crtools     1:31  failed     -     1:27      49
> > > 
> > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > #100 removed
> > > #200 removed
> > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> 
> У нас по умолчанию GCC генерит position independent code (то есть сборка
> неявно происходит с -fPIC/-fPIE).

Если вы имеете в виду, что у нас компилятор собран со штатной опцией
--enable-default-pie, то это не у нас, а в апстриме есть такая хорошая
фича, а мы ею просто пользуемся.

-- 
glebfm

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Vladimir D. Seleznev]

On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> Здравствуйте!
> 
> On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > Hi, devel@!
> > 
> > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > 
> > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > >    #300  crtools     1:31  failed     -     1:27      49
> > > 
> > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > #100 removed
> > > #200 removed
> > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> 
> У нас по умолчанию GCC генерит position independent code (то есть сборка
> неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
> к существенному снижению производительности (x86) и/или меняет ABI,
> вот как здесь:
> 
> > > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> > 
> > А кто знает как такое чинить?
> 
> *По уму* чинить это надо в GCC, а именно: не генерить position independent,
> если никто об этом не просил.

Это было намеренно решение, собирать всё с position independent на
уровне репозитория.

> Хотя бы на тех архитектурах, где это сильно мешает. Пока GCC не
> починили (и даже не собираются), придётся вручную в $CFLAGS передавать
> `-fno-pic -fno-PIC -fno-pie -fno-PIE`.

PI же не про производительность, с другой стороны, особой пользы на
32-хбитных архитектурах ввиду несравненно меньшего адресного
пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
выключить PI для них.

-- 
   WBR,
   Vladimir D. Seleznev

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 25.01.2022 19:12, Vladimir D. Seleznev wrote:
> PI же не про производительность, с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> выключить PI для них.

давно пора.

https://git.altlinux.org/gears/r/rpm-build-ocaml.git?p=rpm-build-ocaml.git;a=blob;f=scripts/ocaml;h=2d247e1f2641a49256201a57331b31360015bbd3;hb=cba6db678bdf4d689e1ed93e006285d917af8eca

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

Добрый день!

On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> On Tue, Jan 25, 2022 at 02:52:26PM +0400, Alexey Sheplyakov wrote:
> > Здравствуйте!
> > 
> > On Mon, Jan 24, 2022 at 06:54:54PM +0300, Vladimir D. Seleznev wrote:
> > > Hi, devel@!
> > > 
> > > On Mon, Jan 17, 2022 at 11:29:03AM +0000, Girar awaiter (vseleznv) wrote:
> > > > https://git.altlinux.org/tasks/291551/logs/events.5.1.log
> > > > 
> > > > subtask  name     aarch64    armh  i586  ppc64le  x86_64
> > > >    #300  crtools     1:31  failed     -     1:27      49
> > > > 
> > > > 2022-Jan-17 11:27:29 :: test-only task #291551 for sisyphus resumed by vseleznv:
> > > > #100 removed
> > > > #200 removed
> > > > #300 build 3.16.1-alt1 from /people/vseleznv/packages/crtools.git fetched at 2021-Dec-07 06:54:54
> > > > 2022-Jan-17 11:27:30 :: #300: force rebuild
> > > > 2022-Jan-17 11:27:30 :: [i586] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [x86_64] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [aarch64] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:30 :: [armh] #300 crtools.git 3.16.1-alt1: build start
> > > > 2022-Jan-17 11:27:38 :: [i586] #300 crtools.git 3.16.1-alt1: build SKIPPED
> > > > 2022-Jan-17 11:28:19 :: [x86_64] #300 crtools.git 3.16.1-alt1: build OK
> > > > 2022-Jan-17 11:28:57 :: [ppc64le] #300 crtools.git 3.16.1-alt1: build OK
> > > > 2022-Jan-17 11:29:01 :: [aarch64] #300 crtools.git 3.16.1-alt1: build OK
> > 
> > У нас по умолчанию GCC генерит position independent code (то есть сборка
> > неявно происходит с -fPIC/-fPIE). Даже на тех архитектурах, где это приводит
> > к существенному снижению производительности (x86) и/или меняет ABI,
> > вот как здесь:
> > 
> > > > [armh] either the file containing the function 'code_syscall' or the file containing the function '' is not compiled with -fpic/-fPIC
> > > > [armh] verify-elf: ERROR: ./usr/sbin/criu: TEXTREL entry found: 0x00000000
> > > > [armh] verify-elf: WARNING: ./usr/bin/compel: skipping eu-elflint by request
> > > 
> > > А кто знает как такое чинить?
> > 
> > *По уму* чинить это надо в GCC, а именно: не генерить position independent,
> > если никто об этом не просил.
> 
> Это было намеренно решение, собирать всё с position independent на
> уровне репозитория.

Это плохо обдуманное решение. И обсуждаемый баг - тому подтверждение.

> > Хотя бы на тех архитектурах, где это сильно мешает. Пока GCC не
> > починили (и даже не собираются), придётся вручную в $CFLAGS передавать
> > `-fno-pic -fno-PIC -fno-pie -fno-PIE`.
> 
> PI же не про производительность,

Не скажу про все 32-битные архитектуры, но на x86 и armv{6,7} это именно
что "про производительность" (и "про ABI"), только в плохом смысле слова.

> с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства

Именно. Никакого толку, один только вред.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
[...]
> PI же не про производительность, с другой стороны, особой пользы на
> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> выключить PI для них.

Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Leonid Krivoshein]

29.01.2022 0:30, Dmitry V. Levin пишет:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

От тяжеловесного десктопного 32-бит резонно отказываться, если больше не 
поддерживается апстримом. Если отказываться совсем, тогда ALT остаётся 
только для десктопов и "до свидания IoT, контроллеры и иже с ними".


-- 
Best regards,
Leonid Krivoshein.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 12:58:57AM +0300, Leonid Krivoshein wrote:
> 29.01.2022 0:30, Dmitry V. Levin пишет:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> >> PI же не про производительность, с другой стороны, особой пользы на
> >> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> >> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> >> выключить PI для них.
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> От тяжеловесного десктопного 32-бит резонно отказываться, если больше не 
> поддерживается апстримом. Если отказываться совсем, тогда ALT остаётся 
> только для десктопов и "до свидания IoT, контроллеры и иже с ними".

Для серверов, десктопы тоже отомрут. :)
А для контроллеров вообще универсальные ОС не нужны.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 01:45:28 +0300, Dmitry V. Levin wrote:

 >>>> выключить PI для них.
 >>> Давайте честно скажем, что особой пользы от 32-битных
 >>> архитектур уже нет. Возможно, неплохая мысль выключить
 >>> их в недалёком будущем, скажем, к p11.
 >> От тяжеловесного десктопного 32-бит резонно отказываться,
 >> если больше не поддерживается апстримом. Если отказываться
 >> совсем, тогда ALT остаётся только для десктопов и "до
 >> свидания IoT, контроллеры и иже с ними".
 > Для серверов, десктопы тоже отомрут. :)

Для серверов у нас пока ничего и нет.

 > А для контроллеров вообще универсальные ОС не нужны.

Вот от тебя не ожидал этого заблуждения...


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Yuri Sedunov]

В Сб, 29/01/2022 в 01:45 +0300, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 12:58:57AM +0300, Leonid Krivoshein wrote:
> > 29.01.2022 0:30, Dmitry V. Levin пишет:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
> > > wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой
> > > > пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая
> > > > мысль
> > > > выключить PI для них.
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур
> > > уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем,
> > > скажем, к p11.
> > 
> > От тяжеловесного десктопного 32-бит резонно отказываться, если
> > больше не 
> > поддерживается апстримом. Если отказываться совсем, тогда ALT
> > остаётся 
> > только для десктопов и "до свидания IoT, контроллеры и иже с ними".
> 
> Для серверов, десктопы тоже отомрут. :)
> А для контроллеров вообще универсальные ОС не нужны.
> 
Ну, я так, наблюдающий за 1000+.git, 32-bit по-прежнему актуальны.


-- 
Yuri N. Sedunov

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

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

PIE на 32 битах на самом деле несёт мало пользы и больше вреда
и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
для DSO, сами включат.

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 01:25:42AM +0300, Andrey Savchenko wrote:
> On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> > > PI же не про производительность, с другой стороны, особой пользы на
> > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> По-моему, не очень хорошо, когда разработчики говорят
> пользователям, что они с их железом нам больше не нужны.
> 
> PIE на 32 битах на самом деле несёт мало пользы и больше вреда

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

> и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
> для DSO, сами включат.

PIC вроде нигде по умолчанию и не включается.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 01:43:45 +0300 Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 01:25:42AM +0300, Andrey Savchenko wrote:
> > On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > выключить PI для них.
> > > 
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > 
> > По-моему, не очень хорошо, когда разработчики говорят
> > пользователям, что они с их железом нам больше не нужны.
> > 
> > PIE на 32 битах на самом деле несёт мало пользы и больше вреда
> 
> Меньше пользы в том смысле, что там меньше бит для рандомизации адресов?
> Ну так это один из врождённых недостатков 32-битных архитектур.
> Больше вреда только на калькуляторах-переростках^W^W^W тех архитектурах,
> где мало регистров.

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

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Mikhail Novosyolov]

29.01.2022 01:25, Andrey Savchenko пишет:
> On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>> [...]
>>> PI же не про производительность, с другой стороны, особой пользы на
>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>> выключить PI для них.
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> По-моему, не очень хорошо, когда разработчики говорят
> пользователям, что они с их железом нам больше не нужны.
>
> PIE на 32 битах на самом деле несёт мало пользы и больше вреда
> и лучше не форсировать. С PIC аналогично — те приложения, кому нужно
> для DSO, сами включат.
Мне кажется, заставлять мейнтейнеров разбираться с дополнительным ворохом i586/armhel-специфичных проблем не стоит.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 30.01.2022 03:20, Aleksey Novodvorsky wrote:
>
>
> сб, 29 янв. 2022 г., 01:26 Andrey Savchenko <bircoph@altlinux.org>:
>
>     On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
>     > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
>     wrote:
>     > [...]
>     > > PI же не про производительность, с другой стороны, особой
>     пользы на
>     > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
>     > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>     > > выключить PI для них.
>     >
>     > Давайте честно скажем, что особой пользы от 32-битных архитектур
>     уже нет.
>     > Возможно, неплохая мысль выключить их в недалёком будущем,
>     скажем, к p11.
>
>     По-моему, не очень хорошо, когда разработчики говорят
>     пользователям, что они с их железом нам больше не нужны.
>
>
> Да, но ничто не вечно. Поддержка  p10 завершается 30 июня 2024 года.
>
> Вы полагаете, что этого мало?
>
А это может показать только время - мы не знаем что будет с 32-bit 
системами даже в этом году, не говоря уже про перспективу трёх лет.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Andrey Savchenko]

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

On Sun, 30 Jan 2022 03:20:50 +0300 Aleksey Novodvorsky wrote:
> сб, 29 янв. 2022 г., 01:26 Andrey Savchenko <bircoph@altlinux.org>:
> 
> > On Sat, 29 Jan 2022 00:30:52 +0300 Dmitry V. Levin wrote:
> > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > [...]
> > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > выключить PI для них.
> > >
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> >
> > По-моему, не очень хорошо, когда разработчики говорят
> > пользователям, что они с их железом нам больше не нужны.
> >
> 
> Да, но ничто не вечно. Поддержка  p10 завершается 30 июня 2024 года.
> 
> Вы полагаете, что этого мало?

Точно сказать сложно, но в целом, думаю, что для:

x86: точно мало (steam, wine, атомы)
armv7: сложно сказать, но как я понял, это оборудование ещё производят
mips32: по-видимому, уже не актуально

Best regards,
Andrew Savchenko

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

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

29.01.2022 04:30, Dmitry V. Levin пишет:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 

А что будет с репозиторием x86_64-i586? Его тоже выключим?
Он то ещё долго будет востребован.
А если не выключать, то сборка на i586 будет нужна.

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 09:32:26AM +0700, Антон Мидюков wrote:
> 29.01.2022 04:30, Dmitry V. Levin пишет:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> >> PI же не про производительность, с другой стороны, особой пользы на
> >> 32-хбитных архитектурах ввиду несравненно меньшего адресного
> >> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> >> выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> А что будет с репозиторием x86_64-i586? Его тоже выключим?
> Он то ещё долго будет востребован.

Интересно, почему вы так думаете.


-- 
ldv

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

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

29.01.2022 10:06, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 09:32:26AM +0700, Антон Мидюков wrote:
>> 29.01.2022 04:30, Dmitry V. Levin пишет:
>>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>>> [...]
>>>> PI же не про производительность, с другой стороны, особой пользы на
>>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>>> выключить PI для них.
>>>
>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>
>> А что будет с репозиторием x86_64-i586? Его тоже выключим?
>> Он то ещё долго будет востребован.
> 
> Интересно, почему вы так думаете.
> 

Что он будет востребован?


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:

 >>> выключить PI для них.
 >> Давайте честно скажем, что особой пользы от 32-битных
 >> архитектур уже нет. Возможно, неплохая мысль выключить
 >> их в недалёком будущем, скажем, к p11.
 > А что будет с репозиторием x86_64-i586? Его тоже выключим?

Вообще-то давно пора.

 > Он то ещё долго будет востребован.

Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.

 > А если не выключать, то сборка на i586 будет нужна.

Думаю, от x86_32 можно отказаться в год 20-летия x86_64 :-)


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

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

29.01.2022 16:31, Alexey V. Vissarionov пишет:
> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> 
>  >>> выключить PI для них.
>  >> Давайте честно скажем, что особой пользы от 32-битных
>  >> архитектур уже нет. Возможно, неплохая мысль выключить
>  >> их в недалёком будущем, скажем, к p11.
>  > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> 
> Вообще-то давно пора.
> 
>  > Он то ещё долго будет востребован.
> 
> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> 

Для запуска проприетарщины 32-битной.
Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
Но к p11 это скорее всего исправится.

steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
Правда, может они уже и не заведутся, после выкидывания старых версий gcc...

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> > On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> > 
> >  >>> выключить PI для них.
> >  >> Давайте честно скажем, что особой пользы от 32-битных
> >  >> архитектур уже нет. Возможно, неплохая мысль выключить
> >  >> их в недалёком будущем, скажем, к p11.
> >  > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> > 
> > Вообще-то давно пора.
> > 
> >  > Он то ещё долго будет востребован.
> > 
> > Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> > 
> 
> Для запуска проприетарщины 32-битной.
> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> Но к p11 это скорее всего исправится.
> 
> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...

steam это единственное для чего x86_64-i586 может быть нужен, но и там
нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
mesa и тому подобное.

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 14:29, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
>>>
>>>   >>> выключить PI для них.
>>>   >> Давайте честно скажем, что особой пользы от 32-битных
>>>   >> архитектур уже нет. Возможно, неплохая мысль выключить
>>>   >> их в недалёком будущем, скажем, к p11.
>>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>
>>> Вообще-то давно пора.
>>>
>>>   > Он то ещё долго будет востребован.
>>>
>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>
>> Для запуска проприетарщины 32-битной.
>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>> Но к p11 это скорее всего исправится.
>>
>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> steam это единственное для чего x86_64-i586 может быть нужен, но и там
> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> mesa и тому подобное.
>
не только steam. Весь стек wine

Re: [devel] x86_64-i586

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
> On 29.01.2022 14:29, Alexey Gladkov wrote:
> > On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> >> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> >>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
[...]
> >>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> >>>
> >>> Вообще-то давно пора.
> >>>
> >>>   > Он то ещё долго будет востребован.
> >>>
> >>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> >>>
> >> Для запуска проприетарщины 32-битной.
> >> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> >> Но к p11 это скорее всего исправится.
> >>
> >> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> >> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> > steam это единственное для чего x86_64-i586 может быть нужен, но и там
> > нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> > mesa и тому подобное.
> >
> не только steam. Весь стек wine

Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?

Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
но будут ли они востребованы настолько, чтобы поддерживать для них i586
и x86_64-i586, или для них будет достаточно старых операционных систем
внутри контейнеров и виртуалок?


-- 
ldv

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 14:47, Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>> mesa и тому подобное.
>>
>> не только steam. Весь стек wine
> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
>
> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> и x86_64-i586, или для них будет достаточно старых операционных систем
> внутри контейнеров и виртуалок?
>
>
Думаю что ещё лет 5-10 будет востребовано.

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

Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее 
время.

Весь другой biarch на linux уже фактически не нужен.


Мне кажется, что в этом вопросе нам придётся следовать за Microsoft - 
как только они откажутся от запуска 32-битных приложений в своих 
системах - так сразу можно и нам задуматься об удалении wine32.

Re: [devel] x86_64-i586

[Anton V. Boyarshinov]

В Sat, 29 Jan 2022 14:58:50 +0300
Anton Farygin <rider@basealt.ru> пишет:

> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее 
> время.

Насколько я понимаю, разработчики wine работают в направлении
возможности запуска 32-битных приложений windows из 64-битного wine без
необходимости установки 32b wine библиотек в linux. И существенно
продвинулись в этом направлении.

Re: [devel] x86_64-i586

[Ilya Kurdyukov]

On 31.01.2022 16:24, Anton V. Boyarshinov wrote:
> В Sat, 29 Jan 2022 14:58:50 +0300
> Anton Farygin <rider@basealt.ru> пишет:
>
>> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее
>> время.
> Насколько я понимаю, разработчики wine работают в направлении
> возможности запуска 32-битных приложений windows из 64-битного wine без
> необходимости установки 32b wine библиотек в linux. И существенно
> продвинулись в этом направлении.

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

Re: [devel] x86_64-i586

[Anton V. Boyarshinov]

> >> Т.е. - я бы не расчитывал на то, что wine32 станет не нужным в ближайшее
> >> время.  
> > Насколько я понимаю, разработчики wine работают в направлении
> > возможности запуска 32-битных приложений windows из 64-битного wine без
> > необходимости установки 32b wine библиотек в linux. И существенно
> > продвинулись в этом направлении.  
> 
> Но давайте обойдёмся без такого, что "они еще не закончили, а мы уже 
> удалили". Вот когда они закончат и крупные/известные дистрибутивы 
> перестанут поддерживать запуск 32-бит приложений, тогда уже следовать за 
> ними. Насчёт существенно или не существенно продвинулись - это не имеет 
> никакого значения, главное чтобы они закончили и этобы это стабильно 
> работало и не было лишь экспериментальной фичей, которая работает хуже 
> чем при использовании нормального 32-бит режима.

Так вроде никто не говорит "давайте уберём i586 завтра и полностью".

Re: [devel] x86_64-i586

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

29.01.2022 18:47, Dmitry V. Levin пишет:
> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> [...]
>>>>>   > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>>>
>>>>> Вообще-то давно пора.
>>>>>
>>>>>   > Он то ещё долго будет востребован.
>>>>>
>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>>>
>>>> Для запуска проприетарщины 32-битной.
>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>>>> Но к p11 это скорее всего исправится.
>>>>
>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>>> mesa и тому подобное.
>>>
>> не только steam. Весь стек wine
> 
> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?

Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
Так что все шансы, что за год не переведут есть. И даже за пару лет.

> 
> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> и x86_64-i586, или для них будет достаточно старых операционных систем
> внутри контейнеров и виртуалок?
> 

А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.

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

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 15:02, Антон Мидюков wrote:
> 29.01.2022 18:47, Dmitry V. Levin пишет:
>> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
>>> On 29.01.2022 14:29, Alexey Gladkov wrote:
>>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
>>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
>>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
>> [...]
>>>>>>    > А что будет с репозиторием x86_64-i586? Его тоже выключим?
>>>>>>
>>>>>> Вообще-то давно пора.
>>>>>>
>>>>>>    > Он то ещё долго будет востребован.
>>>>>>
>>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
>>>>>>
>>>>> Для запуска проприетарщины 32-битной.
>>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
>>>>> Но к p11 это скорее всего исправится.
>>>>>
>>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
>>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
>>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
>>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
>>>> mesa и тому подобное.
>>>>
>>> не только steam. Весь стек wine
>> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
> Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
> Так что все шансы, что за год не переведут есть. И даже за пару лет.
>
>> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
>> но будут ли они востребованы настолько, чтобы поддерживать для них i586
>> и x86_64-i586, или для них будет достаточно старых операционных систем
>> внутри контейнеров и виртуалок?
>>
> А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
> Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
> Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.
>
не пару сотен. Точно больше.

Отдельной сборочницы не получится.

Re: [devel] x86_64-i586

[Andrey Savchenko]

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

On Sat, 29 Jan 2022 15:10:56 +0300 Anton Farygin wrote:
> On 29.01.2022 15:02, Антон Мидюков wrote:
> > 29.01.2022 18:47, Dmitry V. Levin пишет:
> >> On Sat, Jan 29, 2022 at 02:34:59PM +0300, Anton Farygin wrote:
> >>> On 29.01.2022 14:29, Alexey Gladkov wrote:
> >>>> On Sat, Jan 29, 2022 at 05:09:39PM +0700, Антон Мидюков wrote:
> >>>>> 29.01.2022 16:31, Alexey V. Vissarionov пишет:
> >>>>>> On 2022-01-29 09:32:26 +0700, Антон Мидюков wrote:
> >> [...]
> >>>>>>    > А что будет с репозиторием x86_64-i586? Его тоже выключим?
> >>>>>>
> >>>>>> Вообще-то давно пора.
> >>>>>>
> >>>>>>    > Он то ещё долго будет востребован.
> >>>>>>
> >>>>>> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
> >>>>>>
> >>>>> Для запуска проприетарщины 32-битной.
> >>>>> Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
> >>>>> Но к p11 это скорее всего исправится.
> >>>>>
> >>>>> steam выкинем? Клиент у них всё ещё 32-битный. Старых игр 32-битных на Linux определённое количество есть.
> >>>>> Правда, может они уже и не заведутся, после выкидывания старых версий gcc...
> >>>> steam это единственное для чего x86_64-i586 может быть нужен, но и там
> >>>> нужны лишь _некоторые_ библиотеки, а не приложения. В основном ему нужны
> >>>> mesa и тому подобное.
> >>>>
> >>> не только steam. Весь стек wine
> >> Интересно, когда "весь стек wine" (не знаю, что это такое) станет 64-битным?
> > Когда все библиотеки переведут в формат PE. В собранном wine-6.22.1 таких библиотек 38.
> > Так что все шансы, что за год не переведут есть. И даже за пару лет.
> >
> >> Понятно, что старые 32-битные приложения навсегда таковыми и останутся,
> >> но будут ли они востребованы настолько, чтобы поддерживать для них i586
> >> и x86_64-i586, или для них будет достаточно старых операционных систем
> >> внутри контейнеров и виртуалок?
> >>
> > А нельзя ли реализовать некоторую мини-сборочницу для сборки для i586 лишь базового минимума?
> > Как максимум - это пара сотен пакетов. Чтобы из них делать репозиторий с минимальным набором библиотек?
> > Может в спеке специальное объявление сделать о сборке для i586? Ну или жёсткий список в самой сборочнице утвердить.
> >
> не пару сотен. Точно больше.
> 
> Отдельной сборочницы не получится.

По-моему, разумнее всего убирать отдельные приложения через
ExcludeArch, если их уже не реально поддерживать. Но сперва нужно
убрать PIE.

Best regards,
Andrew Savchenko

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

Re: [devel] x86_64-i586

[Anton Farygin]

On 29.01.2022 15:28, Andrey Savchenko wrote:
>> не пару сотен. Точно больше.
>>
>> Отдельной сборочницы не получится.
> По-моему, разумнее всего убирать отдельные приложения через
> ExcludeArch, если их уже не реально поддерживать. Но сперва нужно
> убрать PIE.
>
+1

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 17:09:39 +0700, Антон Мидюков wrote:

 >>>>> выключить PI для них.
 >>>> Давайте честно скажем, что особой пользы от 32-битных
 >>>> архитектур уже нет. Возможно, неплохая мысль выключить
 >>>> их в недалёком будущем, скажем, к p11.
 >>> А что будет с репозиторием x86_64-i586? Его тоже выключим?
 >> Вообще-то давно пора.
 >>> Он то ещё долго будет востребован.
 >> Кем и для чего? Если есть x86_64 - там и запускать надо x86_64.
 > Для запуска проприетарщины 32-битной.

Для этого нужны просто i586.

Кстати, именно на i586 они не работают - требуют как минимум i686,
и то не всякий.

 > Ну, и пока что wine всё ещё нуждается в 32-битных библиотеках.
 > Но к p11 это скорее всего исправится.

Насколько я понимаю, там тоже просто i586, а не x86_64-i586.

 > steam выкинем? Клиент у них всё ещё 32-битный. Старых игр
 > 32-битных на Linux определённое количество есть. Правда,
 > может они уже и не заведутся, после выкидывания старых
 > версий gcc...

Как же меня умиляет такая забота от погаМцах, от которых нам
(разработчикам) ни денег, ни уважения... :-)


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 00:30, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
>> PI же не про производительность, с другой стороны, особой пользы на
>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>> выключить PI для них.
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>
biarch на x86_64 пока нужен

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

Я поддерживаю всеми руками!

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Валерий Иноземцев]

[-- Attachment #1.1: Type: text/plain, Size: 982 bytes --]

29.01.2022 14:22, Alexey Gladkov пишет:
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>> [...]
>>> PI же не про производительность, с другой стороны, особой пользы на
>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>> выключить PI для них.
>>
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> 
> Я поддерживаю всеми руками!
> 
+100500

-- 
Valery V. Inozemtsev

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey Y. Afonin]

On Saturday 29 January 2022, Dmitry V. Levin wrote:

> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.

Мне кажется немного рано. Вот к p12 уже может быть.

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Grigory Ustinov]

29.01.2022 15:48, Sergey Y. Afonin пишет:
> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>
>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> Мне кажется немного рано. Вот к p12 уже может быть.
Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 
32битный, он работает и по большому счёту он меня устраивает ровно 
настолько, что 64битный ноутбук я пока не вижу смысла покупать. Возможно 
не всем нужны большие мощности и некоторые люди могут пользоваться 
устаревшей техникой. У одного довольно известного преподавателя курса 
операционных систем вмк мгу это даже стало жизненной позицией, которую я 
поддерживаю и возможно есть и другие пользователи, которые её разделяют 
в той или иной мере.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
> 29.01.2022 15:48, Sergey Y. Afonin пишет:
> > On Saturday 29 January 2022, Dmitry V. Levin wrote:
> > 
> > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > Мне кажется немного рано. Вот к p12 уже может быть.
> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
> он работает и по большому счёту он меня устраивает ровно настолько, что
> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
> одного довольно известного преподавателя курса операционных систем вмк мгу
> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
> другие пользователи, которые её разделяют в той или иной мере.

Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
иллюзий и обид:

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

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

Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
такую поддержку 32-x сборок.

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 16:26, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
>> 29.01.2022 15:48, Sergey Y. Afonin пишет:
>>> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>>>
>>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>> Мне кажется немного рано. Вот к p12 уже может быть.
>> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
>> он работает и по большому счёту он меня устраивает ровно настолько, что
>> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
>> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
>> одного довольно известного преподавателя курса операционных систем вмк мгу
>> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
>> другие пользователи, которые её разделяют в той или иной мере.
> Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
> иллюзий и обид:
>
> Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
> проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
> сборки у меня нет ни возможности ни желания.
>
> Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
> функционал просто выключаю (удивительно как это не стало ещё заметно).
> Потому что актуальные архитектуры не должны страдать от этого легаси.
>
> Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
> такую поддержку 32-x сборок.
>
У меня точно такая же политика - если тест падает на 32-х битах и сходу 
непонятно как чинить, то я его просто выключаю.

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

Но важное замечание заключается в том, что в основном такое происходит с 
разным серверным ПО.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 08:32:32PM +0300, Anton Farygin wrote:
> On 29.01.2022 16:26, Alexey Gladkov wrote:
> > On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
> > > 29.01.2022 15:48, Sergey Y. Afonin пишет:
> > > > On Saturday 29 January 2022, Dmitry V. Levin wrote:
> > > > 
> > > > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > > > Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
> > > > Мне кажется немного рано. Вот к p12 уже может быть.
> > > Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
> > > он работает и по большому счёту он меня устраивает ровно настолько, что
> > > 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
> > > большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
> > > одного довольно известного преподавателя курса операционных систем вмк мгу
> > > это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
> > > другие пользователи, которые её разделяют в той или иной мере.
> > Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
> > иллюзий и обид:
> > 
> > Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
> > проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
> > сборки у меня нет ни возможности ни желания.
> > 
> > Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
> > функционал просто выключаю (удивительно как это не стало ещё заметно).
> > Потому что актуальные архитектуры не должны страдать от этого легаси.
> > 
> > Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
> > такую поддержку 32-x сборок.
> > 
> У меня точно такая же политика - если тест падает на 32-х битах и сходу
> непонятно как чинить, то я его просто выключаю.
> 
> Я думаю что это нормально и если у владельца такой системы возникнет острая
> необходимость починить приложение на 32-х битной архитектуре, то он это
> сделает.
> 
> Но важное замечание заключается в том, что в основном такое происходит с
> разным серверным ПО.

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

Разве что такой подход приведёт к тому что владельцы старого железа скоро
не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
Это наша цель ?

Какой смысл в такой архитектуре для владельца старого, но работающего
ноутбука ?

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 21:12, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 08:32:32PM +0300, Anton Farygin wrote:
>> On 29.01.2022 16:26, Alexey Gladkov wrote:
>>> On Sat, Jan 29, 2022 at 04:01:15PM +0300, Grigory Ustinov wrote:
>>>> 29.01.2022 15:48, Sergey Y. Afonin пишет:
>>>>> On Saturday 29 January 2022, Dmitry V. Levin wrote:
>>>>>
>>>>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>>>>>> Возможно, неплохая мысль выключить их в недалёком будущем, скажем, к p11.
>>>>> Мне кажется немного рано. Вот к p12 уже может быть.
>>>> Я до сих пор в поездках пользуюсь ноутбуком на Intel Atom N270. Он 32битный,
>>>> он работает и по большому счёту он меня устраивает ровно настолько, что
>>>> 64битный ноутбук я пока не вижу смысла покупать. Возможно не всем нужны
>>>> большие мощности и некоторые люди могут пользоваться устаревшей техникой. У
>>>> одного довольно известного преподавателя курса операционных систем вмк мгу
>>>> это даже стало жизненной позицией, которую я поддерживаю и возможно есть и
>>>> другие пользователи, которые её разделяют в той или иной мере.
>>> Я хочу проговорить вслух всем защитникам 32-x архитектур, чтобы не было
>>> иллюзий и обид:
>>>
>>> Для меня эти архитектуры мертвы. У меня давно нет такого железа, чтобы
>>> проверять там сборки и я патчу связанные баги неглядя. Тестировать эти
>>> сборки у меня нет ни возможности ни желания.
>>>
>>> Когда случаются проблемы, которые я не могу сходу запатчить, то проблемный
>>> функционал просто выключаю (удивительно как это не стало ещё заметно).
>>> Потому что актуальные архитектуры не должны страдать от этого легаси.
>>>
>>> Если вас такой уровень поддержки устраивает, то ок, я буду продолжать
>>> такую поддержку 32-x сборок.
>>>
>> У меня точно такая же политика - если тест падает на 32-х битах и сходу
>> непонятно как чинить, то я его просто выключаю.
>>
>> Я думаю что это нормально и если у владельца такой системы возникнет острая
>> необходимость починить приложение на 32-х битной архитектуре, то он это
>> сделает.
>>
>> Но важное замечание заключается в том, что в основном такое происходит с
>> разным серверным ПО.
> Это ничто иное как деградация архитектуры. Формально архитектура есть, но
> пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
>
> Разве что такой подход приведёт к тому что владельцы старого железа скоро
> не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
> Это наша цель ?
>
> Какой смысл в такой архитектуре для владельца старого, но работающего
> ноутбука ?

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

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 09:16:05PM +0300, Anton Farygin wrote:
> > > У меня точно такая же политика - если тест падает на 32-х битах и сходу
> > > непонятно как чинить, то я его просто выключаю.
> > > 
> > > Я думаю что это нормально и если у владельца такой системы возникнет острая
> > > необходимость починить приложение на 32-х битной архитектуре, то он это
> > > сделает.
> > > 
> > > Но важное замечание заключается в том, что в основном такое происходит с
> > > разным серверным ПО.
> > Это ничто иное как деградация архитектуры. Формально архитектура есть, но
> > пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
> > 
> > Разве что такой подход приведёт к тому что владельцы старого железа скоро
> > не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
> > Это наша цель ?
> > 
> > Какой смысл в такой архитектуре для владельца старого, но работающего
> > ноутбука ?
> 
> Конечно деградация архитектуры, но тащить архитектуру за апстрим нам будет
> ой как не просто. С учётом того, что она, в целом, нужна только некоторым
> владельцам 32-х битных платформ.
> 
> Поэтому надо и возложить на тех людей, кто хочет 32-бит вопросы поддержки
> желаемой ими архитектуры. Это нормальная практика, на мой взгляд.

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

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

-- 
Rgrds, legion

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 21:35, Alexey Gladkov wrote:
> On Sat, Jan 29, 2022 at 09:16:05PM +0300, Anton Farygin wrote:
>>>> У меня точно такая же политика - если тест падает на 32-х битах и сходу
>>>> непонятно как чинить, то я его просто выключаю.
>>>>
>>>> Я думаю что это нормально и если у владельца такой системы возникнет острая
>>>> необходимость починить приложение на 32-х битной архитектуре, то он это
>>>> сделает.
>>>>
>>>> Но важное замечание заключается в том, что в основном такое происходит с
>>>> разным серверным ПО.
>>> Это ничто иное как деградация архитектуры. Формально архитектура есть, но
>>> пакеты в ней либо имеют урезанный функционал, либо вообще не работают.
>>>
>>> Разве что такой подход приведёт к тому что владельцы старого железа скоро
>>> не смогут говорить "у меня есть 32-битный ноут и у меня _всё_работает_".
>>> Это наша цель ?
>>>
>>> Какой смысл в такой архитектуре для владельца старого, но работающего
>>> ноутбука ?
>> Конечно деградация архитектуры, но тащить архитектуру за апстрим нам будет
>> ой как не просто. С учётом того, что она, в целом, нужна только некоторым
>> владельцам 32-х битных платформ.
>>
>> Поэтому надо и возложить на тех людей, кто хочет 32-бит вопросы поддержки
>> желаемой ими архитектуры. Это нормальная практика, на мой взгляд.
> Я призываю придумать критерий, когда можно сказать, что архитектура Х
> находится на поддержке по остаточному принципу, и далее архитектура X
> больше поддерживается вообще, потому что нам уже очень сложно.
>
> Иметь эту информацию в явном виде честнее, чем иметь архитектуру X,
> которая мантейнится по принципу "собралось и ладно". Пользователи такой
> "умирающей" архитектуры смогут что-то сделать до её окончательной
> деградации, либо уйти с неё раз она находится в этом статусе.
>
limited support

Ну и расшифровать что это означает.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Sergey Afonin]

On Saturday 29 January 2022, Alexey Gladkov wrote:

> Какой смысл в такой архитектуре для владельца старого, но работающего
> ноутбука ?
 
Смысл в "сейчас", так как оборудование ещё есть. У меня вон сервер
один есть на PII, правда там p9 и я не знаю, буду ли дальше обновлять.
И c каждым годом такого оборудования всё меньше, так что чем позже
будет отказ от архитектуры, тем, всё же, лучше.

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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey Sheplyakov]

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

On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> [...]
> > PI же не про производительность, с другой стороны, особой пользы на
> > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > выключить PI для них.
> 
> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.

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

А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
(а потом, возможно, из вытеснит riscv, тоже 32-битный).

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Denis Medvedev]

В Sat, 29 Jan 2022 19:38:55 +0400
Alexey Sheplyakov <asheplyakov@basealt.ru> пишет:

> Здравствуйте!
> 
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev
> > wrote: [...]
> > > PI же не про производительность, с другой стороны, особой пользы
> > > на 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
А вот если хотите потом такое сертифицировать, то лучше не надо.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур
> > уже нет.
> 
> А давайте немного легче с квантором общности. Возможно, лично Вам
> пользы от 32-битных архитектур и нет (хотя мне кажется, что есть,
> просто Вы её не замечаете).
> 
> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них
> собирают не только одноплатники), и в ближайшие 5 -- 10 лет они
> никуда не исчезнут (а потом, возможно, из вытеснит riscv, тоже
> 32-битный).
+1
Да и 32-битные машины никуда не делись - железо 2000х  весьма
надежно. И иногда имеет смысл даже на
64битную такое ставить чтобы побыстрее работало.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Anton Farygin]

On 29.01.2022 18:50, Denis Medvedev wrote:
>> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них
>> собирают не только одноплатники), и в ближайшие 5 -- 10 лет они
>> никуда не исчезнут (а потом, возможно, из вытеснит riscv, тоже
>> 32-битный).
> +1
> Да и 32-битные машины никуда не делись - железо 2000х  весьма
> надежно. И иногда имеет смысл даже на
> 64битную такое ставить чтобы побыстрее работало.

Денис, ускорение 64-х битных компьютеров за счёт установки на них 
32-битных систем это какой-то миф из детского садика.

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Alexey V. Vissarionov]

On 2022-01-29 18:50:46 +0300, Denis Medvedev wrote:

 >>>> PI же не про производительность, с другой стороны, особой
 >>>> пользы на 32-хбитных архитектурах ввиду несравненно меньшего
 >>>> адресного пространства по сравнению с 64-хбитными. Возможно,
 >>>> неплохая мысль выключить PI для них.
 > А вот если хотите потом такое сертифицировать, то лучше не надо.

Что сертифицировать? x86_32? Отличная шутка, но до 1 апреля еще 2
месяца :-)

 >>> Давайте честно скажем, что особой пользы от 32-битных
 >>> архитектур уже нет.
 >> А давайте немного легче с квантором общности. Возможно, лично
 >> Вам пользы от 32-битных архитектур и нет (хотя мне кажется,
 >> что есть, просто Вы её не замечаете).
 >> А так-то есть вагон и маленькая тележка armv7 процессоров (и
 >> из них собирают не только одноплатники), и в ближайшие 5 -- 10
 >> лет они никуда не исчезнут

ARM32 имеет все шансы пережить писюшатину.

 >> (а потом, возможно, из вытеснит riscv, тоже 32-битный).

А вот это мне пока видится очень маловероятным.

 > +1 Да и 32-битные машины никуда не делись - железо 2000х весьма
 > надежно.

Напомню, что "архитектура" x86_64 появилась в 2003 году - то есть,
она уже справила свое совершеннолетие.

 > И иногда имеет смысл даже на 64битную такое ставить чтобы
 > побыстрее работало.

Опасный миф. Система должна соответствовать железу, и никак иначе.


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

Re: [devel] [#291551] [test-only] FAILED (try 5) crtools.git=3.16.1-alt1

[Dmitry V. Levin]

On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > [...]
> > > PI же не про производительность, с другой стороны, особой пользы на
> > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > выключить PI для них.
> > 
> > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> 
> А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
> архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
> 
> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
> не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
> (а потом, возможно, из вытеснит riscv, тоже 32-битный).

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

Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.

Если нужен только cross toolchain и кастомное ядро, то это один ответ.
А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
то это совсем другой ответ.


-- 
ldv

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 29.01.2022 19:00, Dmitry V. Levin wrote:
> On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
>> On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
>>> On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
>>> [...]
>>>> PI же не про производительность, с другой стороны, особой пользы на
>>>> 32-хбитных архитектурах ввиду несравненно меньшего адресного
>>>> пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
>>>> выключить PI для них.
>>> Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
>> А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
>> архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
>>
>> А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
>> не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
>> (а потом, возможно, из вытеснит riscv, тоже 32-битный).
> Интересно, как вы оцениваете множество задач, которые реально решать на
> таких системах, и множество пакетов в репозитории, которые для этого
> понадобятся.
>
> Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
> ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.
>
> Если нужен только cross toolchain и кастомное ядро, то это один ответ.
> А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
> то это совсем другой ответ.

Кстати было бы неплохо предусмотреть такой white list - что по умолчанию 
собирать на какой-то архитектуре, а что нет.

Но его сопровождение может стать отдельной весьма существенной задачей, 
если сразу не придумать её автоматизацию.

Т.е. - автоматически на сборочнице определять, нужно собирать пакет на 
32-х битных архитектурах или нет исходя, например, из сборочных чрутов 
пакетов, входящих в whitelist.

Re: [devel] subrepository for 32-bit

[Alexey Gladkov]

On Sat, Jan 29, 2022 at 08:41:21PM +0300, Anton Farygin wrote:
> On 29.01.2022 19:00, Dmitry V. Levin wrote:
> > On Sat, Jan 29, 2022 at 07:38:55PM +0400, Alexey Sheplyakov wrote:
> > > On Sat, Jan 29, 2022 at 12:30:52AM +0300, Dmitry V. Levin wrote:
> > > > On Tue, Jan 25, 2022 at 07:12:22PM +0300, Vladimir D. Seleznev wrote:
> > > > [...]
> > > > > PI же не про производительность, с другой стороны, особой пользы на
> > > > > 32-хбитных архитектурах ввиду несравненно меньшего адресного
> > > > > пространства по сравнению с 64-хбитными. Возможно, неплохая мысль
> > > > > выключить PI для них.
> > > > Давайте честно скажем, что особой пользы от 32-битных архитектур уже нет.
> > > А давайте немного легче с квантором общности. Возможно, лично Вам пользы от 32-битных
> > > архитектур и нет (хотя мне кажется, что есть, просто Вы её не замечаете).
> > > 
> > > А так-то есть вагон и маленькая тележка armv7 процессоров (и из них собирают
> > > не только одноплатники), и в ближайшие 5 -- 10 лет они никуда не исчезнут
> > > (а потом, возможно, из вытеснит riscv, тоже 32-битный).
> > Интересно, как вы оцениваете множество задач, которые реально решать на
> > таких системах, и множество пакетов в репозитории, которые для этого
> > понадобятся.
> > 
> > Вопрос же не в том, будут ли эмбеддить armv7 и riscv32, а в том, может
> > ли быть для этого полезен Сизиф, и если да, то в какой форме и объёме.
> > 
> > Если нужен только cross toolchain и кастомное ядро, то это один ответ.
> > А если нужен chromium, firefox, kde, и ещё 17+ тысяч исходных пакетов,
> > то это совсем другой ответ.
> 
> Кстати было бы неплохо предусмотреть такой white list - что по умолчанию
> собирать на какой-то архитектуре, а что нет.
> 
> Но его сопровождение может стать отдельной весьма существенной задачей, если
> сразу не придумать её автоматизацию.
> 
> Т.е. - автоматически на сборочнице определять, нужно собирать пакет на 32-х
> битных архитектурах или нет исходя, например, из сборочных чрутов пакетов,
> входящих в whitelist.

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

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

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

-- 
Rgrds, legion

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

x86 никогда не устареет, но только из-за Wine. Потому что существует 
большое количество старых программ (без исходников), которые 
пользователи хотели бы продолжать эмулировать через Wine.

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

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

On 30.01.2022 01:25, Alexey Gladkov wrote:
>
> На самом деле вопрос стоит ставить шире. Мы тут обсуждаем устаревание и
> последующее выкидывание какой-либо архитектуры. Для любой архитектуры икс
> будут оставаться пользователи, которые будут против остановки
> сопровождения архитектуры икс.
>
> Нужно иметь какой-то протокол, как определить, что затраты на
> сопровождение архитектуры выше от плюсов присутствия сизифа на ней.
>
> Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
> придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
> входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
> может быть собран, то выкидывать окончательно. (Это просто абстрактные
> мысли на тему).
>

Re: [devel] subrepository for 32-bit

[Aleksey Novodvorsky]

вс, 30 янв. 2022 г. в 09:16, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>
> https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html
>
> https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts

Речь про Ubuntu?
1. 20.04 не поддерживает x86, но установить wine можно:
https://wine.htmlvalidator.com/install-wine-on-ubuntu-20.04.html
p10 полностью поддерживает x86/
2. Поддержка  20.04 заканчиватся в первой половине 2025 года.
У p10 -- во второй половине 2024 года. При необходимости можно продлить.
Можно подождать 22.04 LTS и посмотреть, если есть сомнения.

Rgrds, Алексей

>
> On 30.01.2022 11:52, Aleksey Novodvorsky wrote:
>
>
>
> вс, 30 янв. 2022 г., 07:42 Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>>
>> x86 никогда не устареет, но только из-за Wine. Потому что существует
>> большое количество старых программ (без исходников), которые
>> пользователи хотели бы продолжать эмулировать через Wine.
>>
>> Те дистрибутивы что хотели удалить x86 в итоге столкнулись с большим
>> негодованием пользователей и объявили что будут продолжать поддерживать
>> необходимую для работы Wine часть
>
>
> Например,  какие? Хотелось бы посмотреть, какую часть они поддерживают.
>>
>> .
>>
>> А вот другие 32-бит архитектуры могут устареть. Но тоже не скоро, потому
>> что у народа всё еще есть большое количество девайсов на них (типа
>> девелоперских плат), которые вполне можно использовать.
>
>
> Какие, кроме armh?
> На невключение mipsel в p10 жалоб не припомню.
> И "не скоро" это когда?
>
> Rgrds, Алексей
>>
>>
>> On 30.01.2022 01:25, Alexey Gladkov wrote:
>> >
>> > На самом деле вопрос стоит ставить шире. Мы тут обсуждаем устаревание и
>> > последующее выкидывание какой-либо архитектуры. Для любой архитектуры икс
>> > будут оставаться пользователи, которые будут против остановки
>> > сопровождения архитектуры икс.
>> >
>> > Нужно иметь какой-то протокол, как определить, что затраты на
>> > сопровождение архитектуры выше от плюсов присутствия сизифа на ней.
>> >
>> > Возможно, в сборочнице стоит иметь градации поддержки архитектур (я
>> > придумываю на ходу). Для некоторых архитектур можно собирать лишь то что
>> > входит в базой чрут перед их смертью. Когда через ExcludeArch даже чрут не
>> > может быть собран, то выкидывать окончательно. (Это просто абстрактные
>> > мысли на тему).
>> >
>> _______________________________________________
>> Devel mailing list
>> Devel@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/devel
>
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel
>
> _______________________________________________
> Devel mailing list
> Devel@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/devel

Re: [devel] subrepository for 32-bit

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

30.01.2022 13:35, Aleksey Novodvorsky пишет:
> вс, 30 янв. 2022 г. в 09:16, Ilya Kurdyukov <ilyakurdyukov@basealt.ru>:
>>
>> https://www.linuxuprising.com/2019/06/wine-developers-concerned-with-ubuntu.html
>>
>> https://ubuntu.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts
> 
> Речь про Ubuntu?
> 1. 20.04 не поддерживает x86, но установить wine можно:
> https://wine.htmlvalidator.com/install-wine-on-ubuntu-20.04.html

Через подключение Multi-Arch репозитория i386 - аналога нашего x86_64-i586.
В 22.04 они также будут поддерживать Multi-Arch в объёме, требуемом для
wine и steam. Вот и нам бы в таком же объёме и поддерживать x86_64-i586 в p11.

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

Re: [devel] subrepository for 32-bit

[Ilya Kurdyukov]

Моё личное мнение:

1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
смысл в операционной системе которая не может адресовать более 4Гб 
памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.

2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
долго, до тех пор пока в большинстве x86 процессоров не уберут поддержку 
32-бит режима. Тогда уже будем использовать эмуляторы.

3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
девайсов для него (и на многих менее 4Гб памяти, так что размер адреса 
ничем не мешает).

 > На невключение mipsel в p10 жалоб не припомню.

Ну и не должна никого волновать какая-то малораспространённая 
архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
кучу, популярные стоит поддерживать, не популярные не стоит.

Re: [devel] subrepository for 32-bit

[Anton Farygin]

On 30.01.2022 11:05, Ilya Kurdyukov wrote:
> Моё личное мнение:
>
> 1. Поддерживать x86 32-бит дистрибутив нет смысла, потому что какой 
> смысл в операционной системе которая не может адресовать более 4Гб 
> памяти, когда размеры оперативной памяти увеличиваются и увеличиваются.
>
> 2. Но я за поддержку запуска 32-бит приложений на 64-бит системах. 
> Запуск 32-бит кода в Wine точно должен быть поддержан неограниченно 
> долго, до тех пор пока в большинстве x86 процессоров не уберут 
> поддержку 32-бит режима. Тогда уже будем использовать эмуляторы.
>
> 3. 32-бит ARM должен быть поддержан пока в ходу есть много мелких 
> девайсов для него (и на многих менее 4Гб памяти, так что размер адреса 
> ничем не мешает).
>
> > На невключение mipsel в p10 жалоб не припомню.
>
> Ну и не должна никого волновать какая-то малораспространённая 
> архитектура. Просто не надо складывать все 32-бит архитектуры в одну 
> кучу, популярные стоит поддерживать, не популярные не стоит.


Илья всё написал правильно, но вот 32-bit ARM это скорее про бизнес, а 
не про пользователей - я давно уже не слышал о том, что бы кто-то из 
наших разработчиков пытался что-то делать с armv7.

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

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 10:15 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 10:25 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 0:54 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 20:14 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 20:49 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 21:03 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 10:23 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 10:29 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 5:28 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 10:43 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 16:42 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-31 21:55 UTC (permalink / raw)]

Re: [devel] OOM OMG OMG...

[@ 2022-01-31 23:26 UTC (permalink / raw)]

Re: [devel] OOM OMG OMG...

[@ 2022-01-31 23:55 UTC (permalink / raw)]

Re: [devel] OOM OMG OMG...

[@ 2022-02-01 10:58 UTC (permalink / raw)]

Re: [devel] OOM OMG OMG...

[@ 2022-02-01 14:02 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-02-01 12:40 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-01-30 17:32 UTC (permalink / raw)]

Re: [devel] subrepository for 32-bit

[@ 2022-02-08 20:02 UTC (permalink / raw)]