[devel] mplayer q

[devel] mplayer q

[Sergey Bolshakov]

$ rpm -q mplayer 
mplayer-1.0-alt35.25029.1
$ ldd -r /usr/bin/mplayer |grep directfb
libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)

Можно эту феерию прекратить ?

-- 

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Sun, Nov 18, 2007 at 01:10:15AM +0300, Sergey Bolshakov wrote:
> $ rpm -q mplayer 
> mplayer-1.0-alt35.25029.1
> $ ldd -r /usr/bin/mplayer |grep directfb
> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> 
> Можно эту феерию прекратить ?

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

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

Re: [devel] mplayer q

[Dmitry V. Levin]

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

On Sun, Nov 18, 2007 at 01:15:17AM +0300, Alexey Tourbin wrote:
> On Sun, Nov 18, 2007 at 01:10:15AM +0300, Sergey Bolshakov wrote:
> > $ rpm -q mplayer 
> > mplayer-1.0-alt35.25029.1
> > $ ldd -r /usr/bin/mplayer |grep directfb
> > libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > 
> > Можно эту феерию прекратить ?
> 
> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> причине -- если в адресном пространстве процесса окажется две библиотеки
> разных версий, то это скорее всего как минимум не будет работать.

Очень интересно, как эта феерия работает?


-- 
ldv

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Sun, Nov 18, 2007 at 01:25:51AM +0300, Dmitry V. Levin wrote:
> On Sun, Nov 18, 2007 at 01:15:17AM +0300, Alexey Tourbin wrote:
> > On Sun, Nov 18, 2007 at 01:10:15AM +0300, Sergey Bolshakov wrote:
> > > $ rpm -q mplayer 
> > > mplayer-1.0-alt35.25029.1
> > > $ ldd -r /usr/bin/mplayer |grep directfb
> > > libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > > libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > > 
> > > Можно эту феерию прекратить ?
> > 
> > А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > причине -- если в адресном пространстве процесса окажется две библиотеки
> > разных версий, то это скорее всего как минимум не будет работать.
> 
> Очень интересно, как эта феерия работает?

Кажется libcairo слинкован со старой библиотекой libdirectfb, а libcairo
транзитивно вытягивается через gtk.  А сам mplayer слинкован с новой
версией libdirectfb.

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

Re: [devel] mplayer q

[led]

Sunday, 18 November 2007 00:37:54 Alexey Tourbin написав:
> On Sun, Nov 18, 2007 at 01:25:51AM +0300, Dmitry V. Levin wrote:
> > On Sun, Nov 18, 2007 at 01:15:17AM +0300, Alexey Tourbin wrote:
> > > On Sun, Nov 18, 2007 at 01:10:15AM +0300, Sergey Bolshakov wrote:
> > > > $ rpm -q mplayer
> > > > mplayer-1.0-alt35.25029.1
> > > > $ ldd -r /usr/bin/mplayer |grep directfb
> > > > libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > > > libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > > >
> > > > Можно эту феерию прекратить ?
> > >
> > > А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > > Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > > причине -- если в адресном пространстве процесса окажется две
> > > библиотеки разных версий, то это скорее всего как минимум не будет
> > > работать.
> >
> > Очень интересно, как эта феерия работает?
>
> Кажется libcairo слинкован со старой библиотекой libdirectfb, а libcairo
> транзитивно вытягивается через gtk.  А сам mplayer слинкован с новой
> версией libdirectfb.

Обычная пересборка libcairo решает проблему.

___
Led.

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Sun, Nov 18, 2007 at 01:25:51AM +0300, Dmitry V. Levin wrote:
> > А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > причине -- если в адресном пространстве процесса окажется две библиотеки
> > разных версий, то это скорее всего как минимум не будет работать.
> 
> Очень интересно, как эта феерия работает?

То есть может статься, что она и работает -- до тех пор, пока дело
не доходит до directfb.

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

Re: [devel] mplayer q

[Dmitry V. Levin]

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

On Sun, Nov 18, 2007 at 01:25:51AM +0300, Dmitry V. Levin wrote:
> On Sun, Nov 18, 2007 at 01:15:17AM +0300, Alexey Tourbin wrote:
> > On Sun, Nov 18, 2007 at 01:10:15AM +0300, Sergey Bolshakov wrote:
> > > $ rpm -q mplayer 
> > > mplayer-1.0-alt35.25029.1
> > > $ ldd -r /usr/bin/mplayer |grep directfb
> > > libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > > libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > > 
> > > Можно эту феерию прекратить ?
> > 
> > А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > причине -- если в адресном пространстве процесса окажется две библиотеки
> > разных версий, то это скорее всего как минимум не будет работать.
> 
> Очень интересно, как эта феерия работает?

Повторяю свой вопрос:
Как работает mplayer по состоянию Сизифа "на сейчас"?


-- 
ldv

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 02:46:26PM +0300, Dmitry V. Levin wrote:
> Повторяю свой вопрос:
> Как работает mplayer по состоянию Сизифа "на сейчас"?

В иксах mplayer работает (по крайней мере mms:// музыку играет).  Когда
я попробовал запустить "mplayer -vo directfb /..." то у меня всё зависло
(vga=0x0317, потом просто переключился в иксы по C-A-F7 и оно
"отвисло").  Но я не знаю, работало ли это когда-нибудь вообще, и всё ли
потребное я сделал для запуска mplayer'а в режиме directfb.  У меня
проприетарный nvidia драйвер в иксах.

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

Re: [devel] mplayer q

[ruslandh]

В сообщении от Tuesday 20 November 2007 14:52:45 Alexey Tourbin написал(а):
> On Tue, Nov 20, 2007 at 02:46:26PM +0300, Dmitry V. Levin wrote:
> > Повторяю свой вопрос:
> > Как работает mplayer по состоянию Сизифа "на сейчас"?
>
> В иксах mplayer работает (по крайней мере mms:// музыку играет).  Когда
> я попробовал запустить "mplayer -vo directfb /..." то у меня всё зависло
> (vga=0x0317, потом просто переключился в иксы по C-A-F7 и оно
> "отвисло").  Но я не знаю, работало ли это когда-нибудь вообще, и всё ли
> потребное я сделал для запуска mplayer'а в режиме directfb.  У меня
> проприетарный nvidia драйвер в иксах.

Кстати :

MPlayer dev-SVN-r25029-4.1.1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) D CPU 3.40GHz (Family: 15, Model: 6, Stepping: 4)
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
116 audio & 240 video codecs

Playing s6300725.avi.

AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO:  [MJPG]  640x480  24bpp  30,000 fps  9328,3 kbps (1138,7 kbyte/s)

     =======================|  DirectFB 1.1.0  |=======================
          (c) 2001-2007  The DirectFB Organization (directfb.org)
          (c) 2000-2004  Convergence (integrated media) GmbH
        ------------------------------------------------------------

(*) DirectFB/Core: Single Application Core. (2007-10-15 08:36) 
(!) DirectFB/core/vt: Error opening `/dev/tty0'!
    --> Отказано в доступе
(!) DirectFB/Core: Could not initialize 'system_core' core!
    --> Initialization error!
vo_directfb2.c <275>:
	(#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error!

Но, как я понимаю, это уже смежный вопрос.

-- 
С Уважением Хихин Руслан.

Re: [devel] mplayer q

[led]

Tuesday, 20 November 2007 17:35:31 ruslandh написав:
> В сообщении от Tuesday 20 November 2007 14:52:45 Alexey Tourbin написал(а):
> > On Tue, Nov 20, 2007 at 02:46:26PM +0300, Dmitry V. Levin wrote:
> > > Повторяю свой вопрос:
> > > Как работает mplayer по состоянию Сизифа "на сейчас"?
> >
> > В иксах mplayer работает (по крайней мере mms:// музыку играет).  Когда
> > я попробовал запустить "mplayer -vo directfb /..." то у меня всё зависло
> > (vga=0x0317, потом просто переключился в иксы по C-A-F7 и оно
> > "отвисло").  Но я не знаю, работало ли это когда-нибудь вообще, и всё ли
> > потребное я сделал для запуска mplayer'а в режиме directfb.  У меня
> > проприетарный nvidia драйвер в иксах.
>
> Кстати :
>
> MPlayer dev-SVN-r25029-4.1.1 (C) 2000-2007 MPlayer Team
> CPU: Intel(R) Pentium(R) D CPU 3.40GHz (Family: 15, Model: 6, Stepping: 4)
> CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
> Compiled with runtime CPU detection.
> 116 audio & 240 video codecs
>
> Playing s6300725.avi.
>
> AVI file format detected.
> [aviheader] Video stream found, -vid 0
> [aviheader] Audio stream found, -aid 1
> VIDEO:  [MJPG]  640x480  24bpp  30,000 fps  9328,3 kbps (1138,7 kbyte/s)
>
>      =======================|  DirectFB 1.1.0  |=======================
>           (c) 2001-2007  The DirectFB Organization (directfb.org)
>           (c) 2000-2004  Convergence (integrated media) GmbH
>         ------------------------------------------------------------
>
> (*) DirectFB/Core: Single Application Core. (2007-10-15 08:36)
> (!) DirectFB/core/vt: Error opening `/dev/tty0'!
>     --> Отказано в доступе
> (!) DirectFB/Core: Could not initialize 'system_core' core!
>     --> Initialization error!
> vo_directfb2.c <275>:
> 	(#) DirectFBError [DirectFBCreate (&dfb)]: Initialization error!
>
> Но, как я понимаю, это уже смежный вопрос.

Вопрос о чём? И вопрос в devel@ ли?

____
Led.

Re: [devel] mplayer q

[Хихин Руслан]

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

Здравствуйте led@altlinux.ru
  В сообщении от 21 ноября 2007 led@altlinux.ru написал(a):
 > Вопрос о чём? И вопрос в devel@ ли?

Это не вопрос - это констатация, что через directfb не играет.

-- 
С  уважением Хихин Руслан

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

Re: [devel] mplayer q

[Led]

В сообщении от Wednesday 21 November 2007 07:51:52 Хихин Руслан написал(а):
> Здравствуйте led@altlinux.ru
>
>   В сообщении от 21 ноября 2007 led@altlinux.ru написал(a):
>  > Вопрос о чём? И вопрос в devel@ ли?
>
> Это не вопрос - это констатация, что через directfb не играет.

Играет, только что проверил. Нужен работающий фреймбуффер (не vesafb) и 
нормальная libcairo.

-- 
Led

Re: [devel] mplayer q

[led]

Tuesday, 20 November 2007 13:52:45 Alexey Tourbin написав:
> On Tue, Nov 20, 2007 at 02:46:26PM +0300, Dmitry V. Levin wrote:
> > Повторяю свой вопрос:
> > Как работает mplayer по состоянию Сизифа "на сейчас"?
>
> В иксах mplayer работает (по крайней мере mms:// музыку играет).  Когда
> я попробовал запустить "mplayer -vo directfb /..." то у меня всё зависло
> (vga=0x0317, потом просто переключился в иксы по C-A-F7 и оно
> "отвисло").  Но я не знаю, работало ли это когда-нибудь вообще, и всё ли
> потребное я сделал для запуска mplayer'а в режиме directfb.

А что, directfb уже умеет работать в в недо-фреймбуффере (vesafb)?

> У меня 
> проприетарный nvidia драйвер в иксах.

Когда я последний раз проверял (честно говоря, это было давно, даже не в этом 
году), mplayer работал через directfb. Но только для тех <video>fb, с 
которыми directfb "дружил".

___
Led.

Re: [devel] mplayer q

[led]

Wednesday, 21 November 2007 00:00:16 led@altlinux.ru написав:
> Tuesday, 20 November 2007 13:52:45 Alexey Tourbin написав:
> > On Tue, Nov 20, 2007 at 02:46:26PM +0300, Dmitry V. Levin wrote:
> > > Повторяю свой вопрос:
> > > Как работает mplayer по состоянию Сизифа "на сейчас"?
> >
> > В иксах mplayer работает (по крайней мере mms:// музыку играет).  Когда
> > я попробовал запустить "mplayer -vo directfb /..." то у меня всё зависло
> > (vga=0x0317, потом просто переключился в иксы по C-A-F7 и оно
> > "отвисло").  Но я не знаю, работало ли это когда-нибудь вообще, и всё ли
> > потребное я сделал для запуска mplayer'а в режиме directfb.
>
> А что, directfb уже умеет работать в в недо-фреймбуффере (vesafb)?
>
> > У меня
> > проприетарный nvidia драйвер в иксах.
>
> Когда я последний раз проверял (честно говоря, это было давно, даже не в
> этом году), mplayer работал через directfb. Но только для тех <video>fb, с
> которыми directfb "дружил".

Вот только что проверил: на uvesafb - нормально работает. Правда, у меня нет 
такой "феерии" legacy-библиотек: на устранение её я потратил значительно 
меньше времени, чем каждый из пишущих в этот тред на написание постов - 
забросил в hasher libcairo и потом обновил её в вситеме:)

___
Led.

P.S. На vesafb лучше ничего directfb'шное не запускать - воможно 
полное "залипание": даже Alt-SysRq-B не работает:)

[devel] vesafb (was mplayer q)

[led]

Wednesday, 21 November 2007 00:43:32 led@altlinux.ru написав:
> Вот только что проверил: на uvesafb - нормально работает. Правда, у меня
> нет такой "феерии" legacy-библиотек: на устранение её я потратил
> значительно меньше времени, чем каждый из пишущих в этот тред на написание
> постов - забросил в hasher libcairo и потом обновил её в вситеме:)

> P.S. На vesafb лучше ничего directfb'шное не запускать - воможно
> полное "залипание": даже Alt-SysRq-B не работает:)

Кстати, я так понимаю, что vesafb у нас вроде священной коровы, несмотря на 
постоянные проблемы с nvidia.ko.
На днях тут коллеги жаловались, что периодически, уже давно (даже привыкли 
уже) ловят полный завис системы после нескольких переключений из X-ов в 
консоль и обратно. Я долго удивлялся - у меня такого вобще не припомню... 
Железо у нас полностью одинаковое или почти одинаковое (nForce/GeForce+AMD). 
А через час-полтора выяснили, что различия только в одном: я уже с полгода не 
пользуюсь vesafb (в отличие от них), вместо этого использую uvesafb:)

___
Led.

Re: [devel] vesafb (was mplayer q)

[Konstantin A. Lepikhov]

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

Hi led!

Wednesday 21, at 12:54:47 AM you wrote:

> Wednesday, 21 November 2007 00:43:32 led@altlinux.ru написав:
> > Вот только что проверил: на uvesafb - нормально работает. Правда, у меня
> > нет такой "феерии" legacy-библиотек: на устранение её я потратил
> > значительно меньше времени, чем каждый из пишущих в этот тред на написание
> > постов - забросил в hasher libcairo и потом обновил её в вситеме:)
> 
> > P.S. На vesafb лучше ничего directfb'шное не запускать - воможно
> > полное "залипание": даже Alt-SysRq-B не работает:)
> 
> Кстати, я так понимаю, что vesafb у нас вроде священной коровы, несмотря на 
> постоянные проблемы с nvidia.ko.
> На днях тут коллеги жаловались, что периодически, уже давно (даже привыкли 
> уже) ловят полный завис системы после нескольких переключений из X-ов в 
> консоль и обратно. Я долго удивлялся - у меня такого вобще не припомню... 
> Железо у нас полностью одинаковое или почти одинаковое (nForce/GeForce+AMD). 
> А через час-полтора выяснили, что различия только в одном: я уже с полгода не 
> пользуюсь vesafb (в отличие от них), вместо этого использую uvesafb:)
$ dmesg|grep uvesa
uvesafb: failed to execute /sbin/v86d
uvesafb: make sure that the v86d helper is installed and executable
uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22

$ apt-cache search v86d
$

Пеарить тут все горазды :)

-- 
WBR et al.

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

Re: [devel] vesafb (was mplayer q)

[led]

Wednesday, 21 November 2007 01:27:24 Konstantin A. Lepikhov написав:
> Hi led!
>
> Wednesday 21, at 12:54:47 AM you wrote:
> > Wednesday, 21 November 2007 00:43:32 led@altlinux.ru написав:
> > > Вот только что проверил: на uvesafb - нормально работает. Правда, у
> > > меня нет такой "феерии" legacy-библиотек: на устранение её я потратил
> > > значительно меньше времени, чем каждый из пишущих в этот тред на
> > > написание постов - забросил в hasher libcairo и потом обновил её в
> > > вситеме:)
> > >
> > > P.S. На vesafb лучше ничего directfb'шное не запускать - воможно
> > > полное "залипание": даже Alt-SysRq-B не работает:)
> >
> > Кстати, я так понимаю, что vesafb у нас вроде священной коровы, несмотря
> > на постоянные проблемы с nvidia.ko.
> > На днях тут коллеги жаловались, что периодически, уже давно (даже
> > привыкли уже) ловят полный завис системы после нескольких переключений из
> > X-ов в консоль и обратно. Я долго удивлялся - у меня такого вобще не
> > припомню... Железо у нас полностью одинаковое или почти одинаковое
> > (nForce/GeForce+AMD). А через час-полтора выяснили, что различия только в
> > одном: я уже с полгода не пользуюсь vesafb (в отличие от них), вместо
> > этого использую uvesafb:)
>
> $ dmesg|grep uvesa
> uvesafb: failed to execute /sbin/v86d
> uvesafb: make sure that the v86d helper is installed and executable
> uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
> uvesafb: vbe_init() failed with -22
> uvesafb: probe of uvesafb.0 failed with error -22
>
> $ apt-cache search v86d
> $
>
> Пеарить тут все горазды :)

Не тормози, плиз:) Было к чему - v86d уже давно был бы в сизифе (uvesafb я в 
Сизифе не наблюдаю). Короче - УМВР (и на i586, и на x86_64).

___
Led.

Re: [devel] vesafb (was mplayer q)

[Konstantin A. Lepikhov]

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

Hi led!

Wednesday 21, at 01:45:02 AM you wrote:

<skip>
> > $ apt-cache search v86d
> > $
> >
> > Пеарить тут все горазды :)
> 
> Не тормози, плиз:) Было к чему - v86d уже давно был бы в сизифе (uvesafb я в 
> Сизифе не наблюдаю). Короче - УМВР (и на i586, и на x86_64).
а в гит выложить, не?

-- 
WBR et al.

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

Re: [devel] vesafb (was mplayer q)

[led]

Wednesday, 21 November 2007 02:08:06 Konstantin A. Lepikhov написав:
> Hi led!
>
> Wednesday 21, at 01:45:02 AM you wrote:
>
> <skip>
>
> > > $ apt-cache search v86d
> > > $
> > >
> > > Пеарить тут все горазды :)
> >
> > Не тормози, плиз:) Было к чему - v86d уже давно был бы в сизифе (uvesafb
> > я в Сизифе не наблюдаю). Короче - УМВР (и на i586, и на x86_64).
>
> а в гит выложить, не?

В какой?

По ссылке лежат SRPMS и RPMS.

http://ftp.linux.kiev.ua/pub/Linux/ALT/people/led/Sisyphus/

С 2.6.18 работает, с 2.6.22 - пока нет (наверное из-за того, что для 2.6.22 
нужно и klibc обновить (я собирал v86d с klibc - у меня он стартует в initrd, 
но можно и обыный modprobe uvesafb mode=... в основной системе), а значит и 
udev...).

___
Led.

Re: [devel] vesafb (was mplayer q)

[led]

Wednesday, 21 November 2007 02:29:16 led@altlinux.ru написав:
> Wednesday, 21 November 2007 02:08:06 Konstantin A. Lepikhov написав:
> > Hi led!
> >
> > Wednesday 21, at 01:45:02 AM you wrote:
> >
> > <skip>
> >
> > > > $ apt-cache search v86d
> > > > $
> > > >
> > > > Пеарить тут все горазды :)
> > >
> > > Не тормози, плиз:) Было к чему - v86d уже давно был бы в сизифе
> > > (uvesafb я в Сизифе не наблюдаю). Короче - УМВР (и на i586, и на
> > > x86_64).
> >
> > а в гит выложить, не?
>
> В какой?
>
> По ссылке лежат SRPMS и RPMS.
>
> http://ftp.linux.kiev.ua/pub/Linux/ALT/people/led/Sisyphus/
>
> С 2.6.18 работает, с 2.6.22 - пока нет (наверное из-за того, что для 2.6.22
> нужно и klibc обновить (я собирал v86d с klibc - у меня он стартует в
> initrd, но можно и обыный modprobe uvesafb mode=... в основной системе), а
> значит и udev...).

klibc, естественно, предварительно тоже нужно пересобрать с хэдерами ядра, в 
которых есть uvesafb.h, иначе v86d получится нерабочий.

Led.

[devel] std-smp += uvesafb? (was: vesafb (was mplayer q))

[Michael Shigorin]

On Wed, Nov 21, 2007 at 02:27:24AM +0300, Konstantin A. Lepikhov wrote:
> $ dmesg|grep uvesa
> uvesafb: failed to execute /sbin/v86d
> uvesafb: make sure that the v86d helper is installed and executable
> uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2)
> uvesafb: vbe_init() failed with -22
> uvesafb: probe of uvesafb.0 failed with error -22
> $ apt-cache search v86d
> $
> Пеарить тут все горазды :)

Дык https://bugzilla.altlinux.org/show_bug.cgi?id=12618

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

[devel] завис nvidia из X-ов в консоль и обратно (was: vesafb (was mplayer q))

[Sergey V Turchin]

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

On 21 ноября 2007, led@altlinux.ru wrote:

[...]
> ловят полный завис системы после нескольких 
> переключений из X-ов в консоль и обратно.
Я лично целыми днями только этим и занимаюсь на протяжении 
нескольких лет дома и на работе на различном железе и моделях 
nvidia (MX440, FX5500, 6150) (единственное, всегда последняя версия 
дров (cat /proc/driver/nvidia/version)) и у меня нет и не было этой 
проблемы.
Beryl не использую. Ядро только std. Система везде сборки x86.

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] завис nvidia из X-ов в консоль и обратно (was: vesafb (was mplayer q))

[Led]

В сообщении от Wednesday 21 November 2007 12:30:39 Sergey V Turchin 
написал(а):
> On 21 ноября 2007, led@altlinux.ru wrote:
>
> [...]
>
> > ловят полный завис системы после нескольких
> > переключений из X-ов в консоль и обратно.
>
> Я лично целыми днями только этим и занимаюсь на протяжении
> нескольких лет дома и на работе на различном железе и моделях
> nvidia (MX440, FX5500, 6150) (единственное, всегда последняя версия
> дров (cat /proc/driver/nvidia/version)) и у меня нет и не было этой
> проблемы.
> Beryl не использую. Ядро только std. Система везде сборки x86.

Фреймбуффер?

-- 
Led

Re: [devel] завис nvidia из X-ов в консоль и обратно (was: vesafb (was mplayer q))

[Sergey V Turchin]

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

On 21 ноября 2007, Led wrote:

[...]
> Фреймбуффер?
MX440 - 0x303
FX5500 - normal редкоперегружаема, руки не дошли
6150 - 0x317
8600GT - 0x314, но не часто пользуюсь

-- 
Regards, Sergey, ALT Linux Team, http://www.altlinux.ru
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Sun, Nov 18, 2007 at 01:15:17AM +0300, Алексей Турбин wrote:

>> $ rpm -q mplayer 
>> mplayer-1.0-alt35.25029.1
>> $ ldd -r /usr/bin/mplayer |grep directfb
>> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
>> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
>> Можно эту феерию прекратить ?
AT> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
AT> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
AT> причине -- если в адресном пространстве процесса окажется две библиотеки
AT> разных версий, то это скорее всего как минимум не будет работать.

А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
ситуации склеивать ласты?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Одно из преимуществ hasher -- в том, что это всё в пределах POSIX API.
		-- at in devel@

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

Re: [devel] mplayer q

[led]

Sunday, 18 November 2007 04:46:55 Денис Смирнов написав:
> On Sun, Nov 18, 2007 at 01:15:17AM +0300, Алексей Турбин wrote:
> >> $ rpm -q mplayer
> >> mplayer-1.0-alt35.25029.1
> >> $ ldd -r /usr/bin/mplayer |grep directfb
> >> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> >> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> >> Можно эту феерию прекратить ?
>
> AT> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> AT> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> AT> причине -- если в адресном пространстве процесса окажется две
> библиотеки AT> разных версий, то это скорее всего как минимум не будет
> работать.
>
> А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
> ситуации склеивать ласты?

В каком случае "склеивать ласты"? ИМХО если libfoo собрана с 
legacy-библиотекой, то на libfoo нужно вешать blocker-багу.

___
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Sun, Nov 18, 2007 at 04:54:02AM +0200, led@altlinux.ru wrote:

>> А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
>> ситуации склеивать ласты?
> В каком случае "склеивать ласты"? ИМХО если libfoo собрана с 
> legacy-библиотекой, то на libfoo нужно вешать blocker-багу.

Однако собраные с более свежей библиотекой пакеты должны содержать
conflicts на libfoo < %version.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Но если нельзя будет отключить русский перевод, я напьюсь водки.
		-- at in devel@

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

Re: [devel] mplayer q

[Michael Shigorin]

On Sun, Nov 18, 2007 at 11:30:50PM +0300, Денис Смирнов wrote:
> >> А можно ли наши любимые скрипты при сборке rpm-пакета
> >> научить в такой ситуации склеивать ласты?
> > В каком случае "склеивать ласты"? ИМХО если libfoo собрана с 
> > legacy-библиотекой, то на libfoo нужно вешать blocker-багу.
> Однако собраные с более свежей библиотекой пакеты должны
> содержать conflicts на libfoo < %version.

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

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Wed, Nov 21, 2007 at 03:33:36PM +0200, Michael Shigorin wrote:

>>>> А можно ли наши любимые скрипты при сборке rpm-пакета
>>>> научить в такой ситуации склеивать ласты?
>>> В каком случае "склеивать ласты"? ИМХО если libfoo собрана с 
>>> legacy-библиотекой, то на libfoo нужно вешать blocker-багу.
>> Однако собраные с более свежей библиотекой пакеты должны
>> содержать conflicts на libfoo < %version.
MS> Не очень себе представляю, как это должно выглядеть.
MS> Ты ж не руками предлагаешь это расставлять?

Увы, такие конфликты пока только ручками :( К счастью это не такая уж
распространенная ситуация.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН ПАРАШЮТА
 Оптимисты изобретают самолет, пессимисты - парашют.

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Sun, Nov 18, 2007 at 05:46:55AM +0300, Денис Смирнов wrote:
> On Sun, Nov 18, 2007 at 01:15:17AM +0300, Алексей Турбин wrote:
> 
> >> $ rpm -q mplayer 
> >> mplayer-1.0-alt35.25029.1
> >> $ ldd -r /usr/bin/mplayer |grep directfb
> >> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> >> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> >> Можно эту феерию прекратить ?
> AT> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> AT> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> AT> причине -- если в адресном пространстве процесса окажется две библиотеки
> AT> разных версий, то это скорее всего как минимум не будет работать.
> 
> А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
> ситуации склеивать ласты?

Можно завалить сборку mplayer с диагностикой что 'ldd /usr/bin/mplayer'
даёт libdirectfb-*A* и libdirectfb-*B*.  Но это не вина
/usr/bin/mplayer, а вина того, кто транзитивно (или "рекурсивно")
вытягивает лишнюю версию libdirectfb.

В общем-то после пересборки libcairo с новым libdirectfb сборка mplayer
должна дать идентичный результат.  Казалось бы, на кой чёрт её заваливать?

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

Re: [devel] mplayer q

[led]

Sunday, 18 November 2007 05:05:23 Alexey Tourbin написав:
> On Sun, Nov 18, 2007 at 05:46:55AM +0300, Денис Смирнов wrote:
> > On Sun, Nov 18, 2007 at 01:15:17AM +0300, Алексей Турбин wrote:
> > >> $ rpm -q mplayer
> > >> mplayer-1.0-alt35.25029.1
> > >> $ ldd -r /usr/bin/mplayer |grep directfb
> > >> libdirectfb-1.1.so.0 => /usr/lib/libdirectfb-1.1.so.0 (0xb7f04000)
> > >> libdirectfb-0.9.so.25 => /usr/lib/libdirectfb-0.9.so.25 (0xb5f37000)
> > >> Можно эту феерию прекратить ?
> >
> > AT> А вот я говорил, что не надо увлекаться запаковской legacy библиотек!
> > AT> Лучше просто пересобраться всё с новой библиотекой.  И именно по этой
> > AT> причине -- если в адресном пространстве процесса окажется две
> > библиотеки AT> разных версий, то это скорее всего как минимум не будет
> > работать.
> >
> > А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
> > ситуации склеивать ласты?
>
> Можно завалить сборку mplayer с диагностикой что 'ldd /usr/bin/mplayer'
> даёт libdirectfb-*A* и libdirectfb-*B*.  Но это не вина
> /usr/bin/mplayer, а вина того, кто транзитивно (или "рекурсивно")
> вытягивает лишнюю версию libdirectfb.
>
> В общем-то после пересборки libcairo с новым libdirectfb сборка mplayer
> должна дать идентичный результат.  Казалось бы, на кой чёрт её заваливать?

После пересборки libcairo и установки её в систему получаем:
$ ldd -r /usr/bin/mplayer | grep directfb
libdirectfb-1.1.so.0 => /usr/lib64/libdirectfb-1.1.so.0 (0x00002b8c08f72000)
$

mplayer не пересобирался и не переустанавливался

___
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Sun, Nov 18, 2007 at 06:05:23AM +0300, Алексей Турбин wrote:

>> А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
>> ситуации склеивать ласты?
AT> Можно завалить сборку mplayer с диагностикой что 'ldd /usr/bin/mplayer'
AT> даёт libdirectfb-*A* и libdirectfb-*B*.  Но это не вина
AT> /usr/bin/mplayer, а вина того, кто транзитивно (или "рекурсивно")
AT> вытягивает лишнюю версию libdirectfb.
AT> В общем-то после пересборки libcairo с новым libdirectfb сборка mplayer
AT> должна дать идентичный результат.  Казалось бы, на кой чёрт её заваливать?

На тот, что это означает как минимум необходимость поставить у пакета
mplayer conflicts на более раннюю версию libcairo. Для нормальной
работоспособности точечных обновлений.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
КОММЕНТАРИЙ КОЛЛАГЕНА К ЗАКОНУ МЕРФИ
 Мерфи был оптимистом!

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

Re: [devel] mplayer q

[led]

Sunday, 18 November 2007 22:27:32 Денис Смирнов написав:
> On Sun, Nov 18, 2007 at 06:05:23AM +0300, Алексей Турбин wrote:
> >> А можно ли наши любимые скрипты при сборке rpm-пакета научить в такой
> >> ситуации склеивать ласты?
>
> AT> Можно завалить сборку mplayer с диагностикой что 'ldd /usr/bin/mplayer'
> AT> даёт libdirectfb-*A* и libdirectfb-*B*.  Но это не вина
> AT> /usr/bin/mplayer, а вина того, кто транзитивно (или "рекурсивно")
> AT> вытягивает лишнюю версию libdirectfb.
> AT> В общем-то после пересборки libcairo с новым libdirectfb сборка mplayer
> AT> должна дать идентичный результат.  Казалось бы, на кой чёрт её
> заваливать?
>
> На тот, что это означает как минимум необходимость поставить у пакета
> mplayer conflicts на более раннюю версию libcairo. Для нормальной
> работоспособности точечных обновлений.

Каким образом? mplayer не требует libcairo, mplayer требует libgtk. Вы 
считаете, что я должен при сборке mplayer отслеживать всё дерево линковки 
всех библиотек, которые использует mplayer???

___
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Sun, Nov 18, 2007 at 10:58:11PM +0200, led@altlinux.ru wrote:

> Каким образом? mplayer не требует libcairo, mplayer требует libgtk. Вы 
> считаете, что я должен при сборке mplayer отслеживать всё дерево линковки 
> всех библиотек, которые использует mplayer???

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

Если бы сборка обломалась, то:
 - у тебя была бы возможность повесить блокер на libcairo
 - поставить Conflicts на текущую версию libcairo

После того как прошел бы в репо нормальный libcairo сделать touch mplayer
и отправить на пересборку.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Не юзаю новых технологий, со старыми проблем хватает.
		-- wrar in sisyphus@

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

Re: [devel] mplayer q

[led]

Monday, 19 November 2007 07:17:08 Денис Смирнов написав:
> On Sun, Nov 18, 2007 at 10:58:11PM +0200, led@altlinux.ru wrote:
> > Каким образом? mplayer не требует libcairo, mplayer требует libgtk. Вы
> > считаете, что я должен при сборке mplayer отслеживать всё дерево линковки
> > всех библиотек, которые использует mplayer???
>
> Вот в том-то и дело что ты не можешь этим заниматься. Но де-факто, хоть и
> не по твоей вине, но mplayer оказался в Сизифе с blocker-багой. Мало того,
> в будущем пользователи делающие точечные апдейты еще будут на этом
> спотыкаться, и будут говорить тебе за это свое большое спасибо.
>
> Если бы сборка обломалась, то:
>  - у тебя была бы возможность повесить блокер на libcairo
>  - поставить Conflicts на текущую версию libcairo
>
> После того как прошел бы в репо нормальный libcairo сделать touch mplayer
> и отправить на пересборку.

А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и 
через полгода, потому как по собственному опыту знаю, что баги, в которых 
просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу 
только один вариант в этом случае - просить удалить свой пакет из 
репозитария.

___
Led.

Re: [devel] mplayer q

[Sergey Bolshakov]

>>>>> "led" == led  <led@altlinux.ru> writes:
[skipped]
 > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и 
 > через полгода, потому как по собственному опыту знаю, что баги, в которых 
 > просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу 
 > только один вариант в этом случае - просить удалить свой пакет из 
 > репозитария.
А давайте мы его стукнем^W^W^W просто соберём без directfb --
никто, мне сдаётся, по ней плакать не станет.

-- 

Re: [devel] mplayer q

[led]

Tuesday, 20 November 2007 00:36:05 Sergey Bolshakov написав:
>  > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть
>  > и через полгода, потому как по собственному опыту знаю, что баги, в
>  > которых просьба пересобрать с новой библиотекой, как правило,
>  > игнорируются)? Вижу только один вариант в этом случае - просить удалить
>  > свой пакет из репозитария.
>
> А давайте мы его стукнем^W^W^W просто соберём без directfb --
> никто, мне сдаётся, по ней плакать не станет.

Наверное, я просто соберу его без GUI (gtk2), раз у нас gtk2/libcairo в 
заброшенном состоянии (неизвестно, что ещё вылезет с этими узаконенными 
legacy-библиотеками).

___
Led.

Re: [devel] mplayer q

[Alexey Rusakov]

On Tue, 20 Nov 2007 01:36:05 +0300
Sergey Bolshakov wrote:


> >>>>> "led" == led  <led@altlinux.ru> writes:
> [skipped]
>  > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и 
>  > через полгода, потому как по собственному опыту знаю, что баги, в которых 
>  > просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу 
>  > только один вариант в этом случае - просить удалить свой пакет из 
>  > репозитария.
> А давайте мы его стукнем^W^W^W просто соберём без directfb --
> никто, мне сдаётся, по ней плакать не станет.
lav@ уже плачет по отсутствующему в Сизифе Gtk+ on DirectFB. Нужно собрать
отдельно, отдельно это. Крайне желательно - с непересекающимися сонеймами.
К сожалению, у меня руки до аккуратной сборки libgtk+2 под DirectFB в
обозримое время не дойдут.

-- 
  Alexey "Ktirf" Rusakov
  ALT Linux, project manager

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 02:50:38AM +0300, Alexey Rusakov wrote:
> On Tue, 20 Nov 2007 01:36:05 +0300
> Sergey Bolshakov wrote:
> 
> 
> > >>>>> "led" == led  <led@altlinux.ru> writes:
> > [skipped]
> >  > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и 
> >  > через полгода, потому как по собственному опыту знаю, что баги, в которых 
> >  > просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу 
> >  > только один вариант в этом случае - просить удалить свой пакет из 
> >  > репозитария.
> > А давайте мы его стукнем^W^W^W просто соберём без directfb --
> > никто, мне сдаётся, по ней плакать не станет.
> lav@ уже плачет по отсутствующему в Сизифе Gtk+ on DirectFB. Нужно собрать
> отдельно, отдельно это. Крайне желательно - с непересекающимися сонеймами.
> К сожалению, у меня руки до аккуратной сборки libgtk+2 под DirectFB в
> обозримое время не дойдут.

Не надо собирать ничего отдельно.
Боюсь что у меня тоже руки не дойдут....

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 12:08:59AM +0200, led@altlinux.ru wrote:

> А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и 
> через полгода, потому как по собственному опыту знаю, что баги, в которых 
> просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу 
> только один вариант в этом случае - просить удалить свой пакет из 
> репозитария.

А до этого у тебя будет лежать в репо mplayer с _непредсказуемым_
поведением. И в этом случае лучше его действительно залить без directfb
поддержки.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Автором программы были выявлены недокументированные возможности...

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

Re: [devel] mplayer q

[led]

Tuesday, 20 November 2007 08:29:44 Денис Смирнов написав:
> On Tue, Nov 20, 2007 at 12:08:59AM +0200, led@altlinux.ru wrote:
> > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и
> > через полгода, потому как по собственному опыту знаю, что баги, в которых
> > просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу
> > только один вариант в этом случае - просить удалить свой пакет из
> > репозитария.
>
> А до этого у тебя будет лежать в репо mplayer с _непредсказуемым_
> поведением. И в этом случае лучше его действительно залить без directfb
> поддержки.

С directfb у нас всё в порядке. Я уже сказал: если libgtk/libcairo у нас 
заброшен, значит mplayer будет без GUI.

Led.

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 09:13:52AM +0200, led@altlinux.ru wrote:
> Tuesday, 20 November 2007 08:29:44 Денис Смирнов написав:
> > On Tue, Nov 20, 2007 at 12:08:59AM +0200, led@altlinux.ru wrote:
> > > А до того, как "прошел бы в репо нормальный libcairo" (а это может быть и
> > > через полгода, потому как по собственному опыту знаю, что баги, в которых
> > > просьба пересобрать с новой библиотекой, как правило, игнорируются)? Вижу
> > > только один вариант в этом случае - просить удалить свой пакет из
> > > репозитария.
> >
> > А до этого у тебя будет лежать в репо mplayer с _непредсказуемым_
> > поведением. И в этом случае лучше его действительно залить без directfb
> > поддержки.
> 
> С directfb у нас всё в порядке. Я уже сказал: если libgtk/libcairo у нас 
> заброшен, значит mplayer будет без GUI.

libcairo у нас не заброшен, и libgtk+2 тоже работает.

Специфическая проблема тут в том, что в репозитарии находится две
библиотеки libdirectfb.  Я сейчас не хочу пересобирать libcairo
с новой библиотекой libdirectfb, чтобы все успели над этой проблемой
подумать.

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

Re: [devel] mplayer q

[Alexey Gladkov]

Alexey Tourbin wrote:
> Специфическая проблема тут в том, что в репозитарии находится две
> библиотеки libdirectfb.  Я сейчас не хочу пересобирать libcairo
> с новой библиотекой libdirectfb, чтобы все успели над этой проблемой
> подумать.

Так как у libdirectfb при _каждом_ релизе меняется API и довольно
часто ABI, я другого способа обновления этой библиотеки в сизифе не
вижу. А именно плавный переезд с версии на верию. Я не имею
возможности лазить по всем проектам, слинкованными с libdirectfb, и
фиксить их под новую библиотеку (если это нужно). Я оставляю эту
работу на совести соотвествующих мантейнеров.

Если какой-либо мантейнер (не будем показывать пальцем, хотя это был
слонёнок) _НЕ_ХОЧЕТ_ обновлять пакет по каким-то своим соображениям,
то я ему не смогу помочь, взяв его работу на себя.

-- 
Rgrds, legion

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 11:00:34AM +0300, Alexey Gladkov wrote:
> Alexey Tourbin wrote:
> > Специфическая проблема тут в том, что в репозитарии находится две
> > библиотеки libdirectfb.  Я сейчас не хочу пересобирать libcairo
> > с новой библиотекой libdirectfb, чтобы все успели над этой проблемой
> > подумать.
> 
> Так как у libdirectfb при _каждом_ релизе меняется API и довольно
> часто ABI, я другого способа обновления этой библиотеки в сизифе не
> вижу. А именно плавный переезд с версии на верию. Я не имею

Зачем вместо переименования в libdirectfb1.1 библиотека была назад
переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
стоит "позапрошлая" библиотека libdireсtfb.
https://bugzilla.altlinux.org/show_bug.cgi?id=13383

> возможности лазить по всем проектам, слинкованными с libdirectfb, и
> фиксить их под новую библиотеку (если это нужно). Я оставляю эту
> работу на совести соотвествующих мантейнеров.

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

> Если какой-либо мантейнер (не будем показывать пальцем, хотя это был
> слонёнок) _НЕ_ХОЧЕТ_ обновлять пакет по каким-то своим соображениям,
> то я ему не смогу помочь, взяв его работу на себя.

По-моему просто не надо было собирать compat библиотеку предыдущей
версии.  А если заявлен плавный переезд с версии на версию, то ловлю
на слове.  Буду плавно переезжать.

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 11:11:09AM +0300, Алексей Турбин wrote:

AT> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
AT> переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
AT> стоит "позапрошлая" библиотека libdireсtfb.

/me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
но другим soname.

Это хроническая проблема, на которой уже не один раз обжигались. До того
как это правило не будет enforce'иться (а значит вообще выполняться) слова
о том что можно легко обновиться apt'ом будут пустым звуком, ибо эта
проблема является одной из самых распространенных и сложных для не
опытного пользователя _сизифа_ в разрешении.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
> В М2.4 эти манны в man-pages-POSIX-1.0-alt2.noarch.rpm :)
manna-pages, говоришь? :)
		-- mike in community@

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

Re: [devel] mplayer q

[Dmitry V. Levin]

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

On Tue, Nov 20, 2007 at 02:09:13PM +0300, Денис Смирнов wrote:
> On Tue, Nov 20, 2007 at 11:11:09AM +0300, Алексей Турбин wrote:
> 
> AT> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
> AT> переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
> AT> стоит "позапрошлая" библиотека libdireсtfb.
> 
> /me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
> Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
> то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
> но другим soname.

Нет, наверное проще apt исправить чем это сделать.


-- 
ldv

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 02:45:34PM +0300, Dmitry V. Levin wrote:

AT>>> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
AT>>> переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
AT>>> стоит "позапрошлая" библиотека libdireсtfb.
>> /me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
>> Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
>> то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
>> но другим soname.
DVL> Нет, наверное проще apt исправить чем это сделать.

Я так понимаю, что кроме тебя и at@ никто не рискнет что-либо исправлять в
apt. Кто-нибудь из вас планирует решить эту проблему с apt?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
В пакете всё должно быть прекрасно: и summary, и changelog, и душа,
и мысли.
		-- at in sisyphus@

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 02:45:34PM +0300, Dmitry V. Levin wrote:

> AT>> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
> AT>> переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
> AT>> стоит "позапрошлая" библиотека libdireсtfb.
>> /me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
>> Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
>> то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
>> но другим soname.
DVL> Нет, наверное проще apt исправить чем это сделать.

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

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
P.S. Вообще-то это offtopic для данной баги. :)
		-- ldv in #7606

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 02:59:51PM +0300, Денис Смирнов wrote:
> On Tue, Nov 20, 2007 at 02:45:34PM +0300, Dmitry V. Levin wrote:
> 
> > AT>> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
> > AT>> переименована в libdirectfb?  Апту теперь ломает крышу, если в системе
> > AT>> стоит "позапрошлая" библиотека libdireсtfb.
> >> /me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
> >> Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
> >> то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
> >> но другим soname.
> DVL> Нет, наверное проще apt исправить чем это сделать.
> 
> Да, исправление этой проблемы в apt не решает ситуации с тем, что часто
> _нужно_ иметь в системе библиотеку с разными soname -- в основном для
> точечных обновлений. Историю с libreadline я до сих пор вспоминаю с
> ужасом.

Нельзя решить нерешаемые проблемы.  Я предлагаю просто не паковать
legacy библиотеки, то есть делать вынужденную пересборку всех пакетов
при смене soname'а.  Но если legacy библиотека УЖЕ СТОИТ в системе,
то возможности точечного обновления на свой страх и риск никто не
отнимает (при условии, что, конечно, пакеты с библиотеками называются
по-разному, то есть могут одновременно встать).

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

Re: [devel] mplayer q

[led]

Tuesday, 20 November 2007 14:07:02 Alexey Tourbin написав:
> On Tue, Nov 20, 2007 at 02:59:51PM +0300, Денис Смирнов wrote:
> > On Tue, Nov 20, 2007 at 02:45:34PM +0300, Dmitry V. Levin wrote:
> > > AT>> Зачем вместо переименования в libdirectfb1.1 библиотека была назад
> > > AT>> переименована в libdirectfb?  Апту теперь ломает крышу, если в
> > > системе AT>> стоит "позапрошлая" библиотека libdireсtfb.
> > >
> > >> /me уже хрен знает сколько времени просит чтобы пакет перед попаданием
> > >> в Сизиф проверялся, и если в пакете с именем N предоставлялась некая
> > >> либа X, то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N
> > >> и либой X но другим soname.
> >
> > DVL> Нет, наверное проще apt исправить чем это сделать.
> >
> > Да, исправление этой проблемы в apt не решает ситуации с тем, что часто
> > _нужно_ иметь в системе библиотеку с разными soname -- в основном для
> > точечных обновлений. Историю с libreadline я до сих пор вспоминаю с
> > ужасом.
>
> Нельзя решить нерешаемые проблемы.  Я предлагаю просто не паковать
> legacy библиотеки, то есть делать вынужденную пересборку всех пакетов
> при смене soname'а.  Но если legacy библиотека УЖЕ СТОИТ в системе,
> то возможности точечного обновления на свой страх и риск никто не
> отнимает (при условии, что, конечно, пакеты с библиотеками называются
> по-разному, то есть могут одновременно встать).

так "Allow-Duplicated" позволяет "одновременно встать" и пакетам, если они 
называются одинаково. Разве не так?

Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 11:45:27PM +0200, led@altlinux.ru wrote:

> так "Allow-Duplicated" позволяет "одновременно встать" и пакетам, если они 
> называются одинаково. Разве не так?

Давай не будем делать из системы слакварь?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Мастер достоин того, чтобы ради него купить DVD :)
		-- mithraen in community@

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

Re: [devel] mplayer q

[led]

Thursday, 22 November 2007 04:56:57 Денис Смирнов написав:
> On Tue, Nov 20, 2007 at 11:45:27PM +0200, led@altlinux.ru wrote:
> > так "Allow-Duplicated" позволяет "одновременно встать" и пакетам, если
> > они называются одинаково. Разве не так?
>
> Давай не будем делать из системы слакварь?

..."точечными обновлениями"? Давайте:)

___
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Thu, Nov 22, 2007 at 05:05:38AM +0200, led@altlinux.ru wrote:

>>> так "Allow-Duplicated" позволяет "одновременно встать" и пакетам, если
>>> они называются одинаково. Разве не так?
>> Давай не будем делать из системы слакварь?
> ..."точечными обновлениями"? Давайте:)

Без точечных обновлений можно будет обойтись когда у нас количество
мантейнеров вырастет эдак на 2-3 порядка, и за blocker'ы висящие больше
5-и минут их будут расстреливать.

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

Hint: бывают сервера, где очень сложно обкатать сразу обновление целиком.
В этом случае сначала обновляются все малозначимые для работы сервера
пакеты, потом пакеты которые маловероятно дадут неприятные side-effects. А
потом ключевые сервисы. По одному. В заранее предусмотренные downtime,
когда есть возможность спокойно протестировать последствия.

А о том, что от allow-duplicated apt'у крышу сносит вообще напрочь (не зря
у нас очень много неписаных правил, вроде "не делать никогда requires ни
на какой ядреный пакет"), и это пофиксить уже невозможно, потому как
правильную логику поведения apt'а в ситуации с установленными несколькими
пакетами одной версии до конца никто сформулировать не может, мы, конечно,
не знаем?

О чем разборка вообще? О том что в Сизифе не должно быть пакетов так
замечательно слинкованых? Не должно быть. Да, для отдельных пакетов как
mplayer (который используется в серверных решениях крайне редко -- и то
речь об mencoder) можно сделать соответствующую ручку вида
%set_verify_elf что-нибудь там. Просто потому что кривой mplayer лучше чем
отсутствующий. И если его мантейнеру лень сделать соответствующий
conflicts, это не страшно.

В случае же с другими пакетами это страшно. И скажем я для своих пакетов
хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
виде.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Легко с группами [RPM] 1-го уровня не бывает.
		-- ldv in devel@


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

Re: [devel] mplayer q

[Alexey I. Froloff]

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

* Денис Смирнов <mithraen@> [071122 08:30]:
> Без точечных обновлений можно будет обойтись когда у нас количество
[многабукф]
> хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
> виде.
Вроде уже договорились, что пакеты из группы System/Legacy
libraries не попадут ни в каком виде в дистрибутивы (и бранчи,
надо бы добавить).

То, что предлагаешь делать ты, называется "отслеживание всех
зависимостей вручную".  Зачем нам тогда findreq, buildreq и
прочие rpm'ы-apt'ы?  Вон, в debian всё руками проставляют.

А Сизиф - вообще не дистрибутив и кривизна тут допустима.

-- 
Regards,
Sir Raorn.

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Thu, Nov 22, 2007 at 12:00:27PM +0300, Alexey I. Froloff wrote:
> * Денис Смирнов <mithraen@> [071122 08:30]:
> > Без точечных обновлений можно будет обойтись когда у нас количество
> [многабукф]
> > хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
> > виде.
> Вроде уже договорились, что пакеты из группы System/Legacy
> libraries не попадут ни в каком виде в дистрибутивы (и бранчи,
> надо бы добавить).

Ещё лучше System/Legacy libraries сразу же класть в отдельный от сизифа
минирепо, для тех кому это дело очень нужно.  Можно даже сохранять туда
ошмётки от старых пакетов (без исходников) со статусом "раньше работало".
В сизифе же желательно пересобирать под новые сонеймы чем можно быстрее,
в идеале транзакцией.

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Thu, Nov 22, 2007 at 12:00:27PM +0300, Alexey I. Froloff wrote:
>> Без точечных обновлений можно будет обойтись когда у нас количество
 AIF> [многабукф]
>> хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
>> виде.
AIF> Вроде уже договорились, что пакеты из группы System/Legacy
AIF> libraries не попадут ни в каком виде в дистрибутивы (и бранчи,
AIF> надо бы добавить).

Это не спасает, к сожалению.

Смотри -- предположим завтра новая libdirectfb уйдет в бранч. Или в
дистрибутив новый, что вероятнее.  Вроде все красиво?

А потом человек имеющий старую инсталляцию (со старым libcairo) набирает:
apt-get install mplayer и получает кривой mplayer.

AIF> То, что предлагаешь делать ты, называется "отслеживание всех
AIF> зависимостей вручную".  Зачем нам тогда findreq, buildreq и
AIF> прочие rpm'ы-apt'ы?  Вон, в debian всё руками проставляют.
AIF> А Сизиф - вообще не дистрибутив и кривизна тут допустима.

Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf) обматерил
пакет. Вплоть до вывода в STDERR той строчки conflicts, которую человеку
надо добавить в spec. До полного перехода на сборку из git
автоматизировать это принципиально невозможно, после -- можно, но нелегко.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<sadeness> "соберу гном, возможны другие нетрадиционные услуги"

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

Re: [devel] mplayer q

[Led]

В сообщении от Thursday 22 November 2007 13:59:01 Денис Смирнов написал(а):
> On Thu, Nov 22, 2007 at 12:00:27PM +0300, Alexey I. Froloff wrote:
> >> Без точечных обновлений можно будет обойтись когда у нас количество
>
>  AIF> [многабукф]
>
> >> хотел бы иметь возможность _запретить_ их существование в Сизифе в
> >> кривом виде.
>
> AIF> Вроде уже договорились, что пакеты из группы System/Legacy
> AIF> libraries не попадут ни в каком виде в дистрибутивы (и бранчи,
> AIF> надо бы добавить).
>
> Это не спасает, к сожалению.
>
> Смотри -- предположим завтра новая libdirectfb уйдет в бранч. Или в
> дистрибутив новый, что вероятнее.  Вроде все красиво?
>
> А потом человек имеющий старую инсталляцию (со старым libcairo) набирает:
> apt-get install mplayer и получает кривой mplayer.

Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт в 
сизиф. Вроде всё красиво? А ldd mplayer будет показывать libdirectfb-1.1 + 
libdirectfb-1.2, как будет работать и будет ли - неизвестно. Твои 
предложения?

> AIF> То, что предлагаешь делать ты, называется "отслеживание всех
> AIF> зависимостей вручную".  Зачем нам тогда findreq, buildreq и
> AIF> прочие rpm'ы-apt'ы?  Вон, в debian всё руками проставляют.
> AIF> А Сизиф - вообще не дистрибутив и кривизна тут допустима.
>
> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf) обматерил
> пакет. Вплоть до вывода в STDERR той строчки conflicts, которую человеку
> надо добавить в spec.

Ещё раз - посмотри всё дерево библиотек, которое использует mplayer прямо (это 
ещё как-то можно отследить, но с ними и так всё нормально разруливается по 
сонеймам), и косвено (их намного больше) - как их предлагаешь "отслеживать"? 
разве что постоянно , внимательно читать cyber-talks@ и анализировать КАЖДЫЙ 
обновлённый пакет: а не влияет ли он КОСВЕНО на mplayer?

ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с ней 
слинковано - либо роботом, либо уведеомлением мейнтейнера через багзиллу. 
Ориентироваться на возможность "точечного обновления" непродуктивно, для этих 
редких и нетривиальных случаев есть бэкпорты и бэкпортирование как таковое 
(хотя с переходом на git оно может "кануть в Лету" или быть на порядок 
затруднено).

Практика legacy-библиотек в репозитарии вносит беспорядок, непредсказуемые 
проблемы (как видно на примере mplayer) и отнимает время у мейнтейнеров для 
их сборки и поддержки.

> До полного перехода на сборку из git 
> автоматизировать это принципиально невозможно, после -- можно, но нелегко.

Будет git - будут другие проблемы. И я почему-то не уверен, что их будет 
меньше :(

-- 
Led

Re: [devel] mplayer q

[Денис Смирнов]

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

On Thu, Nov 22, 2007 at 03:04:48PM +0200, Led wrote:
 
L> Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт в 
L> сизиф. Вроде всё красиво? А ldd mplayer будет показывать libdirectfb-1.1 + 
L> libdirectfb-1.2, как будет работать и будет ли - неизвестно. Твои 
L> предложения?

Хороший вопрос. Ты прав.

>> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf) обматерил
>> пакет. Вплоть до вывода в STDERR той строчки conflicts, которую человеку
>> надо добавить в spec.
L> Ещё раз - посмотри всё дерево библиотек, которое использует mplayer прямо (это 
L> ещё как-то можно отследить, но с ними и так всё нормально разруливается по 
L> сонеймам), и косвено (их намного больше) - как их предлагаешь "отслеживать"? 
L> разве что постоянно , внимательно читать cyber-talks@ и анализировать КАЖДЫЙ 
L> обновлённый пакет: а не влияет ли он КОСВЕНО на mplayer?

Это должен делать робот, или не делать никто.

L> ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с ней 
L> слинковано - либо роботом, либо уведеомлением мейнтейнера через багзиллу. 
L> Ориентироваться на возможность "точечного обновления" непродуктивно, для этих 
L> редких и нетривиальных случаев есть бэкпорты и бэкпортирование как таковое 
L> (хотя с переходом на git оно может "кануть в Лету" или быть на порядок 
L> затруднено).

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

L> Практика legacy-библиотек в репозитарии вносит беспорядок, непредсказуемые 
L> проблемы (как видно на примере mplayer) и отнимает время у мейнтейнеров для 
L> их сборки и поддержки.

А с этим я полностью согласен. Только ты предлагаешь использовать это
чтобы замаскировать другую проблему.

>> До полного перехода на сборку из git 
>> автоматизировать это принципиально невозможно, после -- можно, но нелегко.
L> Будет git - будут другие проблемы. И я почему-то не уверен, что их будет 
L> меньше :(

Они будет именно что сильно другими.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Нужно писать по одной перловой программе в день, тогда жизнь наладится.
		-- at in devel@

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

Re: [devel] mplayer q

[led]

Friday, 23 November 2007 17:54:09 Денис Смирнов написав:
> On Thu, Nov 22, 2007 at 03:04:48PM +0200, Led wrote:
>
> L> Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт
> в L> сизиф. Вроде всё красиво? А ldd mplayer будет показывать
> libdirectfb-1.1 + L> libdirectfb-1.2, как будет работать и будет ли -
> неизвестно. Твои L> предложения?
>
> Хороший вопрос. Ты прав.
>
> >> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf)
> >> обматерил пакет. Вплоть до вывода в STDERR той строчки conflicts,
> >> которую человеку надо добавить в spec.
>
> L> Ещё раз - посмотри всё дерево библиотек, которое использует mplayer
> прямо (это L> ещё как-то можно отследить, но с ними и так всё нормально
> разруливается по L> сонеймам), и косвено (их намного больше) - как их
> предлагаешь "отслеживать"? L> разве что постоянно , внимательно читать
> cyber-talks@ и анализировать КАЖДЫЙ L> обновлённый пакет: а не влияет ли он
> КОСВЕНО на mplayer?
>
> Это должен делать робот, или не делать никто.

Т.е. робот должен заворачивать вполне корректный пакет mplayer из-за разнобоя, 
вносимых legacy-библиотеками в репозитарии? И будет заворачивать до тех пор, 
пока "вдруг" этот разнобой каким-то образом, случайно исчезнет? Или я просто 
неправильно тебя понял?

>
> L> ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с
> ней L> слинковано - либо роботом, либо уведеомлением мейнтейнера через
> багзиллу. L> Ориентироваться на возможность "точечного обновления"
> непродуктивно, для этих L> редких и нетривиальных случаев есть бэкпорты и
> бэкпортирование как таковое L> (хотя с переходом на git оно может "кануть в
> Лету" или быть на порядок L> затруднено).
>
> Увы, как я говорил, работоспособность точечных обновлений необходима. В
> противном случае apt можно просто выбросить за ненадобностью.

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

>
> L> Практика legacy-библиотек в репозитарии вносит беспорядок,
> непредсказуемые L> проблемы (как видно на примере mplayer) и отнимает время
> у мейнтейнеров для L> их сборки и поддержки.
>
> А с этим я полностью согласен. Только ты предлагаешь использовать это
> чтобы замаскировать другую проблему.

И с этим я полностьб согласен:) Я прелагаю это, потому как пока не вижу других 
решений :(

>
> >> До полного перехода на сборку из git
> >> автоматизировать это принципиально невозможно, после -- можно, но
> >> нелегко.
>
> L> Будет git - будут другие проблемы. И я почему-то не уверен, что их будет
> L> меньше :(
>
> Они будет именно что сильно другими.

В том-то и дело, что они не исчезнут :(

___
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Fri, Nov 23, 2007 at 06:56:11PM +0200, led@altlinux.ru wrote:
>> Это должен делать робот, или не делать никто.
> Т.е. робот должен заворачивать вполне корректный пакет mplayer из-за разнобоя, 
> вносимых legacy-библиотеками в репозитарии? И будет заворачивать до тех пор, 
> пока "вдруг" этот разнобой каким-то образом, случайно исчезнет? Или я просто 
> неправильно тебя понял?

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

То есть если новый mplayer заливается когда репо разломан -- развернуть
mplayer. Если же новый пакет ломает mplayer -- развернут должен быть он.

>> Увы, как я говорил, работоспособность точечных обновлений необходима. В
>> противном случае apt можно просто выбросить за ненадобностью.
> Наверное, иногда необходима... Я просто думал, что вариант с бэкпортами 
> подойдёт для таких редких случаев. Но, возможно, я и неправ...

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

В этом случае "backport'ить" придется весь дистрибутив.

> L>> Будет git - будут другие проблемы. И я почему-то не уверен, что их будет
> L>> меньше :(
>> Они будет именно что сильно другими.
> В том-то и дело, что они не исчезнут :(

Отдел фантастики на втором этаже :)

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН ХЕБЛОКА
 Если товар хорош, его перестают выпускать.

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

Re: [devel] I: Механизм отображения сборочного окружения на зависимости (was: mplayer q)

[Aleksey Avdeev]

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

led@altlinux.ru пишет:
> Friday, 23 November 2007 17:54:09 Денис Смирнов написав:
>> On Thu, Nov 22, 2007 at 03:04:48PM +0200, Led wrote:
>>
>> L> Предположим, завтра новая libcairo, слинкованная с libdirectfb-1.2 уйдёт
>> в L> сизиф. Вроде всё красиво? А ldd mplayer будет показывать
>> libdirectfb-1.1 + L> libdirectfb-1.2, как будет работать и будет ли -
>> неизвестно. Твои L> предложения?
>>
>> Хороший вопрос. Ты прав.
>>
>>>> Не, речь именно о том, чтобы rpm при сборке (вернее verify_elf)
>>>> обматерил пакет. Вплоть до вывода в STDERR той строчки conflicts,
>>>> которую человеку надо добавить в spec.
>> L> Ещё раз - посмотри всё дерево библиотек, которое использует mplayer
>> прямо (это L> ещё как-то можно отследить, но с ними и так всё нормально
>> разруливается по L> сонеймам), и косвено (их намного больше) - как их
>> предлагаешь "отслеживать"? L> разве что постоянно , внимательно читать
>> cyber-talks@ и анализировать КАЖДЫЙ L> обновлённый пакет: а не влияет ли он
>> КОСВЕНО на mplayer?
>>
>> Это должен делать робот, или не делать никто.
> 
> Т.е. робот должен заворачивать вполне корректный пакет mplayer из-за разнобоя, 
> вносимых legacy-библиотеками в репозитарии? И будет заворачивать до тех пор, 
> пока "вдруг" этот разнобой каким-то образом, случайно исчезнет? Или я просто 
> неправильно тебя понял?
> 
>> L> ИМХО если библиотека обновилась - нужно срочно пересобрать ВСЁ, что с
>> ней L> слинковано - либо роботом, либо уведеомлением мейнтейнера через
>> багзиллу. L> Ориентироваться на возможность "точечного обновления"
>> непродуктивно, для этих L> редких и нетривиальных случаев есть бэкпорты и
>> бэкпортирование как таковое L> (хотя с переходом на git оно может "кануть в
>> Лету" или быть на порядок L> затруднено).
>>
>> Увы, как я говорил, работоспособность точечных обновлений необходима. В
>> противном случае apt можно просто выбросить за ненадобностью.
> 
> Наверное, иногда необходима... Я просто думал, что вариант с бэкпортами 
> подойдёт для таких редких случаев. Но, возможно, я и неправ...
> 
>> L> Практика legacy-библиотек в репозитарии вносит беспорядок,
>> непредсказуемые L> проблемы (как видно на примере mplayer) и отнимает время
>> у мейнтейнеров для L> их сборки и поддержки.
>>
>> А с этим я полностью согласен. Только ты предлагаешь использовать это
>> чтобы замаскировать другую проблему.
> 
> И с этим я полностьб согласен:) Я прелагаю это, потому как пока не вижу других 
> решений :(

  Может стоит придумать механизм трансляции текущего сборочного
окружения на зависимости?

  Например так (в порядке бреда ;-)):

1. После сборки пакета с некоим нечто (библиотекой/приложением, назовём
nameAAA для определённости) получаем список пакетов содержащих
библиотеки, с которыми собираемое слинковано по факту:

а) Бинарникам кладущимся в пакет делается ldd для определения списка
lib* с которыми они слинкована по факту.

б) По списку библиотек определяем список пакетов их предоставляющий.
Пусть это будут nameBBB, nameCCC, ... nameDDD.

2. Используя полученный на предыдущем шаге список, в создаваемый пакет
добавляем пачку рrovides специального вида: %name-rnameBBB,
%name-rnameCCC, ... %name-rnameDDD (с версиями данных пакетов). Этот шаг
позволит позволит языком понятным для rpm/apt сохранить информацию о
том, с чем собственно мы собрались по факту. (Данная информация нам
потребуется на следующем шаге.)

3. Создаём список уточняющих requires, которые будут говорить что нам
нужна не просто libBBB, а libBBB собранная с libCCC нужной версии:

а) Для списка пакетов nameBBB, nameCCC, ... nameDDD получаем список
предоставляемых рrovides вида nameBBB-rnameССС, ... nameBBB-rnameXXX,
... nameDDD-rnameYYY (эту информацию сохранил шаг 2, выполненный при
сборке данных пакетов).

б) Фильтруем данный список на предмет нахождения в нём библиотек с
которыми наше nameAAA слинковано. В частности
name*-rname{BBB,ССС,...DDD} это пример того, что мы ищем, а всякие
name*-rname{XXX,...ZZZ} -- ненужный, в данный момет, мусор.

в) Дополняем список requires найденными name*-rname{BBB,ССС,...DDD} с
версиями соответствующих, использованных при сборке (!),
name(BBB,ССС,...DDD}, возможно не тех, что найдены в рrovides данных
пакетов (это то, ради чего всё и затеяно).

  После работы данного алгоритма на выходе, для нашего nameAAA будем
иметь следующие requires:

1. name{BBB,ССС,...DDD} соответствующих версий (как это происходит сейчас)

2. name{BBB,ССС,...DDD}-rname{BBB,ССС,...DDD} с версиями соответствующих
name{BBB,ССС,...DDD}, с которыми эти name{BBB,ССС,...DDD} должны быть
собраны для корректной работы нашего nameAAA.

  Соответственно, если некоторого nameBBB-rnameССС-Y предоставлено не
будет -- nameAAA не встанет, пусть даже в репозетарии существует
nameBBB, предоставляющий nameBBB-rnameССС-X (т. е. собранный с
nameССС-X, а не с nameССС-Y как нам для nameAAA нужно).

  Недостатки такого решения, что вижу сразу:

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

2. Рост бызы rpm/apt.

-- 

С уважением. Алексей.



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

Re: [devel] mplayer q (policy howto)

[Igor Vlasenko]

On Thu, Nov 22, 2007 at 08:21:52AM +0300, Денис Смирнов wrote:
> В случае же с другими пакетами это страшно. И скажем я для своих пакетов
> хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
> виде.

Такие возможности в Сизифе есть, ими только нужно пользоваться.

Policy Applying mini-HOWTO.

1) вычитываем (или пишем, если нет) полиси по нужной теме
(например, 
http://www.freesource.info/wiki/Altlinux/Policy/SharedLibs)
с описанием проблем и способом их решения.

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

Поэтому нужен шаг 2.

2) пришем тесты.
Если проверку можно вставить в sisyphus_check, 
ее нужно пролоббировать в sisyphus_check.
Если нет, то пишем скрипт a'la qa-robots и регулярно спамим им рассылку.
Через какое-то время полиси становится чуть ли не рефлексом :)

Получается что-то вроде Extreme Maintaining :)

Вот и в случае http://www.freesource.info/wiki/Altlinux/Policy/SharedLibs, 
насколько я понял, достаточно в срезе сизифа дампить таблицу
| package name | lib name | soname !
скриптом сравнивать свежий и прошлый дамп 
и скриптом же ругать пакеты и майнтайнеров, 
для которых совпадает package name и lib name, но сменился soname.

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


-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine

Re: [devel] mplayer q (policy howto)

[Led]

2007/11/22, Igor Vlasenko <vlasenko@imath.kiev.ua>:
> On Thu, Nov 22, 2007 at 08:21:52AM +0300, Денис Смирнов wrote:
> > В случае же с другими пакетами это страшно. И скажем я для своих пакетов
> > хотел бы иметь возможность _запретить_ их существование в Сизифе в кривом
> > виде.
>
> Такие возможности в Сизифе есть, ими только нужно пользоваться.
>
> Policy Applying mini-HOWTO.
>
> 1) вычитываем (или пишем, если нет) полиси по нужной теме
> (например,
> http://www.freesource.info/wiki/Altlinux/Policy/SharedLibs)
> с описанием проблем и способом их решения.

Из-за неверной предпосылки:

> С полиси все соглашаются,

Дальше следуют спорные выводы:)

> но мало кто соблюдает.
> Это нормально. Полиси похоже на документацию.
> А кто любит читать документацию?

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

>
> Поэтому нужен шаг 2.
>
> 2) пришем тесты.
> Если проверку можно вставить в sisyphus_check,
> ее нужно пролоббировать в sisyphus_check.
> Если нет, то пишем скрипт a'la qa-robots и регулярно спамим им рассылку.
> Через какое-то время полиси становится чуть ли не рефлексом :)
>
> Получается что-то вроде Extreme Maintaining :)
>
> Вот и в случае http://www.freesource.info/wiki/Altlinux/Policy/SharedLibs,
> насколько я понял, достаточно в срезе сизифа дампить таблицу
> | package name | lib name | soname !
> скриптом сравнивать свежий и прошлый дамп
> и скриптом же ругать пакеты и майнтайнеров,
> для которых совпадает package name и lib name, но сменился soname.

Т.е. ругать нужно мейнтейнеров библиотек, а не мейнтейнеров пакетов,
использующих эти библиотеки, но игнорирующие их обновлени, записи в
багзилле с просьбой пересобрать свой пакет с новой библиотекой. Я
понимаю - лениво... Но эта ленивость - в большинстве является не
здоровым консерватизмом, а внесением дополнительной энтропии и др.
проблем в репозитарий и навешиванием дополнительной работы по
изготовлению и поддержанию дополнительных пакетов (legacy-вариантов
библиотек) на мейнтейнеров библиотек.

> Или если нужна другая проверка, то реализовать именно ее.

ИМХО нужна только одна проверка: при смене сонейма у библиотеки
проверять зависимые от неё пакеты на собираемость, в случае успеха -
вешать major-баги на эти пакеты или пересобирать автоматом/роботом.

-- 
Led.

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 03:07:02PM +0300, Алексей Турбин wrote:

AT> Нельзя решить нерешаемые проблемы.  Я предлагаю просто не паковать
AT> legacy библиотеки, то есть делать вынужденную пересборку всех пакетов
AT> при смене soname'а.  Но если legacy библиотека УЖЕ СТОИТ в системе,
AT> то возможности точечного обновления на свой страх и риск никто не
AT> отнимает (при условии, что, конечно, пакеты с библиотеками называются
AT> по-разному, то есть могут одновременно встать).

Вот это и есть та проблема, которую я хотел решить тестом при попадании
пакета в Сизиф. Изменение soname без изменения %name недопустимо.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
ЗАКОН ШМИДТА
 Если достаточно долго портить машину, она сломается.

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

Re: [devel] mplayer q

[Alexey Tourbin]

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

On Tue, Nov 20, 2007 at 02:45:34PM +0300, Dmitry V. Levin wrote:
> > /me уже хрен знает сколько времени просит чтобы пакет перед попаданием в
> > Сизиф проверялся, и если в пакете с именем N предоставлялась некая либа X,
> > то больше _никогда_ бы в Сизиф не мог попасть пакет с именем N и либой X
> > но другим soname.
> 
> Нет, наверное проще apt исправить чем это сделать.

А каким образом хотелось бы apt исправить?

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

Re: [devel] mplayer q

[Денис Смирнов]

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

On Tue, Nov 20, 2007 at 11:00:34AM +0300, Alexey Gladkov wrote:

>> Специфическая проблема тут в том, что в репозитарии находится две
>> библиотеки libdirectfb.  Я сейчас не хочу пересобирать libcairo
>> с новой библиотекой libdirectfb, чтобы все успели над этой проблемой
>> подумать.
AG> Так как у libdirectfb при _каждом_ релизе меняется API и довольно
AG> часто ABI, я другого способа обновления этой библиотеки в сизифе не
AG> вижу. А именно плавный переезд с версии на верию. Я не имею
AG> возможности лазить по всем проектам, слинкованными с libdirectfb, и
AG> фиксить их под новую библиотеку (если это нужно). Я оставляю эту
AG> работу на совести соотвествующих мантейнеров.
AG> Если какой-либо мантейнер (не будем показывать пальцем, хотя это был
AG> слонёнок) _НЕ_ХОЧЕТ_ обновлять пакет по каким-то своим соображениям,
AG> то я ему не смогу помочь, взяв его работу на себя.

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

Кстати, как у нас с libdb эта проблема решается?

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
"Hello World!" 17 errors, 31 warnings

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

Re: [devel] libdb и apache2 (was: mplayer q)

[Aleksey Avdeev]

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

Денис Смирнов пишет:
> 
> Это не отменяет необходимости решения общей проблемы с бинарниками,
> которые оказываются в результате слинкованы сразу с двумя версиями одной
> библиотеки.
> 
> Кстати, как у нас с libdb эта проблема решается?

  В apache2-common предоставляет Provides вида apache2-libdb с версией
соответствующей libdb, с которой оный apache2 собран. Модули/плагины
собирающиеся с libdb -- имеют зависимость на данный Provides нужной версии.

-- 

С уважением. Алексей.



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