[devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Valery V. Inozemtsev]

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

если так дальше пойдет, я просто положу на все эти пакеты. потом
выковыривать все эти левые коммиты и разглядывать что же там наменяли
мне совершенно не интересно
-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Dmitry V. Levin]

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

On Mon, Feb 28, 2011 at 10:16:49PM +0300, Valery V. Inozemtsev wrote:
> если так дальше пойдет, я просто положу на все эти пакеты. потом
> выковыривать все эти левые коммиты и разглядывать что же там наменяли
> мне совершенно не интересно

git merge не помогает?


-- 
ldv

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

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Valery V. Inozemtsev]

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

В Пнд, 28/02/2011 в 22:25 +0300, Dmitry V. Levin пишет:
> On Mon, Feb 28, 2011 at 10:16:49PM +0300, Valery V. Inozemtsev wrote:
> > если так дальше пойдет, я просто положу на все эти пакеты. потом
> > выковыривать все эти левые коммиты и разглядывать что же там наменяли
> > мне совершенно не интересно
> 
> git merge не помогает?

напрягает. посчитай все libX*

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Dmitry V. Levin]

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

On Mon, Feb 28, 2011 at 10:32:24PM +0300, Valery V. Inozemtsev wrote:
> В Пнд, 28/02/2011 в 22:25 +0300, Dmitry V. Levin пишет:
> > On Mon, Feb 28, 2011 at 10:16:49PM +0300, Valery V. Inozemtsev wrote:
> > > если так дальше пойдет, я просто положу на все эти пакеты. потом
> > > выковыривать все эти левые коммиты и разглядывать что же там наменяли
> > > мне совершенно не интересно
> > 
> > git merge не помогает?
> 
> напрягает. посчитай все libX*

А ты думаешь, что фиксить все эти и многие другие пакеты не напрягает?
Нужно стараться помогать друг другу, у нас ведь не одиночное плавание.


-- 
ldv

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

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Valery V. Inozemtsev]

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

В Пнд, 28/02/2011 в 22:35 +0300, Dmitry V. Levin пишет:
> On Mon, Feb 28, 2011 at 10:32:24PM +0300, Valery V. Inozemtsev wrote:
> > В Пнд, 28/02/2011 в 22:25 +0300, Dmitry V. Levin пишет:
> > > On Mon, Feb 28, 2011 at 10:16:49PM +0300, Valery V. Inozemtsev wrote:
> > > > если так дальше пойдет, я просто положу на все эти пакеты. потом
> > > > выковыривать все эти левые коммиты и разглядывать что же там наменяли
> > > > мне совершенно не интересно
> > > 
> > > git merge не помогает?
> > 
> > напрягает. посчитай все libX*
> 
> А ты думаешь, что фиксить все эти и многие другие пакеты не напрягает?
> Нужно стараться помогать друг другу,

это предпологает как минимум предварительное обсуждение или хотя бы
предупреждение

>  у нас ведь не одиночное плавание.

ДАА?! см. выше

-- 
Valery V. Inozemtsev

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 10:16:49PM +0300, Valery V. Inozemtsev wrote:
> если так дальше пойдет, я просто положу на все эти пакеты. потом
> выковыривать все эти левые коммиты и разглядывать что же там наменяли
> мне совершенно не интересно

Почему "левые", "наменяли" и "не интересно"?
Мне тоже не больше всех надо исправлять эти пакеты.

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

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 10:07:50PM +0200, Michael Shigorin wrote:
> On Mon, Feb 28, 2011 at 10:45:02PM +0300, Valery V. Inozemtsev wrote:
> > > Нужно стараться помогать друг другу,
> > это предпологает как минимум предварительное обсуждение или
> > хотя бы предупреждение
> 
> Вообще-то да.

Я писал в письме про "полчища саранчи", что пересоберу некоторые
пакеты, у которых лишние зависимости из-за pkg-config Requires.private.
libGL-devel относится к таким пакетам, после пересборки получается вот
что:

$ compare_packages -i -a -R /home/at/RPM/RPMS/x86_64/libGL-devel-7.10-alt2.x86_64.rpm
--- /tmp/.private/at/compare_packages.tFx2FZMpHq/1      2011-02-28 22:57:35.065534965 +0300
+++ /tmp/.private/at/compare_packages.tFx2FZMpHq/2      2011-02-28 22:57:35.049536331 +0300
@@ -1,13 +1,5 @@
 /usr/lib64/pkgconfig
-libGL = 7.10-alt2
-pkgconfig(dri2proto) >= 2.1
-pkgconfig(glproto) >= 1.4.11
-pkgconfig(libdrm) >= 2.4.15
-pkgconfig(x11)
-pkgconfig(x11-xcb)
-pkgconfig(xcb-glx)
-pkgconfig(xdamage)
-pkgconfig(xext)
-pkgconfig(xfixes)
-pkgconfig(xxf86vm)
+libGL = 4:7.10-alt2
+libX11-devel
+libdrm-devel
 rpmlib(PayloadIsLzma)

Дополнительно исправлена зависимость на libGL - добавлена Epoch.

> PS: и всё-таки -- возможно ли отфильтровывать где-то *-debuginfo
> в отдельный репозиторий?  Хотели как лучше, но пришлось пока
> повписывать в домашний/ноутбучный rsync ещё по --exclude.

Со временем будет сделана отдельная компонента RPMS.debug, но это не
поможет при синхронизации файлов (если файлы все вместе будут лежать в
files/RPMS, что в принципе предполагается при текущей организации дерева
репозитория).  Поэтому не понятно, как лучше сделать.

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Michael Shigorin]

On Mon, Feb 28, 2011 at 10:45:02PM +0300, Valery V. Inozemtsev wrote:
> > Нужно стараться помогать друг другу,
> это предпологает как минимум предварительное обсуждение или
> хотя бы предупреждение

Вообще-то да.

PS: и всё-таки -- возможно ли отфильтровывать где-то *-debuginfo
в отдельный репозиторий?  Хотели как лучше, но пришлось пока
повписывать в домашний/ноутбучный rsync ещё по --exclude.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 10:28:13PM +0200, Michael Shigorin wrote:
> On Mon, Feb 28, 2011 at 11:02:00PM +0300, Alexey Tourbin wrote:
> > Со временем будет сделана отдельная компонента RPMS.debug, но
> > это не поможет при синхронизации файлов (если файлы все вместе
> > будут лежать в files/RPMS, что в принципе предполагается при
> > текущей организации дерева репозитория).
> 
> Может, обойтись без симлинков или ломка схемы?  Тут-то излишни.

Хочется обойтись без массового перемещения файлов, чтобы не было
взрыва трафика при очередной синхронизации.  Дело осложняется тем,
что я обдумываю возможность миграции i586 -> i686.

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Aleksey Novodvorsky]

28 февраля 2011 г. 23:24 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Mon, Feb 28, 2011 at 10:28:13PM +0200, Michael Shigorin wrote:
>> On Mon, Feb 28, 2011 at 11:02:00PM +0300, Alexey Tourbin wrote:
>> > Со временем будет сделана отдельная компонента RPMS.debug, но
>> > это не поможет при синхронизации файлов (если файлы все вместе
>> > будут лежать в files/RPMS, что в принципе предполагается при
>> > текущей организации дерева репозитория).
>>
>> Может, обойтись без симлинков или ломка схемы?  Тут-то излишни.
>
> Хочется обойтись без массового перемещения файлов, чтобы не было
> взрыва трафика при очередной синхронизации.  Дело осложняется тем,
> что я обдумываю возможность миграции i586 -> i686.

Не сейчас, пожалуйста. Не надо сейчас осложнять.

Rgrds, Алексей

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Michael Shigorin]

On Mon, Feb 28, 2011 at 11:02:00PM +0300, Alexey Tourbin wrote:
> Со временем будет сделана отдельная компонента RPMS.debug, но
> это не поможет при синхронизации файлов (если файлы все вместе
> будут лежать в files/RPMS, что в принципе предполагается при
> текущей организации дерева репозитория).

Может, обойтись без симлинков или ломка схемы?  Тут-то излишни.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Anton Farygin]

28.02.2011 23:24, Alexey Tourbin пишет:
> On Mon, Feb 28, 2011 at 10:28:13PM +0200, Michael Shigorin wrote:
>> On Mon, Feb 28, 2011 at 11:02:00PM +0300, Alexey Tourbin wrote:
>>> Со временем будет сделана отдельная компонента RPMS.debug, но
>>> это не поможет при синхронизации файлов (если файлы все вместе
>>> будут лежать в files/RPMS, что в принципе предполагается при
>>> текущей организации дерева репозитория).
>>
>> Может, обойтись без симлинков или ломка схемы?  Тут-то излишни.
>
> Хочется обойтись без массового перемещения файлов, чтобы не было
> взрыва трафика при очередной синхронизации.  Дело осложняется тем,
> что я обдумываю возможность миграции i586 ->  i686.

А это зачем ?

ты уверен, что на VIA C7 пойдёт i686 код ?

[devel] i586 -> i686

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 11:26:44PM +0300, Aleksey Novodvorsky wrote:
> > Хочется обойтись без массового перемещения файлов, чтобы не было
> > взрыва трафика при очередной синхронизации.  Дело осложняется тем,
> > что я обдумываю возможность миграции i586 -> i686.
> 
> Не сейчас, пожалуйста. Не надо сейчас осложнять.

Если удастся придумать хорошоую схему миграции, то осложнений не будет:
просто в процессе миграции часть файлов останется i586, а часть будет
i686.  В отличие от других причин для массовой пересборки, как то:
set-весрии, debuginfo-пакеты, оптимизация зависимостей между подпакетами,
расчистка pkgconfig-зависимостей, новые зависимости cpp.req и upcoming
python-2.7, для миграции на i686 порядок пересборки пакетов не играет
роли - он может быть любым.

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

[devel] i586 -> i686

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 11:30:48PM +0300, Anton Farygin wrote:
> >Хочется обойтись без массового 
> >перемещения файлов, чтобы не было
> >взрыва трафика при очередной 
> >синхронизации.  Дело осложняется тем,
> >что я обдумываю возможность миграции i586 
> >->  i686.
> 
> А это зачем ?

Чтобы сократить отставание от американского редхата, который мигрировал
с i386 на i686.  С точки зрения кодогенерации прирост производительности
будет минимальным, но этим всё не ограничивается.  С подачи редхата
i686 стал новой generic-платформой.  Например, в glibc
условно-подключаемые функции, оптимизированные для SSE2, есть только
для i686.  Кроме того, в сознании обывателей архитектура i686 примерно
на 17% лучше, чем i586.  Нельзя упускать из виду этот имиджевый эффект.

> ты уверен, что на VIA C7 пойдёт i686 код ?

Надо проверить, если это важно.

[devel] i686 (was: RPMS.debug (was: NMU))

[Michael Shigorin]

On Mon, Feb 28, 2011 at 11:30:48PM +0300, Anton Farygin wrote:
> >Хочется обойтись без массового перемещения файлов, чтобы не было
> >взрыва трафика при очередной синхронизации.  Дело осложняется тем,
> >что я обдумываю возможность миграции i586 ->  i686.
> А это зачем ?

...или i486, если помнишь обсуждение специфики i586
(код для которого быстрее ездит только на самом i586,
но не на i686).

> ты уверен, что на VIA C7 пойдёт i686 код ?

На C3 точно не идёт.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] i586 -> i686

[Aleksey Novodvorsky]

28 февраля 2011 г. 23:51 пользователь Alexey Tourbin <at@altlinux.ru> написал:
> On Mon, Feb 28, 2011 at 11:30:48PM +0300, Anton Farygin wrote:
>> >Хочется обойтись без массового
>> >перемещения файлов, чтобы не было
>> >взрыва трафика при очередной
>> >синхронизации.  Дело осложняется тем,
>> >что я обдумываю возможность миграции i586
>> >->  i686.
>>
>> А это зачем ?
>
> Чтобы сократить отставание от американского редхата, который мигрировал
> с i386 на i686.  С точки зрения кодогенерации прирост производительности
> будет минимальным, но этим всё не ограничивается.  С подачи редхата
> i686 стал новой generic-платформой.  Например, в glibc
> условно-подключаемые функции, оптимизированные для SSE2, есть только
> для i686.  Кроме того, в сознании обывателей архитектура i686 примерно
> на 17% лучше, чем i586.  Нельзя упускать из виду этот имиджевый эффект.

Имиджевый эффект скорее будет обратный. Новое железо -- это x86_64. А
старое в России -- это PI. Потому мы почти ничего не приобретем,
больше потеряем.

Rgrds, Алексей

Re: [devel] i586 -> i686

[Alexey Tourbin]

On Mon, Feb 28, 2011 at 11:56:10PM +0300, Aleksey Novodvorsky wrote:
> > Чтобы сократить отставание от американского редхата, который мигрировал
> > с i386 на i686.  С точки зрения кодогенерации прирост производительности
> > будет минимальным, но этим всё не ограничивается.  С подачи редхата
> > i686 стал новой generic-платформой.  Например, в glibc
> > условно-подключаемые функции, оптимизированные для SSE2, есть только
> > для i686.  Кроме того, в сознании обывателей архитектура i686 примерно
> > на 17% лучше, чем i586.  Нельзя упускать из виду этот имиджевый эффект.
> 
> Имиджевый эффект скорее будет обратный. Новое железо -- это x86_64. А
> старое в России -- это PI. Потому мы почти ничего не приобретем,
> больше потеряем.

Проблемы со старым железом упираются в RAM, а не в CPU.
Типичными конфигурациями были P200 + 32M (i586) и Celeron 300A +
64M (i686).  Минимальные системные требования сейчас - 128M.
Даже если иметь в виду, что умельцам удаётся запустить альт линукс
на 64M, то это всё равно уже i686.

Хотя про обратный имиджевый эффект я не подумал.  С другой стороны,
i686 отмирает не так скоро, как хотелось бы, и ещё долго не отомрёт
на всяких гаджетах - x86_64 жрёт больше памяти.

Re: [devel] unnecessary kde breakage

[Dmitry V. Levin]

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

On Mon, Feb 28, 2011 at 11:26:44PM +0300, Aleksey Novodvorsky wrote:
[...]
> Не сейчас, пожалуйста. Не надо сейчас осложнять.

Что касается "не надо осложнять", то с легкой руки мейтейнера kde* у нас 
сейчас из-за перемещения файлов совершенно напрасно сломалось более 30
kdeшных пакетов.


-- 
ldv

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

Re: [devel] i686

[Dmitry V. Levin]

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

On Mon, Feb 28, 2011 at 11:26:44PM +0300, Aleksey Novodvorsky wrote:
> 28 февраля 2011 г. 23:24 пользователь Alexey Tourbin написал:
[...]
> > Хочется обойтись без массового перемещения файлов, чтобы не было
> > взрыва трафика при очередной синхронизации.  Дело осложняется тем,
> > что я обдумываю возможность миграции i586 -> i686.
> 
> Не сейчас, пожалуйста. Не надо сейчас осложнять.

С i686 только одна неприятная проблема -- слишком много пакетов не
собирается, поэтому первое время все равно будет гибрид.

Вопрос в том, как именно оптимизировать под i686.
В упомянутой рядом Федоре собирают -march=i686 -mtune=atom.
Тут есть над чем подумать.


-- 
ldv

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

Re: [devel] i586 -> i686

[Michael Shigorin]

On Tue, Mar 01, 2011 at 12:03:25AM +0300, Alexey Tourbin wrote:
> Проблемы со старым железом упираются в RAM, а не в CPU.
> Типичными конфигурациями были P200 + 32M (i586) и Celeron 300A
> + 64M (i686).  Минимальные системные требования сейчас - 128M.
> Даже если иметь в виду, что умельцам удаётся запустить альт
> линукс на 64M, то это всё равно уже i686.

Терминальник и на i586/16M работал, причём i486 тоже бы хватило.
Но это решаемо и пересборкой небольшой части пакетов под i[45]86.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] i586 -> i686

[Sergey Y. Afonin]

On Tuesday 01 March 2011, Alexey Tourbin wrote:

> Типичными конфигурациями были P200 + 32M (i586) и Celeron 300A + 64M (i686).

Где-то в это время быстрой птицей промелькнул AMD K6-II. Он, вроде бы,
не i686. А вот 64M там не редкость уже была. Как и NVidia/AGP, например
на материнке Iwill XA100 и прочих похожих. Их продано было, очевидно,
поменьше, чем Intel, но они были. 

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

Re: [devel] i586 -> i686

[Alexey Tourbin]

On Tue, Mar 01, 2011 at 12:49:15AM +0300, Sergey Y. Afonin wrote:
> On Tuesday 01 March 2011, Alexey Tourbin wrote:
> 
> > Типичными конфигурациями были P200 + 32M (i586) и Celeron 300A + 64M (i686).
> 
> Где-то в это время быстрой птицей промелькнул AMD K6-II. Он, вроде бы,
> не i686. А вот 64M там не редкость уже была. Как и NVidia/AGP, например
> на материнке Iwill XA100 и прочих похожих. Их продано было, очевидно,
> поменьше, чем Intel, но они были. 

Да, K6 пролетает, в нём нету cmov.
http://forums.fedoraforum.org/showthread.php?t=249126

С точки зрения кодогенератора cmov - это единственное отличие
между i586 и более старшими архитектурами.  Остальные отличия
уже идут по линии SMID-инструкций (MMX, SSE).

gcc-4*/gcc/config/i386/i386.c:
  1634  /* Feature tests against the various architecture variations, used to create
  1635     ix86_arch_features based on the processor mask.  */
  1636  static unsigned int initial_ix86_arch_features[X86_ARCH_LAST] = {
  1637    /* X86_ARCH_CMOVE: Conditional move was added for pentiumpro.  */
  1638    ~(m_386 | m_486 | m_PENT | m_K6),

Здесь видно, что K6 находится в компании с младшими братьями.

  1639
  1640    /* X86_ARCH_CMPXCHG: Compare and exchange was added for 80486.  */
  1641    ~m_386,
  1642
  1643    /* X86_ARCH_CMPXCHG8B: Compare and exchange 8 bytes was added for pentium. */
  1644    ~(m_386 | m_486),
  1645
  1646    /* X86_ARCH_XADD: Exchange and add was added for 80486.  */
  1647    ~m_386,
  1648
  1649    /* X86_ARCH_BSWAP: Byteswap was added for 80486.  */
  1650    ~m_386,
  1651  };

Re: [devel] i686

[Alexey Tourbin]

On Tue, Mar 01, 2011 at 12:29:02AM +0300, Dmitry V. Levin wrote:
> Вопрос в том, как именно оптимизировать под i686.
> В упомянутой рядом Федоре собирают -march=i686 -mtune=atom.
> Тут есть над чем подумать.

Ссылки в тему
http://fedoraproject.org/wiki/Features/F12X86Support
http://fedoraproject.org/wiki/Talk:Features/F12X86Support
https://www.redhat.com/archives/fedora-devel-list/2009-August/thread.html#00796

Re: [devel] unnecessary kde breakage

[REAL]

01.03.2011 03:26, Dmitry V. Levin пишет:
>> Не сейчас, пожалуйста. Не надо сейчас осложнять.
>
> Что касается "не надо осложнять", то с легкой руки мейтейнера kde* у нас
> сейчас из-за перемещения файлов совершенно напрасно сломалось более 30
> kdeшных пакетов.

Можно список с ACL'ами?

-- 

REAL aka Евгений Ростовцев, программист ЦНИТ КемГУ

Re: [devel] #39547 AWAITING #1 [test-only] sisyphus/at Mesa.git=7.10-alt3

[Sergei Epiphanov]

В сообщении от 28 февраля 2011 23:02:00 автор Alexey Tourbin написал:
> > PS: и всё-таки -- возможно ли отфильтровывать где-то *-debuginfo
> > в отдельный репозиторий?  Хотели как лучше, но пришлось пока
> > повписывать в домашний/ноутбучный rsync ещё по --exclude.
> 
> Со временем будет сделана отдельная компонента RPMS.debug, но это не
> поможет при синхронизации файлов (если файлы все вместе будут лежать в
> files/RPMS, что в принципе предполагается при текущей организации дерева
> репозитория).  Поэтому не понятно, как лучше сделать.

Для начала хотя бы такой шаг, чтобы использовать нормальное обновление через 
интернет или не генерить заново списки файлов при скачивании из сети. Файлы из 
files/.../RPMS можно и отфильтровать при скачивании. Нет ссылок в 
packages.classic - нет проблем с debuginfo.

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

Re: [devel] i586 -> i686

[Anton Farygin]

28.02.2011 23:51, Alexey Tourbin пишет:
> On Mon, Feb 28, 2011 at 11:30:48PM +0300, Anton Farygin wrote:
>>> Хочется обойтись без массового
>>> перемещения файлов, чтобы не было
>>> взрыва трафика при очередной
>>> синхронизации.  Дело осложняется тем,
>>> что я обдумываю возможность миграции i586
>>> ->   i686.
>>
>> А это зачем ?
>
> Чтобы сократить отставание от американского редхата, который мигрировал
> с i386 на i686.  С точки зрения кодогенерации прирост производительности
> будет минимальным, но этим всё не ограничивается.  С подачи редхата
> i686 стал новой generic-платформой.  Например, в glibc
> условно-подключаемые функции, оптимизированные для SSE2, есть только
> для i686.  Кроме того, в сознании обывателей архитектура i686 примерно
> на 17% лучше, чем i586.  Нельзя упускать из виду этот имиджевый эффект.

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

>
>> ты уверен, что на VIA C7 пойдёт i686 код ?
>
> Надо проверить, если это важно.

Важно не устроить регрессий.

Решения на VIA были очень популярны в школах.

Re: [devel] unnecessary kde breakage

[Dmitry V. Levin]

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

On Tue, Mar 01, 2011 at 12:56:36PM +0600, REAL wrote:
> 01.03.2011 03:26, Dmitry V. Levin пишет:
> >>Не сейчас, пожалуйста. Не надо сейчас 
> >>осложнять.
> >
> >Что касается "не надо осложнять", то с 
> >легкой руки мейтейнера kde* у нас
> >сейчас из-за перемещения файлов 
> >совершенно напрасно сломалось более 30
> >kdeшных пакетов.
> 
> Можно список с ACL'ами?

По результатам следующей пересборки робот включит их в свой отчет автоматически.


-- 
ldv

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

Re: [devel] i586 -> i686

[Dmitry V. Levin]

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

On Tue, Mar 01, 2011 at 11:25:36AM +0300, Anton Farygin wrote:
[...]
> Тараканы в сознании обывателей не имеют никакого значения,

Отчего же, очень даже имеют.  Порой они являются движущей силой.

> а оптимизация сейчас прекрасно работает на x86_64.

Если не переехать на i686, то даже в 32-битной контейнерах на x86_64
нормальной оптимизации не будет.


-- 
ldv

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

Re: [devel] i586 -> i686

[Anton Farygin]

01.03.2011 13:21, Dmitry V. Levin пишет:
> On Tue, Mar 01, 2011 at 11:25:36AM +0300, Anton Farygin wrote:
> [...]
>> Тараканы в сознании обывателей не имеют никакого значения,
>
> Отчего же, очень даже имеют.  Порой они являются движущей силой.

Главное что бы эти тараканы проблем не создавали. а так пускай живут, 
плодятся...

>
>> а оптимизация сейчас прекрасно работает на x86_64.
>
> Если не переехать на i686, то даже в 32-битной контейнерах на x86_64
> нормальной оптимизации не будет.

Конечно не будет, а зачем нужны i586 контейнеры ?

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

Через какое-то время i586 будет востребован только на сотовых телефонах, 
планшетках и ... и всё.

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

Re: [devel] i586 -> i686

[Alexey Tourbin]

On Tue, Mar 01, 2011 at 01:28:57PM +0300, Anton Farygin wrote:
> >Если не переехать на i686, то даже в 
> >32-битной контейнерах на x86_64
> >нормальной оптимизации не будет.
> 
> Конечно не будет, а зачем нужны i586 
> контейнеры ?

Для сборки i586 пакетов.-)

> i586 нужен как правило только на десктопах, 
> да и то с каждым днём количество новых 
> систем для i586 стремительно падает.

Нет, i586 отмирает очень медленно.  Некоторые дистрибутивы альт линукс
выпускает только для i586 - simply, school - при том, что процессоры
x86_64 выпускаются с 2003 года, т.е. больше семи лет.  На стремительное
падение это не похоже, картина более сложная.

> Через какое-то время i586 будет 
> востребован только на сотовых телефонах, 
> планшетках и ... и всё.
> 
> Да и то, думаю, что это время быстро 
> проскочим... как только какому-то 
> маркетоиду придёт в голову восхвалить 
> очередное достижение Intel - сотовый 
> телефон с набором инструкций x86_64, 
> который позволяет ещё быстрее и 
> качественнее общаться с окружающим 
> миром ;)

Re: [devel] i586 -> i686

[Anton Farygin]

01.03.2011 16:55, Alexey Tourbin пишет:


>
>> i586 нужен как правило только на десктопах,
>> да и то с каждым днём количество новых
>> систем для i586 стремительно падает.
>
> Нет, i586 отмирает очень медленно.  Некоторые дистрибутивы альт линукс
> выпускает только для i586 - simply, school - при том, что процессоры
> x86_64 выпускаются с 2003 года, т.е. больше семи лет.  На стремительное
> падение это не похоже, картина более сложная.

Правильно, я вот тоже не перехожу на x86_64, хотя мог бы - причина 
простая - нет качественной реализации biarch, а под x86_64 не работает 
(не работал) flash, который нужен для ряда систем управления серверами. 
Да и с wine есть заморочки.

Т.е. - гораздо выгоднее с точки зрения новых систем предложить x86_64 и 
удобный biarch, чем перезжать на i686.

Обновив на i686 ты как раз закроешь дорогу таким дистрибутивам как 
school и simply - расчитанным на старое железо, на очень старое, на 
котором чисто теоретически i686 может и не заработать.

Re: [devel] i686

[Ivan A. Melnikov]

On Tue, 1 Mar 2011 00:29:02 +0300
"Dmitry V. Levin" <ldv@altlinux.org> wrote:
> 
> Вопрос в том, как именно оптимизировать под i686.
> В упомянутой рядом Федоре собирают -march=i686 -mtune=atom.
> Тут есть над чем подумать.
> 

Мне отчего-то кажется, что интереснее не переезжать с i586 на i686, а
добавить ещё одну архитектуру -- i686, причём сразу с sse2 (сначала в
Федоре, насколько я понимаю, хотели добавить sse2 в минимальные
требования). Интереснее и имиджево, и технически. Конечно, это добавляет
вопросы о ресурсах сборочницы, зеркал и т.п., а также целесообразности
поддержки двух очень похожих архитектур.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] i686g

[Kirill A. Shutemov]

On Tue, Mar 01, 2011 at 09:17:09PM +0300, Ivan A. Melnikov wrote:
> On Tue, 1 Mar 2011 00:29:02 +0300
> "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> > 
> > Вопрос в том, как именно оптимизировать под i686.
> > В упомянутой рядом Федоре собирают -march=i686 -mtune=atom.
> > Тут есть над чем подумать.
> > 
> 
> Мне отчего-то кажется, что интереснее не переезжать с i586 на i686, а
> добавить ещё одну архитектуру -- i686, причём сразу с sse2 (сначала в
> Федоре, насколько я понимаю, хотели добавить sse2 в минимальные
> требования). Интереснее и имиджево, и технически. Конечно, это добавляет
> вопросы о ресурсах сборочницы, зеркал и т.п., а также целесообразности
> поддержки двух очень похожих архитектур.

Интересней -- x32.

https://sites.google.com/site/x32abi/

Правда, там ещё совсем не хожено.

-- 
 Kirill A. Shutemov

Re: [devel] i686g

[Ivan A. Melnikov]

On Tue, 1 Mar 2011 20:22:00 +0200
"Kirill A. Shutemov" <kirill@shutemov.name> wrote:
>
> Интересней -- x32.
> 
> https://sites.google.com/site/x32abi/
> 
> Правда, там ещё совсем не хожено.
>

Если оно работает, то да.

-- 
WBR,
Ivan A. Melnikov

Re: [devel] i686

[Dmitry V. Levin]

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

On Tue, Mar 01, 2011 at 08:22:00PM +0200, Kirill A. Shutemov wrote:
> On Tue, Mar 01, 2011 at 09:17:09PM +0300, Ivan A. Melnikov wrote:
> > On Tue, 1 Mar 2011 00:29:02 +0300, Dmitry V. Levin wrote:
> > > 
> > > Вопрос в том, как именно оптимизировать под i686.
> > > В упомянутой рядом Федоре собирают -march=i686 -mtune=atom.
> > > Тут есть над чем подумать.
> > 
> > Мне отчего-то кажется, что интереснее не переезжать с i586 на i686, а
> > добавить ещё одну архитектуру -- i686, причём сразу с sse2 (сначала в
> > Федоре, насколько я понимаю, хотели добавить sse2 в минимальные
> > требования). Интереснее и имиджево, и технически. Конечно, это добавляет
> > вопросы о ресурсах сборочницы, зеркал и т.п., а также целесообразности
> > поддержки двух очень похожих архитектур.
> 
> Интересней -- x32.
> 
> https://sites.google.com/site/x32abi/
> 
> Правда, там ещё совсем не хожено.

Если вопрос только в интересе, то нехоженность x32, несомненно,
увеличивает интерес.  :)


-- 
ldv

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

Re: [devel] i586 -> i686

[Alexey Tourbin]

On Tue, Mar 01, 2011 at 11:25:36AM +0300, Anton Farygin wrote:
> Тараканы в сознании обывателей не имеют 
> никакого значения, а оптимизация сейчас 
> прекрасно работает на x86_64. Тащить же 
> медленно умирающий i586 в данный момент не 
> имеет никакого смысла, пока Intel не 
> вдохнёт в эту архитектуру новую жизнь в 
> виде какой-то особо популярной платформы 
> для планшеток.

http://smolt.fedoraproject.org/static/stats/stats.html

The overall picture is clear: 32-bit x86 is still the dominant
architecture in use in Fedora.  We shouldn't break high volume 32-bit
chips in Fedora, nor should we stop optimizing for 32-bit systems.
https://bugzilla.redhat.com/show_bug.cgi?id=579838

> >>ты уверен, что на VIA C7 пойдёт i686 код ?
> >
> >Надо проверить, если это важно.
> Важно не устроить регрессий.

Важно разобраться, какое именно железо стоит на кону.

> Решения на VIA были очень популярны в 
> школах.

VIA C7 и VIA C3-2 работать будут, более ранние VIA C3 - не будут.

[devel] i686: CPUs at stake

[Alexey Tourbin]

On Wed, Mar 02, 2011 at 03:52:16AM +0300, Alexey Tourbin wrote:
> Важно разобраться, какое именно железо стоит на кону.

Nick Lowe	2011-02-16
https://bugzilla.redhat.com/show_bug.cgi?id=579838#c46

Now that binutils has been fixed, i686 is a sane baseline for a 32-bit build.
In my view, the entire 32-bit build of FC15 should be targeted for i686 with
-march=i686 with a fixed version of binutils (GAS) that does not make bad
assumption over the presence of NOPL.

As far as compatibility impact of compiling for i686, which need to be
understood and digested:

VIA Edens based on the 'Samuel 2' design do not support CMOV or NOPL. (These
would break.)
All VIA Edens based on the 'Nehemiah' design support CMOV but not NOPL.
(Introduced in 2003. These would not break.)

Via C3s based on the 'Samuel 2'or 'Ezra'/'Ezra-T' design do not support CMOV or
NOPL. (These would break.)
All C3s based on the 'Nehemiah' design support CMOV but not NOPL. (Introduced
in 2003. These would not break.)

National Semi's GXm, GXLV and GX1 do not support CMOV or NOPL. (These would
break.)
All Geodes since and including National Semi's GX2 support CMOV but not NOPL.
(Introduced in 2002. These would not break.)
The AMD branded Geodes (GX and LX) support CMOV but not NOPL. (These would not
break.)

The Cyrix 6x86 processors do not support CMOV or NOPL. (These would break.)
The Cyrix 8x86MX / Cyrix MII do support CMOV but not NOPL. (These would not
break.)

The AMD K6 and K6-2 do not support CMOV or NOPL. (These would break.)

Re: [devel] i686: CPUs at stake

[Anton Farygin]

02.03.2011 04:12, Alexey Tourbin пишет:
> On Wed, Mar 02, 2011 at 03:52:16AM +0300, Alexey Tourbin wrote:
>> Важно разобраться, какое именно железо стоит на кону.
>
> Nick Lowe	2011-02-16
> https://bugzilla.redhat.com/show_bug.cgi?id=579838#c46

<skip>

Понятно, не надо нам такого пока.

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

Re: [devel] i586 -> i686

[Michael Shigorin]

On Mon, Feb 28, 2011 at 11:38:42PM +0300, Alexey Tourbin wrote:
> > > Хочется обойтись без массового перемещения файлов, чтобы не
> > > было взрыва трафика при очередной синхронизации.  Дело
> > > осложняется тем, что я обдумываю возможность миграции i586
> > > -> i686.
> > Не сейчас, пожалуйста. Не надо сейчас осложнять.
> Если удастся придумать хорошоую схему миграции, то осложнений не будет:

И ещё до кучи:
http://old.nabble.com/i686-quirk-for-AMD-Geode-td25725094i40.html
http://linux.derkeiler.com/Mailing-Lists/Kernel/2009-11/msg04336.html
(via led@)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] i686: CPUs at stake

[Alexey Tourbin]

On Wed, Mar 02, 2011 at 11:51:55AM +0300, Anton Farygin wrote:
> 02.03.2011 04:12, Alexey Tourbin пишет:
> >On Wed, Mar 02, 2011 at 03:52:16AM +0300, Alexey Tourbin wrote:
> >>Важно разобраться, какое именно железо 
> >>стоит на кону.
> >
> >Nick Lowe	2011-02-16
> >https://bugzilla.redhat.com/show_bug.cgi?id=579838#c46
> 
> <skip>
> 
> Понятно, не надо нам такого пока.
> 
> Я думаю, что в данном случае лучше 
> подождать пока апстрим по всем минам с 
> пользователями пройдёт...

Какими "минами"?  Это FUD.
Есть точный список поддерживаемх и неподдерживаемых CPU.

Re: [devel] i686: CPUs at stake

[Anton Farygin]

02.03.2011 17:11, Alexey Tourbin пишет:
> On Wed, Mar 02, 2011 at 11:51:55AM +0300, Anton Farygin wrote:
>> 02.03.2011 04:12, Alexey Tourbin пишет:
>>> On Wed, Mar 02, 2011 at 03:52:16AM +0300, Alexey Tourbin wrote:
>>>> Важно разобраться, какое именно железо
>>>> стоит на кону.
>>>
>>> Nick Lowe	2011-02-16
>>> https://bugzilla.redhat.com/show_bug.cgi?id=579838#c46
>>
>> <skip>
>>
>> Понятно, не надо нам такого пока.
>>
>> Я думаю, что в данном случае лучше
>> подождать пока апстрим по всем минам с
>> пользователями пройдёт...
>
> Какими "минами"?  Это FUD.
> Есть точный список поддерживаемх и неподдерживаемых CPU.

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

Т.е. - каким процентом пользователей системы мы готовы пожертвовать ради 
того, что бы была галочка про оптимизацию под i686.

Re: [devel] i686: CPUs at stake

[Alexey Tourbin]

On Wed, Mar 02, 2011 at 05:24:22PM +0300, Anton Farygin wrote:
> 02.03.2011 17:11, Alexey Tourbin пишет:
> >On Wed, Mar 02, 2011 at 11:51:55AM +0300, Anton Farygin wrote:
> >>Я думаю, что в данном случае лучше
> >>подождать пока апстрим по всем минам с
> >>пользователями пройдёт...
> >
> >Какими "минами"?  Это FUD.
> >Есть точный список поддерживаемх и 
> >неподдерживаемых CPU.
> 
> Проблема не со списком, а с тем, в каких 
> пропорциях распространёно железо из 
> этого списка у наших пользователей 
> (текущих и потенциальных).
> 
> Т.е. - каким процентом пользователей 
> системы мы готовы пожертвовать ради 
> того, что бы была галочка про оптимизацию 
> под i686.

Из старых машин мы лишаемся конфигураций типа k6-2 350Mhz 128RAM.
Такие конфигурации выпускались более 10 лет назад.

Из чуть более новых машин (2002) мы лишаемся конфигураций на основе
ранних моделей VIA C3 (последующие VIA C3-2 будут работать).  Но это
уже более экзотические конфигурации, "писюков" таких не было.

Сколько это процентов пользователей я конечно не знаю.

Re: [devel] i686: CPUs at stake

[Sergey Y. Afonin]

On Wednesday, March 02, 2011, Alexey Tourbin wrote:

> Из чуть более новых машин (2002) мы лишаемся конфигураций
> на основе ранних моделей VIA C3 (последующие VIA C3-2 будут
> работать).  Но это уже более экзотические конфигурации,
> "писюков" таких не было.
> 
> Сколько это процентов пользователей я конечно не знаю.

Может опрос на forum.altlinux.ru устроить для имеющихся там
представителей школ ? Хоть какое-то подобие адекватного результата
может получиться. Не в школах если, то вряд ли оно живо где-то.

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

Re: [devel] i686: CPUs at stake

[Андрей Черепанов]

[-- Attachment #1: Type: Text/Plain, Size: 695 bytes --]

2 марта 2011 Sergey Y. Afonin написал:
> On Wednesday, March 02, 2011, Alexey Tourbin wrote:
> > Из чуть более новых машин (2002) мы лишаемся конфигураций
> > на основе ранних моделей VIA C3 (последующие VIA C3-2 будут
> > работать).  Но это уже более экзотические конфигурации,
> > "писюков" таких не было.
> > 
> > Сколько это процентов пользователей я конечно не знаю.
> 
> Может опрос на forum.altlinux.ru
forum.altlinux.org (это не ресурс ООО)

> устроить для имеющихся там
> представителей школ ? Хоть какое-то подобие адекватного результата
> может получиться. Не в школах если, то вряд ли оно живо где-то.
Там реально очень мало учителей.

-- 
Андрей Черепанов
ALT Linux
cas@altlinux.ru

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] i686: CPUs at stake

[Michael Shigorin]

On Wed, Mar 02, 2011 at 06:18:11PM +0300, Alexey Tourbin wrote:
> Из старых машин мы лишаемся конфигураций типа k6-2 350Mhz 128RAM.
> Такие конфигурации выпускались более 10 лет назад.

Вполне живучие машинки, на химфаке такие были.

> Из чуть более новых машин (2002) мы лишаемся конфигураций на
> основе ранних моделей VIA C3 (последующие VIA C3-2 будут
> работать).  Но это уже более экзотические конфигурации,
> "писюков" таких не было.

Были-были, куча тонких клиентов ниже двухсот баксов.

Но CMOV как раз можно эмулировать.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] i686: CPUs at stake

[Alexey Tourbin]

On Thu, Mar 03, 2011 at 08:33:33PM +0200, Michael Shigorin wrote:
> On Wed, Mar 02, 2011 at 06:18:11PM +0300, Alexey Tourbin wrote:
> > Из старых машин мы лишаемся конфигураций типа k6-2 350Mhz 128RAM.
> > Такие конфигурации выпускались более 10 лет назад.
> 
> Вполне живучие машинки, на химфаке такие были.

Смена базовой архитектуры репозитория с i586 на i686 - это часть
модернизации, заповеданной президентом Медведевым.  А а кто против
модернизации, того надо кастрировать.  Как Пьера Абеляра.

> > Из чуть более новых машин (2002) мы лишаемся конфигураций на
> > основе ранних моделей VIA C3 (последующие VIA C3-2 будут
> > работать).  Но это уже более экзотические конфигурации,
> > "писюков" таких не было.
> 
> Были-были, куча тонких клиентов ниже двухсот баксов.
> 
> Но CMOV как раз можно эмулировать.

Прежде чем эмулировать надо решительно кастрировать.