Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> Dear Sisyphus!
> The kernel-image-led-tc-2.6.22-alt23 package has been rejected from
> Sisyphus incoming for i586 architecture.
>
> Possible reason follows:
> Executing(Requires): /bin/sh -e /usr/src/tmp/rpm-tmp.18225
> + umask 022
> + /bin/mkdir -p /usr/src/RPM/BUILD
> + cd /usr/src/RPM/BUILD
> + /usr/lib/rpm/find-requires
> find-requires: empty file list, nothing to do
> + exit 0
> Provides: kernel-doc-led = 2.6.22-alt23
> Requires(rpmlib): rpmlib(VersionedDependencies) <= 3.0.3-1,
> rpmlib(PayloadFilesHavePrefix) <= 4.0-1, rpmlib(CompressedFileNames) <=
> 3.0.4-1 Finding unpackaged files (using /usr/lib/rpm/check-files)
> Executing(check-files): /bin/sh -e /usr/src/tmp/rpm-tmp.85913
> + umask 022
> + /bin/mkdir -p /usr/src/RPM/BUILD
> + cd /usr/src/RPM/BUILD
> + /usr/lib/rpm/check-files
> + exit 0
> Wrote: /usr/src/RPM/RPMS/i586/kernel-image-led-tc-2.6.22-alt23.i586.rpm
> Wrote:
> /usr/src/RPM/RPMS/i586/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm
> Wrote: /usr/src/RPM/RPMS/i586/kernel-headers-led-tc-2.6.22-alt23.i586.rpm
> Wrote:
> /usr/src/RPM/RPMS/i586/kernel-headers-modules-led-tc-2.6.22-alt23.i586.rpm
> Wrote: /usr/src/RPM/RPMS/noarch/kernel-doc-led-tc-2.6.22-alt23.noarch.rpm
> 2142.87user 234.91system 39:58.26elapsed 99%CPU (0avgtext+0avgdata
> 0maxresident)k 0inputs+0outputs (0major+55590551minor)pagefaults 0swaps
> sisyphus_check: check-kernel ERROR: kernel module violation
> /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package RELEASE
> should end with kernel release number

Что это? Почему в этом конкретном случае "package RELEASE should end with 
kernel release number"???

> sisyphus_check: check-kernel ERROR: 
> kernel package violation
> /.out/kernel-headers-led-tc-2.6.22-alt23.i586.rpm: package GROUP should be
> 'Development/Kernel' sisyphus_check: check-kernel ERROR: kernel package
> violation
> /.out/kernel-headers-modules-led-tc-2.6.22-alt23.i586.rpm: package GROUP
> should be 'Development/Kernel' hsh-rebuild:
> kernel-image-led-tc-2.6.22-alt23.src.rpm: sisyphus_check failed.

По этим пунктам вопросов нет.

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
> On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> > Dear Sisyphus!

Мне нравится такое обращение. ;)

> > The kernel-image-led-tc-2.6.22-alt23 package has been rejected from
> > Sisyphus incoming for i586 architecture.
[...]
> > sisyphus_check: check-kernel ERROR: kernel module violation

Это результат работы новой проверки в sisyphus_check, описание см.
http://git.altlinux.org/people/ldv/packages/?p=sisyphus_check.git;a=commit;h=1f06218654082cb6e3a6c30865eedfb27257369a

> > /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package RELEASE
> > should end with kernel release number
> 
> Что это? Почему в этом конкретном случае "package RELEASE should end with 
> kernel release number"???

Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
Почему-то раньше это правило распространялось только на сторонние модули.

Впрочем, если есть совместное желание продлить действие этого исключения,
то давайте зафиксируем этот факт и адаптируем sisyphus_check.

> > sisyphus_check: check-kernel ERROR: 
> > kernel package violation
> > /.out/kernel-headers-led-tc-2.6.22-alt23.i586.rpm: package GROUP should be
> > 'Development/Kernel' sisyphus_check: check-kernel ERROR: kernel package
> > violation
> > /.out/kernel-headers-modules-led-tc-2.6.22-alt23.i586.rpm: package GROUP
> > should be 'Development/Kernel' hsh-rebuild:
> > kernel-image-led-tc-2.6.22-alt23.src.rpm: sisyphus_check failed.
> 
> По этим пунктам вопросов нет.

Да, пожалуй что kernel-headers-* и /kernel-headers-modules-* это
Development/Kernel.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
> On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
> > On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> > > Dear Sisyphus!
>
> Мне нравится такое обращение. ;)
>
> > > The kernel-image-led-tc-2.6.22-alt23 package has been rejected from
> > > Sisyphus incoming for i586 architecture.
>
> [...]
>
> > > sisyphus_check: check-kernel ERROR: kernel module violation
>
> Это результат работы новой проверки в sisyphus_check, описание см.
> http://git.altlinux.org/people/ldv/packages/?p=sisyphus_check.git;a=commit;
>h=1f06218654082cb6e3a6c30865eedfb27257369a
>
> > > /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package RELEASE
> > > should end with kernel release number
> >
> > Что это? Почему в этом конкретном случае "package RELEASE should end with
> > kernel release number"???
>
> Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
> специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> Почему-то раньше это правило распространялось только на сторонние модули.
>
> Впрочем, если есть совместное желание продлить действие этого исключения,
> то давайте зафиксируем этот факт и адаптируем sisyphus_check.

ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после этого 
принимать решение (если kernel-image-*, то никакой ошибки в релизе нет).

>
> > > sisyphus_check: check-kernel ERROR:
> > > kernel package violation
> > > /.out/kernel-headers-led-tc-2.6.22-alt23.i586.rpm: package GROUP should
> > > be 'Development/Kernel' sisyphus_check: check-kernel ERROR: kernel
> > > package violation
> > > /.out/kernel-headers-modules-led-tc-2.6.22-alt23.i586.rpm: package
> > > GROUP should be 'Development/Kernel' hsh-rebuild:
> > > kernel-image-led-tc-2.6.22-alt23.src.rpm: sisyphus_check failed.
> >
> > По этим пунктам вопросов нет.
>
> Да, пожалуй что kernel-headers-* и /kernel-headers-modules-* это
> Development/Kernel.

Всё верно. Поэтому и "вопросов нет":)

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 04:01:45AM +0300, Led wrote:
> On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
> > On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
> > > On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
[...]
> > > > /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package RELEASE
> > > > should end with kernel release number
> > >
> > > Что это? Почему в этом конкретном случае "package RELEASE should end with
> > > kernel release number"???
> >
> > Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
> > специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> > Почему-то раньше это правило распространялось только на сторонние модули.
> >
> > Впрочем, если есть совместное желание продлить действие этого исключения,
> > то давайте зафиксируем этот факт и адаптируем sisyphus_check.
> 
> ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после этого 
> принимать решение (если kernel-image-*, то никакой ошибки в релизе нет).

Просьба всем, кто собирает kernel-image'ы, быстренько высказать своё мнение
по этой теме.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Михаил Якушин]

Dmitry V. Levin wrote:
> On Wed, Oct 01, 2008 at 04:01:45AM +0300, Led wrote:
>> On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
>>> On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
>>>> On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> [...]
>>>>> /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package RELEASE
>>>>> should end with kernel release number
>>>> Что это? Почему в этом конкретном случае "package RELEASE should end with
>>>> kernel release number"???
>>> Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
>>> специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
>>> Почему-то раньше это правило распространялось только на сторонние модули.
>>>
>>> Впрочем, если есть совместное желание продлить действие этого исключения,
>>> то давайте зафиксируем этот факт и адаптируем sisyphus_check.
>> ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после этого 
>> принимать решение (если kernel-image-*, то никакой ошибки в релизе нет).
> 
> Просьба всем, кто собирает kernel-image'ы, быстренько высказать своё мнение
> по этой теме.
Я тоже наступил на эту проблему. Сначала, я пытался сделать там 
правильный релиз, но не добившись желаемого результата, подумал  о том, 
а не выкинуть ли OSS драйверы из наших ядер. Опросив народ в sisyphus и 
hardware пришёл к выводу, что таки выкинуть.
Итого: имхо пусть остаёться как есть, потому что OSS не нужен.

Если кто-то скажет приведёт пример где нужен OSS, будем  думать.

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 07:26:01 Михаил Якушин wrote:
> Dmitry V. Levin wrote:
> > On Wed, Oct 01, 2008 at 04:01:45AM +0300, Led wrote:
> >> On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
> >>> On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
> >>>> On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> >
> > [...]
> >
> >>>>> /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package
> >>>>> RELEASE should end with kernel release number
> >>>>
> >>>> Что это? Почему в этом конкретном случае "package RELEASE should end
> >>>> with kernel release number"???
> >>>
> >>> Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
> >>> специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> >>> Почему-то раньше это правило распространялось только на сторонние
> >>> модули.
> >>>
> >>> Впрочем, если есть совместное желание продлить действие этого
> >>> исключения, то давайте зафиксируем этот факт и адаптируем
> >>> sisyphus_check.
> >>
> >> ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после этого
> >> принимать решение (если kernel-image-*, то никакой ошибки в релизе нет).
> >
> > Просьба всем, кто собирает kernel-image'ы, быстренько высказать своё
> > мнение по этой теме.
>
> Я тоже наступил на эту проблему. Сначала, я пытался сделать там
> правильный релиз, но не добившись желаемого результата, подумал  о том,
> а не выкинуть ли OSS драйверы из наших ядер. Опросив народ в sisyphus и
> hardware пришёл к выводу, что таки выкинуть.
> Итого: имхо пусть остаёться как есть, потому что OSS не нужен.
>
> Если кто-то скажет приведёт пример где нужен OSS, будем  думать.

OSS нужен или не нужен - это отдельный вопрос. А вдруг завтра понадобится 
kernel-modules-{alsa,drm,v4l,etc} собираемые из kernel-image?
Разложим старательно грабли на будущее? Может их сразу убрать, пока не забыли, 
где они лежат и то место не заросло травой?

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Михаил Якушин]

Led wrote:
> On Wednesday, 01 October 2008 07:26:01 Михаил Якушин wrote:
>> Dmitry V. Levin wrote:
>>> On Wed, Oct 01, 2008 at 04:01:45AM +0300, Led wrote:
>>>> On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
>>>>> On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
>>>>>> On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
>>> [...]
>>>
>>>>>>> /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package
>>>>>>> RELEASE should end with kernel release number
>>>>>> Что это? Почему в этом конкретном случае "package RELEASE should end
>>>>>> with kernel release number"???
>>>>> Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
>>>>> специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
>>>>> Почему-то раньше это правило распространялось только на сторонние
>>>>> модули.
>>>>>
>>>>> Впрочем, если есть совместное желание продлить действие этого
>>>>> исключения, то давайте зафиксируем этот факт и адаптируем
>>>>> sisyphus_check.
>>>> ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после этого
>>>> принимать решение (если kernel-image-*, то никакой ошибки в релизе нет).
>>> Просьба всем, кто собирает kernel-image'ы, быстренько высказать своё
>>> мнение по этой теме.
>> Я тоже наступил на эту проблему. Сначала, я пытался сделать там
>> правильный релиз, но не добившись желаемого результата, подумал  о том,
>> а не выкинуть ли OSS драйверы из наших ядер. Опросив народ в sisyphus и
>> hardware пришёл к выводу, что таки выкинуть.
>> Итого: имхо пусть остаёться как есть, потому что OSS не нужен.
>>
>> Если кто-то скажет приведёт пример где нужен OSS, будем  думать.
> 
> OSS нужен или не нужен - это отдельный вопрос. А вдруг завтра понадобится 
> kernel-modules-{alsa,drm,v4l,etc} собираемые из kernel-image?
> Разложим старательно грабли на будущее? Может их сразу убрать, пока не забыли, 
> где они лежат и то место не заросло травой?
> 
Грабля ли это?
Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы. 
А откуда они собираются не важно.
Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 07:42:53 Михаил Якушин wrote:
> Led wrote:
> > On Wednesday, 01 October 2008 07:26:01 Михаил Якушин wrote:
> >> Dmitry V. Levin wrote:
> >>> On Wed, Oct 01, 2008 at 04:01:45AM +0300, Led wrote:
> >>>> On Wednesday, 01 October 2008 03:51:21 Dmitry V. Levin wrote:
> >>>>> On Wed, Oct 01, 2008 at 03:38:15AM +0300, Led wrote:
> >>>>>> On Wednesday, 01 October 2008 03:17:03 QA Team Upravdom Robot wrote:
> >>>
> >>> [...]
> >>>
> >>>>>>> /.out/kernel-modules-oss-led-tc-2.6.22-alt23.i586.rpm: package
> >>>>>>> RELEASE should end with kernel release number
> >>>>>>
> >>>>>> Что это? Почему в этом конкретном случае "package RELEASE should end
> >>>>>> with kernel release number"???
> >>>>>
> >>>>> Считается, что имя релиза пакета kernel-modules-что-то-там должно
> >>>>> иметь специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> >>>>> Почему-то раньше это правило распространялось только на сторонние
> >>>>> модули.
> >>>>>
> >>>>> Впрочем, если есть совместное желание продлить действие этого
> >>>>> исключения, то давайте зафиксируем этот факт и адаптируем
> >>>>> sisyphus_check.
> >>>>
> >>>> ИМХО нужно всего-лишь проверять ещё и %{SOURCERPM} и только после
> >>>> этого принимать решение (если kernel-image-*, то никакой ошибки в
> >>>> релизе нет).
> >>>
> >>> Просьба всем, кто собирает kernel-image'ы, быстренько высказать своё
> >>> мнение по этой теме.
> >>
> >> Я тоже наступил на эту проблему. Сначала, я пытался сделать там
> >> правильный релиз, но не добившись желаемого результата, подумал  о том,
> >> а не выкинуть ли OSS драйверы из наших ядер. Опросив народ в sisyphus и
> >> hardware пришёл к выводу, что таки выкинуть.
> >> Итого: имхо пусть остаёться как есть, потому что OSS не нужен.
> >>
> >> Если кто-то скажет приведёт пример где нужен OSS, будем  думать.
> >
> > OSS нужен или не нужен - это отдельный вопрос. А вдруг завтра понадобится
> > kernel-modules-{alsa,drm,v4l,etc} собираемые из kernel-image?
> > Разложим старательно грабли на будущее? Может их сразу убрать, пока не
> > забыли, где они лежат и то место не заросло травой?
>
> Грабля ли это?
> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.

Сорри, я пропустил этот момент, когда ВЫ это решили.

> А откуда они собираются не важно.
> Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?

Странно, что вы это спрашиваете. В том-то и дело, что НЕТ.

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Михаил Якушин]

Led wrote:
[skip]
>> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.
> 
> Сорри, я пропустил этот момент, когда ВЫ это решили.
Про модули релиши уже давно. Насколько я понял ещё при vsu@.  Может быть 
я не прав.
Видимо пора оформлять kernel policy.
>> А откуда они собираются не важно.
>> Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?
> 
> Странно, что вы это спрашиваете. В том-то и дело, что НЕТ.
> 

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

kernel-image
Release: altn

kernel-modules
Release: altn.blablabla

kernel-headers
Release: altn

kernel-headers-modules

Собирается:
kernel-image-*altn
kerhel-modules-*altn.blablabla
kernel-headers-*-altn.blabla
kernel-headers-modules-*altn

Почему kernel-headers собирается с неправильным релизом так и не понял.

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 08:25:57 Михаил Якушин wrote:
> Led wrote:
> [skip]
>
> >> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.
> >
> > Сорри, я пропустил этот момент, когда ВЫ это решили.
>
> Про модули релиши уже давно. Насколько я понял ещё при vsu@.

Так решили про ВНЕШНИЕ модули.

> Может быть 
> я не прав.

Да.

> Видимо пора оформлять kernel policy.

Может стОит его просто внимательно читать?:)

>
> >> А откуда они собираются не важно.
> >> Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?
> >
> > Странно, что вы это спрашиваете. В том-то и дело, что НЕТ.
>
> Вот как не странно, это не совсем так, и у меня это почти вышло. Дело в
> том что можно второй раз указать релиз в spec, Но все последующие пакеты
> в спеке тоже меняют релиз, поэтому релиз приходиться менять обратно.

Не стОит мне "читать вслух" "букварь" - я его уже прочитал:)

> Всё 
> бы было хорошо, но оно как то странно отрабатывает, и релиз меняется не
> с указаного пакета а со следующего.
> Тоесть 
>
> kernel-image
> Release: altn
>
> kernel-modules
> Release: altn.blablabla
>
> kernel-headers
> Release: altn
>
> kernel-headers-modules
>
> Собирается:
> kernel-image-*altn
> kerhel-modules-*altn.blablabla
> kernel-headers-*-altn.blabla
> kernel-headers-modules-*altn
>
> Почему kernel-headers собирается с неправильным релизом так и не понял.

Не нужно забивать голову ерундой. Нужно просто поправить кривой 
sisyphus_check. Не убрать эту проверку (которая предназначна для ВНЕШНИХ 
модулей), а именно ПОПРАВИТЬ.

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Михаил!

Wednesday 01, at 09:25:57 AM you wrote:

> Led wrote:
> [skip]
> >> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.
> > 
> > Сорри, я пропустил этот момент, когда ВЫ это решили.
> Про модули релиши уже давно. Насколько я понял ещё при vsu@.  Может быть 
> я не прав.
> Видимо пора оформлять kernel policy.
Отучаемся говорить за всех. Миша, на роль vsu@ ты пока мягко говоря не
тянешь ;)

> >> А откуда они собираются не важно.
> >> Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?
> > 
> > Странно, что вы это спрашиваете. В том-то и дело, что НЕТ.
> > 
> 
> Вот как не странно, это не совсем так, и у меня это почти вышло. Дело в 
> том что можно второй раз указать релиз в spec, Но все последующие пакеты 
> в спеке тоже меняют релиз, поэтому релиз приходиться менять обратно. Всё 
> бы было хорошо, но оно как то странно отрабатывает, и релиз меняется не 
> с указаного пакета а со следующего. Тоесть
Для sisyphus_check уже есть исправление, надеюсь оно скоро попадет в
сизиф.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Михаил Якушин]

Konstantin A. Lepikhov wrote:
> Hi Михаил!
> 
> Wednesday 01, at 09:25:57 AM you wrote:
> 
>> Led wrote:
>> [skip]
>>>> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.
>>> Сорри, я пропустил этот момент, когда ВЫ это решили.
>> Про модули релиши уже давно. Насколько я понял ещё при vsu@.  Может быть 
>> я не прав.
>> Видимо пора оформлять kernel policy.
> Отучаемся говорить за всех. Миша, на роль vsu@ ты пока мягко говоря не
> тянешь ;)
А я и не пытаюсь тянуть. Я действительно считал что это так для всех 
модулей. И почти сутки воевал с specом
чтобы пропихнуть oss через этот sisyphus_check

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Михаил!

Wednesday 01, at 09:52:18 AM you wrote:

> Konstantin A. Lepikhov wrote:
> > Hi Михаил!
> > 
> > Wednesday 01, at 09:25:57 AM you wrote:
> > 
> >> Led wrote:
> >> [skip]
> >>>> Сторго говоря, мы решили, что у ВСЕХ модулей, должны быть такие релизы.
> >>> Сорри, я пропустил этот момент, когда ВЫ это решили.
> >> Про модули релиши уже давно. Насколько я понял ещё при vsu@.  Может быть 
> >> я не прав.
> >> Видимо пора оформлять kernel policy.
> > Отучаемся говорить за всех. Миша, на роль vsu@ ты пока мягко говоря не
> > тянешь ;)
> А я и не пытаюсь тянуть. Я действительно считал что это так для всех 
> модулей. И почти сутки воевал с specом
> чтобы пропихнуть oss через этот sisyphus_check
Если что непонятно, надо спрашивать. Собственно, заинтересованность в
решении этого вопроса я увидел только у ldv@ и legion@, остальные
типа-сборщики-крутых-ядер как всегда решили отмолчаться по углам.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 07:59:16AM +0300, Led wrote:
> On Wednesday, 01 October 2008 07:42:53 Михаил Якушин wrote:
[...]
> > Другой вопрос в том, можно ли иметь несколько релизов на один SRPM?
> 
> Странно, что вы это спрашиваете. В том-то и дело, что НЕТ.

Синтаксис rpm позволяет делать такие spec-файлы.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Синтаксис rpm позволяет делать такие spec-файлы.

А фактически это реально ? :)

-- 
Rgrds, legion

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 03:03:59PM +0400, Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> >Синтаксис rpm позволяет делать такие spec-файлы.
> 
> А фактически это реально ? :)

Фактически реально получить неправильную нумерацию релизов подпакетов.
Слишком легко сделать ошибку.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Wednesday 01, at 03:07:50 PM you wrote:

> On Wed, Oct 01, 2008 at 03:03:59PM +0400, Alexey Gladkov wrote:
> > Dmitry V. Levin wrote:
> > >Синтаксис rpm позволяет делать такие spec-файлы.
> > 
> > А фактически это реально ? :)
> 
> Фактически реально получить неправильную нумерацию релизов подпакетов.
> Слишком легко сделать ошибку.
Из того, что получилось у меня, релизы субпакетов стали правильными, но
изменился общий релиз _всего_ пакета. Т.е. в этом случае пришлось бы от
него избавляться. Если наш rpm научится и это (переопределение релиза для
%package и только в рамках этого %package), то, конечно, эту проверку
%можно вернуть.

Кстати, насчет проверок. Есть мысль закрутить гайки совсем, т.е.
обеспечить возможность непропускания пакетов, не собранных из kernel
module template + ядер, собранных непонятно-как.

Проверки для модулей (в дополнение к текущим)

1) Наличие build-requires(pre): rpm-build-kernel (для src.rpm).
2) Наличие в src.rpm
Provides:  kernel-modules-%module_name-%kversion-%flavour-%krelease =
%version-%release                                                                       
Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease <
%version-%release                                                                       
Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease >
%version-%release
3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)
4) Наличие Requires(postun): kernel-image-%flavour = %kversion-%krelease в
src.rpm
5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
athlon или pentium4) + ExclusiveOS:    Linux
6) Наличие содержимого %post_kernel_modules в %post/%postun.
7) %defattr(644,root,root,755) для модулей/директорий с модулями
8) проверка что модули лежат в
/lib/modules/%kversion-%flavour-%krelease/%module_name (если они
собираются отдельно) + там кроме *.ko ничего нет.

Для ядер я напишу чуть позже отдельным письмом.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
[...]
> Кстати, насчет проверок. Есть мысль закрутить гайки совсем, т.е.
> обеспечить возможность непропускания пакетов, не собранных из kernel
> module template + ядер, собранных непонятно-как.
> 
> Проверки для модулей (в дополнение к текущим)
> 
> 1) Наличие build-requires(pre): rpm-build-kernel (для src.rpm).

К сожалению, в src.rpm buildrequires(pre) ничем не отличается от
buildrequires, а sisyphus_check работает именно с rpm-пакетами, а не со
spec-файлами.  Так что максимум, что можно здесь проверить -- это наличие
зависимости src.rpm-пакета от rpm-build-kernel.

> 2) Наличие в src.rpm
> Provides:  kernel-modules-%module_name-%kversion-%flavour-%krelease =
> %version-%release                                                                       
> Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease <
> %version-%release                                                                       
> Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease >
> %version-%release

Это можно добавить.
Кстати, кто-нибудь помнит, зачем нужны эти provides/conflicts?

> 3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)

Наш rpm теперь порождает prereq'и сам, coreutils туда точно вносить не
надо.

> 4) Наличие Requires(postun): kernel-image-%flavour = %kversion-%krelease в
> src.rpm

Это можно добавить.

> 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
> athlon или pentium4) + ExclusiveOS:    Linux

Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
архитектуру в ExclusiveArch?
Что касается "ExclusiveOS: linux", то мне кажется, что от присутствия или
отсутствия этого тэга ничего не изменится.

> 6) Наличие содержимого %post_kernel_modules в %post/%postun.

Это можно добавить.

> 7) %defattr(644,root,root,755) для модулей/директорий с модулями

%defattr сложно проверить; можно проверять права доступа
на сами каталоги с файлами.

> 8) проверка что модули лежат в
> /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
> собираются отдельно) + там кроме *.ko ничего нет.

Тут могут возникнуть проблемы.  Например, в пакете
kernel-modules-nvidia есть что-то похожее на переключатель модулей.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Так что максимум, что можно здесь проверить -- это наличие
> зависимости src.rpm-пакета от rpm-build-kernel.

В принципе этого достаточно.

> Это можно добавить.
> Кстати, кто-нибудь помнит, зачем нужны эти provides/conflicts?

Совместимость с какой-нибудь старой схемой именования?

>> 4) Наличие Requires(postun): kernel-image-%flavour = %kversion-%krelease в
>> src.rpm
> 
> Это можно добавить.

Это уже есть. Даже уже в сизифе.

>> 6) Наличие содержимого %post_kernel_modules в %post/%postun.
> 
> Это можно добавить.

А как это проверить ?

>> 7) %defattr(644,root,root,755) для модулей/директорий с модулями
> 
> %defattr сложно проверить; можно проверять права доступа
> на сами каталоги с файлами.

Это дорогая проверка.

>> 8) проверка что модули лежат в
>> /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
>> собираются отдельно) + там кроме *.ko ничего нет.
> 
> Тут могут возникнуть проблемы.  Например, в пакете
> kernel-modules-nvidia есть что-то похожее на переключатель модулей.

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

-- 
Rgrds, legion

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Wednesday 01, at 06:09:54 PM you wrote:

> On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
> [...]
> > Кстати, насчет проверок. Есть мысль закрутить гайки совсем, т.е.
> > обеспечить возможность непропускания пакетов, не собранных из kernel
> > module template + ядер, собранных непонятно-как.
> > 
> > Проверки для модулей (в дополнение к текущим)
> > 
> > 1) Наличие build-requires(pre): rpm-build-kernel (для src.rpm).
> 
> К сожалению, в src.rpm buildrequires(pre) ничем не отличается от
> buildrequires, а sisyphus_check работает именно с rpm-пакетами, а не со
> spec-файлами.  Так что максимум, что можно здесь проверить -- это наличие
> зависимости src.rpm-пакета от rpm-build-kernel.
хотя бы так.

> 
> > 2) Наличие в src.rpm
> > Provides:  kernel-modules-%module_name-%kversion-%flavour-%krelease =
> > %version-%release                                                                       
> > Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease <
> > %version-%release                                                                       
> > Conflicts: kernel-modules-%module_name-%kversion-%flavour-%krelease >
> > %version-%release
> 
> Это можно добавить.
> Кстати, кто-нибудь помнит, зачем нужны эти provides/conflicts?
Для того, чтобы исключить возможность установки нескольких версией одного
и того же модуля для одного ядра.

> 
> > 3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)
> 
> Наш rpm теперь порождает prereq'и сам, coreutils туда точно вносить не
> надо.
Значит, в templates это можно убирать?

<skip>
> > 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
> > athlon или pentium4) + ExclusiveOS:    Linux
> 
> Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
> архитектуру в ExclusiveArch?
в модуле ядра не может быть конфигураций для неподдерживаемых архитектур
ядра. Пока ядра у нас собираются на i586 и x86_64 и репозитория для
athlon/pentium4 у нас нет.

> Что касается "ExclusiveOS: linux", то мне кажется, что от присутствия или
> отсутствия этого тэга ничего не изменится.
Это защита от дурака, как и предыдущие проверки.

> 
> > 6) Наличие содержимого %post_kernel_modules в %post/%postun.
> 
> Это можно добавить.
> 
> > 7) %defattr(644,root,root,755) для модулей/директорий с модулями
> 
> %defattr сложно проверить; можно проверять права доступа
> на сами каталоги с файлами.
ага.

> 
> > 8) проверка что модули лежат в
> > /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
> > собираются отдельно) + там кроме *.ko ничего нет.
> 
> Тут могут возникнуть проблемы.  Например, в пакете
> kernel-modules-nvidia есть что-то похожее на переключатель модулей.
меня давно интересовало, зачем _это_ засовывать в kernel-modules, да еще и
в /var/lib

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Aleksey Avdeev]

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

Konstantin A. Lepikhov пишет:
> Hi Dmitry!
> 
> Wednesday 01, at 06:09:54 PM you wrote:
> 
>> On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
...
>>> 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
>>> athlon или pentium4) + ExclusiveOS:    Linux
>> Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
>> архитектуру в ExclusiveArch?
> в модуле ядра не может быть конфигураций для неподдерживаемых архитектур
> ядра. Пока ядра у нас собираются на i586 и x86_64 и репозитория для
> athlon/pentium4 у нас нет.

   Почему это должно мешать собирать ядра/модули под не поддерживаемую 
архитектуру локально?

-- 

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



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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 07:11:12PM +0400, Konstantin A. Lepikhov wrote:
> Wednesday 01, at 06:09:54 PM you wrote:
> > On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
[...]
> > > 3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)
> > 
> > Наш rpm теперь порождает prereq'и сам, coreutils туда точно вносить не
> > надо.
> Значит, в templates это можно убирать?

coreutils точно можно убирать.

> <skip>
> > > 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
> > > athlon или pentium4) + ExclusiveOS:    Linux
> > 
> > Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
> > архитектуру в ExclusiveArch?
> в модуле ядра не может быть конфигураций для неподдерживаемых архитектур
> ядра.

Почему?  С точки зрения пакета в репозитории, какой может быть вред от
поддержки в пакете архитектур, неподдерживаемых в репозитории?
Это ограничение осложнит расширение списка поддерживаемых архитектур
(типа ppc).

> Пока ядра у нас собираются на i586 и x86_64 и репозитория для
> athlon/pentium4 у нас нет.
> 
> > Что касается "ExclusiveOS: linux", то мне кажется, что от присутствия или
> > отсутствия этого тэга ничего не изменится.
> Это защита от дурака, как и предыдущие проверки.

Тэг "ExclusiveOS: linux" нужен для того, чтобы сборка не прошла,
если OS != linux.  Неужели эта защита нам важна?

> > > 8) проверка что модули лежат в
> > > /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
> > > собираются отдельно) + там кроме *.ko ничего нет.
> > 
> > Тут могут возникнуть проблемы.  Например, в пакете
> > kernel-modules-nvidia есть что-то похожее на переключатель модулей.
> меня давно интересовало, зачем _это_ засовывать в kernel-modules, да еще и
> в /var/lib

Это лучше пусть расскажет мантейнер kernel-modules-nvidia.


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Wednesday 01, at 07:44:52 PM you wrote:

> On Wed, Oct 01, 2008 at 07:11:12PM +0400, Konstantin A. Lepikhov wrote:
> > Wednesday 01, at 06:09:54 PM you wrote:
> > > On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
> [...]
> > > > 3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)
> > > 
> > > Наш rpm теперь порождает prereq'и сам, coreutils туда точно вносить не
> > > надо.
> > Значит, в templates это можно убирать?
> 
> coreutils точно можно убирать.
> 
> > <skip>
> > > > 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
> > > > athlon или pentium4) + ExclusiveOS:    Linux
> > > 
> > > Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
> > > архитектуру в ExclusiveArch?
> > в модуле ядра не может быть конфигураций для неподдерживаемых архитектур
> > ядра.
> 
> Почему?  С точки зрения пакета в репозитории, какой может быть вред от
> поддержки в пакете архитектур, неподдерживаемых в репозитории?
> Это ограничение осложнит расширение списка поддерживаемых архитектур
> (типа ppc).
Я не видел еще ядер с поддержкой ppc (пусть даже опционально) в сизифе.
Т.е. мы говорим о том, чего нет.

> 
> > Пока ядра у нас собираются на i586 и x86_64 и репозитория для
> > athlon/pentium4 у нас нет.
> > 
> > > Что касается "ExclusiveOS: linux", то мне кажется, что от присутствия или
> > > отсутствия этого тэга ничего не изменится.
> > Это защита от дурака, как и предыдущие проверки.
> 
> Тэг "ExclusiveOS: linux" нужен для того, чтобы сборка не прошла,
> если OS != linux.  Неужели эта защита нам важна?
Неужели мне или тебе нужны эти защиты? :)

> 
> > > > 8) проверка что модули лежат в
> > > > /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
> > > > собираются отдельно) + там кроме *.ko ничего нет.
> > > 
> > > Тут могут возникнуть проблемы.  Например, в пакете
> > > kernel-modules-nvidia есть что-то похожее на переключатель модулей.
> > меня давно интересовало, зачем _это_ засовывать в kernel-modules, да еще и
> > в /var/lib
> 
> Это лучше пусть расскажет мантейнер kernel-modules-nvidia.
мантейнер прячется в кусты с дешевыми отмазками. У меня, например, после
его "переключения" стабильно слетают ссылки на драйвера _xorg_ при
обновлении _ядра_.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Thu, Oct 02, 2008 at 01:09:19AM +0400, Konstantin A. Lepikhov wrote:
> Wednesday 01, at 07:44:52 PM you wrote:
> > On Wed, Oct 01, 2008 at 07:11:12PM +0400, Konstantin A. Lepikhov wrote:
> > > Wednesday 01, at 06:09:54 PM you wrote:
> > > > On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
> > [...]
> > > > > 3) Наличие все дополнительных prereq в src.rpm (coreutils,kernel-image)
> > > > 
> > > > Наш rpm теперь порождает prereq'и сам, coreutils туда точно вносить не
> > > > надо.
> > > Значит, в templates это можно убирать?
> > 
> > coreutils точно можно убирать.
> > 
> > > <skip>
> > > > > 5) Наличие ExclusiveArch (+ там не должно быть левых архитектур типа
> > > > > athlon или pentium4) + ExclusiveOS:    Linux
> > > > 
> > > > Если в пакете есть конфиг для athlon или pentium4, то зачем запрещать эту
> > > > архитектуру в ExclusiveArch?
> > > в модуле ядра не может быть конфигураций для неподдерживаемых архитектур
> > > ядра.
> > 
> > Почему?  С точки зрения пакета в репозитории, какой может быть вред от
> > поддержки в пакете архитектур, неподдерживаемых в репозитории?
> > Это ограничение осложнит расширение списка поддерживаемых архитектур
> > (типа ppc).
> Я не видел еще ядер с поддержкой ppc (пусть даже опционально) в сизифе.
> Т.е. мы говорим о том, чего нет.

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

> > > Пока ядра у нас собираются на i586 и x86_64 и репозитория для
> > > athlon/pentium4 у нас нет.
> > > 
> > > > Что касается "ExclusiveOS: linux", то мне кажется, что от присутствия или
> > > > отсутствия этого тэга ничего не изменится.
> > > Это защита от дурака, как и предыдущие проверки.
> > 
> > Тэг "ExclusiveOS: linux" нужен для того, чтобы сборка не прошла,
> > если OS != linux.  Неужели эта защита нам важна?
> Неужели мне или тебе нужны эти защиты? :)

Стоп.  Я думаю, что ExclusiveOS не нужен, с одной стороны, и его наличие
ничему не повредит, с другой стороны.  Разновидность балласта.  Вопрос,
следует ли считать такой балласт ошибкой?

> > > > > 8) проверка что модули лежат в
> > > > > /lib/modules/%kversion-%flavour-%krelease/%module_name (если они
> > > > > собираются отдельно) + там кроме *.ko ничего нет.
> > > > 
> > > > Тут могут возникнуть проблемы.  Например, в пакете
> > > > kernel-modules-nvidia есть что-то похожее на переключатель модулей.
> > > меня давно интересовало, зачем _это_ засовывать в kernel-modules, да еще и
> > > в /var/lib
> > 
> > Это лучше пусть расскажет мантейнер kernel-modules-nvidia.
> мантейнер прячется в кусты с дешевыми отмазками. У меня, например, после
> его "переключения" стабильно слетают ссылки на драйвера _xorg_ при
> обновлении _ядра_.

Единственное, что мне точно известно -- это факт наличия в пакете
kernel-modules-nvidia-что-то-там модулей nvidia нескольких версий.
Вероятно, реализован какой-то механизм переключения версий, но
интересно было бы узнать, как именно он задуман работать?


-- 
ldv

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Dmitry!

Thursday 02, at 01:38:49 AM you wrote:

<skip>
> Я говорю о том, для чего мы делаем дополнительные проверки.
> Я полагаю, что мы их делаем для того, чтобы снизить вероятность ошибки
> упаковки.
> Так вот, проверка на ExclusiveArch с этой точки зрения бесполезная.
Это проверка, что пакующий может отличить ExclusiveArch от Arch. С этой
точки она небесполезная.

<skip>
> > > Тэг "ExclusiveOS: linux" нужен для того, чтобы сборка не прошла,
> > > если OS != linux.  Неужели эта защита нам важна?
> > Неужели мне или тебе нужны эти защиты? :)
> 
> Стоп.  Я думаю, что ExclusiveOS не нужен, с одной стороны, и его наличие
> ничему не повредит, с другой стороны.  Разновидность балласта.  Вопрос,
> следует ли считать такой балласт ошибкой?
Ошибкой, что его нет, или что он содержит неверные данные? Имхо последний
вреднее %)

<skip>
> Единственное, что мне точно известно -- это факт наличия в пакете
> kernel-modules-nvidia-что-то-там модулей nvidia нескольких версий.
модулей _разных_ версий, под лавкой "наипоследней" версии. Это не просто
рассадник багов упаковки, а просто цветник :)

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey Vlasov]

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

On Thu, Oct 02, 2008 at 01:51:00AM +0400, Konstantin A. Lepikhov wrote:
> > Единственное, что мне точно известно -- это факт наличия в пакете
> > kernel-modules-nvidia-что-то-там модулей nvidia нескольких версий.
> модулей _разных_ версий, под лавкой "наипоследней" версии. Это не просто
> рассадник багов упаковки, а просто цветник :)

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

У fglrx такой проблемы нет - с одной стороны, драйвер fglrx при
несоответствии версии модуля fglrx.ko способен запуститься хотя бы в
режиме 2D, с другой стороны, в последней версии этого драйвера пока
поддерживаются все карты >= R300.  Правда, в текущем варианте
получается, что при загрузке со старым ядром, для которого была
собрана другая версия fglrx.ko, 3D не будет (в случае nvidia
произойдёт переключение на нужную версию nvidia_glx).

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 12:49:36 PM you wrote:

> On Thu, Oct 02, 2008 at 01:51:00AM +0400, Konstantin A. Lepikhov wrote:
> > > Единственное, что мне точно известно -- это факт наличия в пакете
> > > kernel-modules-nvidia-что-то-там модулей nvidia нескольких версий.
> > модулей _разных_ версий, под лавкой "наипоследней" версии. Это не просто
> > рассадник багов упаковки, а просто цветник :)
> 
> Проблема в том, что "наипоследняя" версия не работает со старыми
> устройствами - для них нужны более старые версии модуля; из-за этого
> и приходится городить переключатель.  Переименовывать модули вроде
> бы тоже нельзя, так что приходится делать nvidia.ko симлинком на
> нужную версию.
Вообще старые устройства, которые не поддерживаются, обслуживаются
отдельным приложением nvidia_legacy. Зачем пихать все модули в одну
кучу и потом городить переключатели?

> 
> У fglrx такой проблемы нет - с одной стороны, драйвер fglrx при
> несоответствии версии модуля fglrx.ko способен запуститься хотя бы в
> режиме 2D, с другой стороны, в последней версии этого драйвера пока
> поддерживаются все карты >= R300.  Правда, в текущем варианте
> получается, что при загрузке со старым ядром, для которого была
> собрана другая версия fglrx.ko, 3D не будет (в случае nvidia
> произойдёт переключение на нужную версию nvidia_glx).
А смысл прыганья между ядрами? В сизифе всегда есть только одно ядро и
один комплект драйверов.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> Вообще старые устройства, которые не поддерживаются,
> обслуживаются отдельным приложением nvidia_legacy.
> Зачем пихать
> все модули в одну кучу и потом городить переключатели?
В них содержится это волшебное "отдельное приложение nvidia_legacy"

[...]
> А смысл прыганья между ядрами?
> В сизифе всегда есть только одно ядро
Версию-релиз пакета назови. Я тоже такое хочу -- одно на всю жизнь.

> и один комплект драйверов.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey Vlasov]

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

On Thu, Oct 02, 2008 at 01:31:41PM +0400, Konstantin A. Lepikhov wrote:
> Вообще старые устройства, которые не поддерживаются, обслуживаются
> отдельным приложением nvidia_legacy. Зачем пихать все модули в одну
> кучу и потом городить переключатели?

Как минимум драйвер X переименовать нельзя - модуль должен иметь имя
nvidia (в модуле ищется символ ${name}ModuleData), так что без симлинков
на этом этапе не обойтись (разве что сделать несколько пакетов,
конфликтущих друг с другом, но в этом случае нужно, например, в
инсталяторе делать установку пакетов в зависимости от обнаруженного
железа).  Модули ядра тоже просто так не переименовываются.

> А смысл прыганья между ядрами? В сизифе всегда есть только одно ядро и
> один комплект драйверов.

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

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

[devel] установка пакетов alterator-ом по надобности (was: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23)

[Sergey V Turchin]

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

On Thursday 02 October 2008, Sergey Vlasov wrote:

[...]
> в инсталяторе делать установку пакетов в
> зависимости от обнаруженного железа
Да, было бы здорово придумать, какие файлы, какого формата, как 
создать автоматически и куда положить в пакеты с модулями ядра для 
облегчения задачи инсталлятору.
Установка произвольных пакетов не "модулем установки всех пакетов" 
-- вообще больная тема.

[...]

-- 
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: 197 bytes --]

Re: [devel] установка пакетов alterator-ом по надобности

[Michael Shigorin]

On Thu, Oct 02, 2008 at 02:05:45PM +0400, Sergey V Turchin wrote:
> Установка произвольных пакетов не "модулем установки всех
> пакетов" -- вообще больная тема.

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

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

Re: [devel] установка пакетов alterator-ом по надобности

[Sergey V Turchin]

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

On Thursday 02 October 2008, Michael Shigorin wrote:
> On Thu, Oct 02, 2008 at 02:05:45PM +0400, Sergey V Turchin wrote:
> > Установка произвольных пакетов не "модулем установки всех
> > пакетов" -- вообще больная тема.
>
> Вполне можно взяться, было бы желание и уверенность в том,
> что караван идёт примерно в ту же сторону.
Он уже примерно в 3 стороны ушел. Когда был только alterator-
packages, функция "установи списочек пакетов" была доступна любому 
модулю.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 01:54:27 PM you wrote:

> On Thu, Oct 02, 2008 at 01:31:41PM +0400, Konstantin A. Lepikhov wrote:
> > Вообще старые устройства, которые не поддерживаются, обслуживаются
> > отдельным приложением nvidia_legacy. Зачем пихать все модули в одну
> > кучу и потом городить переключатели?
> 
> Как минимум драйвер X переименовать нельзя - модуль должен иметь имя
> nvidia (в модуле ищется символ ${name}ModuleData), так что без симлинков
> на этом этапе не обойтись (разве что сделать несколько пакетов,
> конфликтущих друг с другом, но в этом случае нужно, например, в
> инсталяторе делать установку пакетов в зависимости от обнаруженного
> железа).  Модули ядра тоже просто так не переименовываются.
Механизм детекта железа/драйвера через .xinf в alterator работает,
реализовать provides: <список modalias> для каждого такого пакета тоже
можно:

[17:10:38] <legion> а modalias:<pcimap>
[17:11:11] <legion> чтобы по rpmquery -a modalias* можно было получить список
[17:11:18] <legion> с модулями

> 
> > А смысл прыганья между ядрами? В сизифе всегда есть только одно ядро и
> > один комплект драйверов.
> 
> Даже в сизифе могут быть разные версии модулей для разных flavour ядер, а
> уж что находится в системе у пользователей - вообще неизвестно.
Значит, не надо допускать такого бардака в сизифе.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey Vlasov]

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

On Thu, Oct 02, 2008 at 05:12:48PM +0400, Konstantin A. Lepikhov wrote:
> Механизм детекта железа/драйвера через .xinf в alterator работает,
> реализовать provides: <список modalias> для каждого такого пакета тоже
> можно:
> 
> [17:10:38] <legion> а modalias:<pcimap>
> [17:11:11] <legion> чтобы по rpmquery -a modalias* можно было получить список
> [17:11:18] <legion> с модулями

А база не треснет?  Файлы pkglist и так толстые.

> > > А смысл прыганья между ядрами? В сизифе всегда есть только одно ядро и
> > > один комплект драйверов.
> > 
> > Даже в сизифе могут быть разные версии модулей для разных flavour ядер, а
> > уж что находится в системе у пользователей - вообще неизвестно.
> Значит, не надо допускать такого бардака в сизифе.

Этот "бардак" возникнет у любого пользователя после обновления ядра,
когда ему по каким-то причинам понадобится загрузить старую версию.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 05:38:06 PM you wrote:

> On Thu, Oct 02, 2008 at 05:12:48PM +0400, Konstantin A. Lepikhov wrote:
> > Механизм детекта железа/драйвера через .xinf в alterator работает,
> > реализовать provides: <список modalias> для каждого такого пакета тоже
> > можно:
> > 
> > [17:10:38] <legion> а modalias:<pcimap>
> > [17:11:11] <legion> чтобы по rpmquery -a modalias* можно было получить список
> > [17:11:18] <legion> с модулями
> 
> А база не треснет?  Файлы pkglist и так толстые.
Если попилить модули, то не треснет.

> 
> > > > А смысл прыганья между ядрами? В сизифе всегда есть только одно ядро и
> > > > один комплект драйверов.
> > > 
> > > Даже в сизифе могут быть разные версии модулей для разных flavour ядер, а
> > > уж что находится в системе у пользователей - вообще неизвестно.
> > Значит, не надо допускать такого бардака в сизифе.
> 
> Этот "бардак" возникнет у любого пользователя после обновления ядра,
> когда ему по каким-то причинам понадобится загрузить старую версию.
Для таких случаев придуман механизм Hold.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Sergey Vlasov wrote:
> On Thu, Oct 02, 2008 at 05:12:48PM +0400, Konstantin A. Lepikhov wrote:
>> Механизм детекта железа/драйвера через .xinf в alterator работает,
>> реализовать provides: <список modalias> для каждого такого пакета тоже
>> можно:
>>
>> [17:10:38] <legion> а modalias:<pcimap>
>> [17:11:11] <legion> чтобы по rpmquery -a modalias* можно было получить список
>> [17:11:18] <legion> с модулями
> 
> А база не треснет?  Файлы pkglist и так толстые.

Увеличение pkglist это небольшая жертва (хоть и жертва). xinf файлов у 
нас не много и они не большие. Если идею распространять на все модули, 
то modalias'ов будет существенно больше. Но и в этом случае мне не 
кажется это смертельным.

-- 
Rgrds, legion

[devel] video drivers

[Michael Shigorin]

On Thu, Oct 02, 2008 at 01:38:49AM +0400, Dmitry V. Levin wrote:
> Единственное, что мне точно известно -- это факт наличия в пакете
> kernel-modules-nvidia-что-то-там модулей nvidia нескольких версий.
> Вероятно, реализован какой-то механизм переключения версий, но
> интересно было бы узнать, как именно он задуман работать?

Что вышло -- собрал здесь: http://www.altlinux.org/VideoDrivers

On Thu, Oct 02, 2008 at 12:49:36PM +0400, Sergey Vlasov wrote:
> Проблема в том, что "наипоследняя" версия не работает со
> старыми устройствами - для них нужны более старые версии
> модуля; из-за этого и приходится городить переключатель.

Мало того, в других дистрибутивах такого не видывал.
А zerg@ за реализацию памятник поставить стоит прижизненно,
даже если некоторые горазды только плеваться, сами не сделав
подхода к этому снаряду.

> Переименовывать модули вроде бы тоже нельзя, так что приходится
> делать nvidia.ko симлинком на нужную версию.

Точно нельзя, проверено.

On Thu, Oct 02, 2008 at 01:15:40PM +0400, Sergey V Turchin wrote:
> > У меня, например, после его "переключения" стабильно слетают
> > ссылки на драйвера _xorg_ при обновлении _ядра_.
> Опять кривой пакет fglrx?  Номер баги?

И ещё chkconfig --list x11presetdrv

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

Re: [devel] video drivers

[Mikhail Gusarov]

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

Twas brillig at 16:59:14 02.10.2008 UTC+03 when mike@osdn.org.ua did gyre and gimble:

 MS> Мало того, в других дистрибутивах такого не видывал.

nvidia-kernel-legacy / nvidia-glx-legacy (в двух вариантах) в Debian
есть. Это чтобы развеять нездоровую ауру уникальности.

-- 

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

Re: [devel] video drivers

[Michael Shigorin]

On Thu, Oct 02, 2008 at 09:03:05PM +0700, Mikhail Gusarov wrote:
>  MS> Мало того, в других дистрибутивах такого не видывал.
> nvidia-kernel-legacy / nvidia-glx-legacy (в двух вариантах) в
> Debian есть.

С автопереключалкой?

> Это чтобы развеять нездоровую ауру уникальности.

(это чтоб развеять нездоровую тягу к поспешности)

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

Re: [devel] video drivers

[Mikhail Gusarov]

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

Twas brillig at 17:19:35 02.10.2008 UTC+03 when mike@osdn.org.ua did gyre and gimble:

 MS> С автопереключалкой?

Разумеется, нет.

-- 

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

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Michael!

Thursday 02, at 05:19:35 PM you wrote:

> On Thu, Oct 02, 2008 at 09:03:05PM +0700, Mikhail Gusarov wrote:
> >  MS> Мало того, в других дистрибутивах такого не видывал.
> > nvidia-kernel-legacy / nvidia-glx-legacy (в двух вариантах) в
> > Debian есть.
> 
> С автопереключалкой?
Расскажи популярно, в чем уникальность этого чудокостыля?

> 
> > Это чтобы развеять нездоровую ауру уникальности.
> 
> (это чтоб развеять нездоровую тягу к поспешности)
Боюсь аффтар костыля не знал, что есть debian ;) 

-- 
WBR et al.

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

Re: [devel] video drivers

[Mikhail Gusarov]

Twas brillig at 18:24:30 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:

 >> С автопереключалкой?
 KAL> Расскажи популярно, в чем уникальность этого чудокостыля?

Проблему третьего мира решает: без наличия интернета можно
попереключать. Та же убунта при смене видюшки выпадет в failsafe и своим
менеджером драйверов спросит "а не поставить ли нам пакет с драйверами",
поскольку nvidia*legacy* между собой конфликтуют.

-- 

Re: [devel] video drivers

[Sergey V Turchin]

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

On Thursday 02 October 2008, Mikhail Gusarov wrote:

[...]
> Та же убунта при смене видюшки выпадет в failsafe
> и своим менеджером драйверов спросит "а не поставить ли нам пакет
> с драйверами"
По хорошему так и надо, но у нас в этом месте проблема, поэтому все 
дрова должны заранее стоять и поэтому я нагородил для nvidia эту 
переключалку.

[...]

-- 
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: 197 bytes --]

Re: [devel] video drivers

[Anton Farygin]

Sergey V Turchin пишет:
> On Thursday 02 October 2008, Mikhail Gusarov wrote:
> 
> [...]
>> Та же убунта при смене видюшки выпадет в failsafe
>> и своим менеджером драйверов спросит "а не поставить ли нам пакет
>> с драйверами"
> По хорошему так и надо, но у нас в этом месте проблема, поэтому все 
> дрова должны заранее стоять и поэтому я нагородил для nvidia эту 
> переключалку.

И очень хорошо сделал - оно вполне неплохо работает.

Re: [devel] video drivers

[Michael Shigorin]

On Thu, Oct 02, 2008 at 10:35:19PM +0400, Anton Farygin wrote:
> >>Та же убунта при смене видюшки выпадет в failsafe и своим
> >>менеджером драйверов спросит "а не поставить ли нам пакет с
> >>драйверами"
> >По хорошему так и надо

Нет, не надо.  Они предпочитают сваливать проблему установки
драйверов на голову пользователя, а мы предпочитаем так не делать.

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

+1.  Кстати, забыл по этому поводу на LF проставиться.

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

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Thursday 02, at 09:26:47 PM you wrote:

> 
> Twas brillig at 18:24:30 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:
> 
>  >> С автопереключалкой?
>  KAL> Расскажи популярно, в чем уникальность этого чудокостыля?
> 
> Проблему третьего мира решает: без наличия интернета можно
> попереключать. Та же убунта при смене видюшки выпадет в failsafe и своим
> менеджером драйверов спросит "а не поставить ли нам пакет с драйверами",
> поскольку nvidia*legacy* между собой конфликтуют.
Т.е. мы решаем проблему использования altlinux в подводной лодке, где
подводникам заняться нечем и они проводят все время в перетыкании
различных nvidia?

-- 
WBR et al.

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

Re: [devel] video drivers

[Mikhail Gusarov]

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

Twas brillig at 23:07:44 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:

 >> Проблему третьего мира решает: без наличия интернета можно
 >> попереключать. Та же убунта при смене видюшки выпадет в failsafe и
 >> своим менеджером драйверов спросит "а не поставить ли нам пакет с
 >> драйверами", поскольку nvidia*legacy* между собой конфликтуют.

 KAL> Т.е. мы решаем проблему использования altlinux в подводной лодке,

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

-- 

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

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Friday 03, at 02:10:02 AM you wrote:

> Twas brillig at 23:07:44 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:
> 
>  >> Проблему третьего мира решает: без наличия интернета можно
>  >> попереключать. Та же убунта при смене видюшки выпадет в failsafe и
>  >> своим менеджером драйверов спросит "а не поставить ли нам пакет с
>  >> драйверами", поскольку nvidia*legacy* между собой конфликтуют.
> 
>  KAL> Т.е. мы решаем проблему использования altlinux в подводной лодке,
> 
> Вне крупных городов интернет - редкость жуткая, ага. Спроси кого-нибудь
> из внедренцев школьного проекта, расскажут.
Ага, а диски у бедных детишек после установки отнимают и не отдают пока
уроки не сделают.

-- 
WBR et al.

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

Re: [devel] video drivers

[Mikhail Gusarov]

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

Twas brillig at 23:14:33 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:

 >> Вне крупных городов интернет - редкость жуткая, ага. Спроси кого-нибудь
 >> из внедренцев школьного проекта, расскажут.

 KAL> Ага, а диски у бедных детишек после установки отнимают и не отдают
 KAL> пока уроки не сделают.

На подводной лодке диски тоже никуда не пропадут, кстати :)

В общем, если переключалка стабильно работает - это прикольная фиговина
(== не надо вообще ни о чём думать), но можно и без него спокойно
обойтись, никакой "особой уникальности" в нём нет.

-- 

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

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Mikhail!

Friday 03, at 02:18:45 AM you wrote:

> Twas brillig at 23:14:33 02.10.2008 UTC+04 when lakostis@altlinux.org did gyre and gimble:
> 
>  >> Вне крупных городов интернет - редкость жуткая, ага. Спроси кого-нибудь
>  >> из внедренцев школьного проекта, расскажут.
> 
>  KAL> Ага, а диски у бедных детишек после установки отнимают и не отдают
>  KAL> пока уроки не сделают.
> 
> На подводной лодке диски тоже никуда не пропадут, кстати :)
А там устав запрещает %)

> 
> В общем, если переключалка стабильно работает - это прикольная фиговина
> (== не надо вообще ни о чём думать), но можно и без него спокойно
> обойтись, никакой "особой уникальности" в нём нет.
Так вот мы и хотим ее оторвать, чтобы отдельные эстеты-некрофилы ей продолжали
пользоваться, а нормальные люди не искали какой из x11автоугадавов надо
запустить чтобы вывести систему из бесконечного подмигивания.

-- 
WBR et al.

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

Re: [devel] video drivers

[Anton Farygin]

Konstantin A. Lepikhov пишет:
> Hi Mikhail!
> 
> Friday 03, at 02:18:45 AM you wrote:
> 
>> Twas brillig at 23:14:33 02.10.2008 UTC+04 when lakostis-u2l5PoMzF/Vg9hUCZPvPmw@public.gmane.org did gyre and gimble:
>>
>>  >> Вне крупных городов интернет - редкость жуткая, ага. Спроси кого-нибудь
>>  >> из внедренцев школьного проекта, расскажут.
>>
>>  KAL> Ага, а диски у бедных детишек после установки отнимают и не отдают
>>  KAL> пока уроки не сделают.
>>
>> На подводной лодке диски тоже никуда не пропадут, кстати :)
> А там устав запрещает %)

Неправда... устав разрешает.

> 
>> В общем, если переключалка стабильно работает - это прикольная фиговина
>> (== не надо вообще ни о чём думать), но можно и без него спокойно
>> обойтись, никакой "особой уникальности" в нём нет.
> Так вот мы и хотим ее оторвать, чтобы отдельные эстеты-некрофилы ей продолжали
> пользоваться, а нормальные люди не искали какой из x11автоугадавов надо
> запустить чтобы вывести систему из бесконечного подмигивания.

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

драйвера nv тоже неплохо работают, без автопереключалок.

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Anton!

Thursday 02, at 11:31:14 PM you wrote:

<skip>
> >> В общем, если переключалка стабильно работает - это прикольная фиговина
> >> (== не надо вообще ни о чём думать), но можно и без него спокойно
> >> обойтись, никакой "особой уникальности" в нём нет.
> > Так вот мы и хотим ее оторвать, чтобы отдельные эстеты-некрофилы ей продолжали
> > пользоваться, а нормальные люди не искали какой из x11автоугадавов надо
> > запустить чтобы вывести систему из бесконечного подмигивания.
> 
> На своём персональном компьюетере, Вы, константин, можете делать всё что 
> Вам заблагорассудится..
А вы что, хотите мне запретить?

> 
> драйвера nv тоже неплохо работают, без автопереключалок.
Удивительно. И как только они работают, ведь без автопереключалок
теперь никуда, дети в школах не поймут.

-- 
WBR et al.

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

Re: [devel] video drivers

[Anton Farygin]

Konstantin A. Lepikhov пишет:
> Hi Anton!
> 
> Thursday 02, at 11:31:14 PM you wrote:
> 
> <skip>
>>>> В общем, если переключалка стабильно работает - это прикольная фиговина
>>>> (== не надо вообще ни о чём думать), но можно и без него спокойно
>>>> обойтись, никакой "особой уникальности" в нём нет.
>>> Так вот мы и хотим ее оторвать, чтобы отдельные эстеты-некрофилы ей продолжали
>>> пользоваться, а нормальные люди не искали какой из x11автоугадавов надо
>>> запустить чтобы вывести систему из бесконечного подмигивания.
>> На своём персональном компьюетере, Вы, константин, можете делать всё что 
>> Вам заблагорассудится..
> А вы что, хотите мне запретить?

Нет, я Вам разрешаю, разве из первого письма этого не понятно ?

Не надо навязывать своё, ошибочное, мнение всем пользователям.

> 
>> драйвера nv тоже неплохо работают, без автопереключалок.
> Удивительно. И как только они работают, ведь без автопереключалок
> теперь никуда, дети в школах не поймут.

Константин, Вы наверное не в курсе, но драйверу nv автопереключалки не 
требуются...

Re: [devel] video drivers

[Konstantin A. Lepikhov]

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

Hi Anton!

Thursday 02, at 11:47:10 PM you wrote:

<skip>
> > А вы что, хотите мне запретить?
> 
> Нет, я Вам разрешаю, разве из первого письма этого не понятно ?
> 
> Не надо навязывать своё, ошибочное, мнение всем пользователям.
Не мешайте нам навязывать свое мнение, а то пользователи 2 мнения
ниасилят? IHMO пользователя все равно, главное, чтобы работало.

> 
> > 
> >> драйвера nv тоже неплохо работают, без автопереключалок.
> > Удивительно. И как только они работают, ведь без автопереключалок
> > теперь никуда, дети в школах не поймут.
> 
> Константин, Вы наверное не в курсе, но драйверу nv автопереключалки не 
> требуются...
Чем "драйвер nv" отличается от "недрайвера nvidia"? Да, там нет
автоугдава на c++, криво реализующего sort -u :)

-- 
WBR et al.

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

Re: [devel] video drivers

[Sergey V Turchin]

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

On Friday 03 October 2008, Konstantin A. Lepikhov wrote:

[...]
> автоугдава на c++, криво реализующего sort -u :)
Что это такое? Какое-то твое изобретение? ;-)

-- 
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: 197 bytes --]

Re: [devel] video drivers

[Michael Shigorin]

On Thu, Oct 02, 2008 at 11:27:48PM +0400, Konstantin A. Lepikhov wrote:
> > В общем, если переключалка стабильно работает - это
> > прикольная фиговина (== не надо вообще ни о чём думать),
> > но можно и без него спокойно обойтись, никакой "особой
> > уникальности" в нём нет.
> Так вот мы и хотим ее оторвать

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

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

Нормальные люди не лезут в /dev/arse, чтоб потом оттуда
возглашать, как всё плохо.

У них или всё поставлено инсталятором и просто работает,
или обновляется update-kernel и тоже просто работает.

Прекрати высасывать флуд из пальца, пожалуйста.

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

Re: [devel] video drivers

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

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

Здравствуйте Konstantin A. Lepikhov
  В сообщении от Четверг 02 октября 2008 Konstantin A. Lepikhov 
написал(a):
> > (это чтоб развеять нездоровую тягу к поспешности)
> Боюсь аффтар костыля не знал, что есть debian ;)
Спасибо на добром слове ! :) Хотя название nvidia-kernel-legacy 
взято оттуда :)


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

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Dmitry V. Levin wrote:

[...]
> Единственное, что мне точно известно -- это факт наличия в пакете
> kernel-modules-nvidia-что-то-там модулей nvidia нескольких
> версий. Вероятно, реализован какой-то механизм переключения
> версий, но интересно было бы узнать, как именно он задуман
> работать?
При запуске сервиса x11presetdrv запускаются все программы из 
каталога /usr/libexec/X11/drvpre.d/ , одна из которых nvidia.
Она сканирует PCI в /sys на предмет видеоплат производителя NVIDIA.
Если таковые найдены, ищет пары драйверов ядерный+Xовый, совпадающие 
по версии.
Иcходя из списка найденных грепает соответствующие 
/usr/share/hwdatabase/videoaliases/nvidia-*.xinf на предмет ID 
платы.
Из списка подошедших .xinf выбирает тот, у кого версия больше (кол-
во подошедших версий под несколько плат имеет приоритет).
Переключает /lib/modules/`uname -r`/nVidia/nvidia.ko на выбранную 
версию.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 01:27:02 PM you wrote:

> On Thursday 02 October 2008, Dmitry V. Levin wrote:
> 
> [...]
> > Единственное, что мне точно известно -- это факт наличия в пакете
> > kernel-modules-nvidia-что-то-там модулей nvidia нескольких
> > версий. Вероятно, реализован какой-то механизм переключения
> > версий, но интересно было бы узнать, как именно он задуман
> > работать?
> При запуске сервиса x11presetdrv запускаются все программы из 
> каталога /usr/libexec/X11/drvpre.d/ , одна из которых nvidia.
Не запускаются:

[lakostis@localhost ~]$ rpm -qa|fgrep x11
xorg-x11-rgb-1.0.1-alt1
x11updatedrv-0.2.0-alt3
xorg-x11-drv-vga-4.1.0-alt3
x11setupdrv-0.4.2-alt1
x11presetdrv-1.0.0-alt1
[lakostis@localhost ~]$ /sbin/chkconfig --list|fgrep x11
x11presetdrv    0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл

Стабильно после обновления ядра получаю мигание экрана вместо запуска xorg
и битые симлинки в /etc/X11

Помогает только повторная перезагрузка в single и запуск x11setupdrv
руками.

> Она сканирует PCI в /sys на предмет видеоплат производителя NVIDIA.
> Если таковые найдены, ищет пары драйверов ядерный+Xовый, совпадающие 
> по версии.
> Иcходя из списка найденных грепает соответствующие 
> /usr/share/hwdatabase/videoaliases/nvidia-*.xinf на предмет ID 
> платы.
> Из списка подошедших .xinf выбирает тот, у кого версия больше (кол-
> во подошедших версий под несколько плат имеет приоритет).
> Переключает /lib/modules/`uname -r`/nVidia/nvidia.ko на выбранную 
> версию.
Здорово - если я обновлю ядро через rpm -Fhv, то в момент запуска
"автоугадава" ядра у меня уже в системе не будет и /lib/modules/'uname -r'
будет пуст. И далее вся эта мурдёная логика идет лесом.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> Здорово - если я обновлю ядро через rpm -Fhv, то в момент запуска
> "автоугадава" ядра у меня уже в системе не будет и
> /lib/modules/'uname -r' будет пуст.
> И далее вся эта мурдёная логика идет лесом.
Нет, т.к. тебе придется перезагрузиться.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Vitaly Ostanin]

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

Konstantin A. Lepikhov пишет:

<skipped/>

> [lakostis@localhost ~]$ /sbin/chkconfig --list|fgrep x11
> x11presetdrv    0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл
> 
> Стабильно после обновления ядра получаю мигание экрана вместо запуска xorg
> и битые симлинки в /etc/X11

Кстати, я тоже на это натыкался, но думал, что это моя 
персональная кривизна системы. После смены ядра приходится 
вручную запускать
/usr/libexec/X11/drv.d/nvidia

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

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@altlinux.org
JID:     vitaly.ostanin@gmail.com


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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Vitaly Ostanin wrote:

[...]
> > Стабильно после обновления ядра получаю мигание экрана вместо
> > запуска xorg и битые симлинки в /etc/X11
> Кстати, я тоже на это натыкался, но думал, что это моя
> персональная кривизна системы. После смены ядра приходится
> вручную запускать
> /usr/libexec/X11/drv.d/nvidia
пакет x11_autosetup

> Ещё не исключено, что у некоторых вздорных точно такая же
> персональная кривизна системы.
>
> <skipped/>


-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Vitaly Ostanin]

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

Sergey V Turchin пишет:
> On Thursday 02 October 2008, Vitaly Ostanin wrote:
> 
> [...]
>>> Стабильно после обновления ядра получаю мигание экрана вместо
>>> запуска xorg и битые симлинки в /etc/X11
>> Кстати, я тоже на это натыкался, но думал, что это моя
>> персональная кривизна системы. После смены ядра приходится
>> вручную запускать
>> /usr/libexec/X11/drv.d/nvidia
> пакет x11_autosetup

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

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@altlinux.org
JID:     vitaly.ostanin@gmail.com


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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Vitaly Ostanin wrote:

[...]
> Спасибо, поставил. Хорошо бы этот пакет кто-нибудь вытягивал по
> зависимостям, раз он такой полезный.
Инсталлятор это делает со времен 3.0 (ранее в виде пакета hardware ( 
x11_autosetup его obsolete))

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 04:33:14 PM you wrote:

> On Thursday 02 October 2008, Vitaly Ostanin wrote:
> 
> [...]
> > Спасибо, поставил. Хорошо бы этот пакет кто-нибудь вытягивал по
> > зависимостям, раз он такой полезный.
> Инсталлятор это делает со времен 3.0 (ранее в виде пакета hardware ( 
> x11_autosetup его obsolete))
Это делает installer ALD. Installer от сервера это не делает, а пакет
nvidia_glx это не вытягивает.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:
> Hi Sergey!
>
> Thursday 02, at 04:33:14 PM you wrote:
> > On Thursday 02 October 2008, Vitaly Ostanin wrote:
> >
> > [...]
> >
> > > Спасибо, поставил. Хорошо бы этот пакет кто-нибудь вытягивал
> > > по зависимостям, раз он такой полезный.
> >
> > Инсталлятор это делает со времен 3.0 (ранее в виде пакета
> > hardware ( x11_autosetup его obsolete))
>
> Это делает installer ALD. Installer от сервера это не делает,
Он и X-ы не ставит, при этом kde X-сервер тоже не вытаскивает.

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

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 05:02:47 PM you wrote:

> > пакет nvidia_glx это не вытягивает.
> Да я понимаю, но x11_autosetup предполагает неизвестную мне в 
> дальнейшем бороду зависимостей, на которую я опасаюсь надеяться, 
> т.к. если она поломается хоть где-то, то снесется все, что связано с 
> nvidia.
Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и вагоном
лишних зависимостей впридачу?

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Thursday 02 October 2008 16:13:52 Konstantin A. Lepikhov wrote:
> Hi Sergey!
>
> Thursday 02, at 05:02:47 PM you wrote:
> > > пакет nvidia_glx это не вытягивает.
> >
> > Да я понимаю, но x11_autosetup предполагает неизвестную мне в
> > дальнейшем бороду зависимостей, на которую я опасаюсь надеяться,
> > т.к. если она поломается хоть где-то, то снесется все, что связано с
> > nvidia.
>
> Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и вагоном
> лишних зависимостей впридачу?

Предложи решение типа:
%files
%pciid(xxxx:yyyy) module_dir/module1
%pciid(xxxx:yyyy) module_dir/module2
...
:)

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Thursday 02 October 2008 16:28:14 Led wrote:
> On Thursday 02 October 2008 16:13:52 Konstantin A. Lepikhov wrote:
> > Hi Sergey!
> >
> > Thursday 02, at 05:02:47 PM you wrote:
> > > > пакет nvidia_glx это не вытягивает.
> > >
> > > Да я понимаю, но x11_autosetup предполагает неизвестную мне в
> > > дальнейшем бороду зависимостей, на которую я опасаюсь надеяться,
> > > т.к. если она поломается хоть где-то, то снесется все, что связано с
> > > nvidia.
> >
> > Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и вагоном
> > лишних зависимостей впридачу?
>
> Предложи решение типа:
> %files
> %pciid(xxxx:yyyy) module_dir/module1
> %pciid(xxxx:yyyy) module_dir/module2
> ...

Хотя... может и стОит разделить их на отдельные пакеты:
kernel-modules-nvidia-tnt
kernel-modules-nvidia-geforce
kernel-modules-nvidia
и добавив виртуальный
kernel-modules-nvidia-full для "ленивых"?

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и
> вагоном лишних зависимостей впридачу?
Нет, ты.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 05:30:54 PM you wrote:

> On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:
> 
> [...]
> > Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и
> > вагоном лишних зависимостей впридачу?
> Нет, ты.
У меня такого пакета нет, переключение не работает. Что делать?

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> > > Т.е. ты всем предлагаешь ставить пакет с непонятным
> > > содержимым и вагоном лишних зависимостей впридачу?
> >
> > Нет, ты.
>
> У меня такого пакета нет, переключение не работает. Что делать?
А-а-а! А я думал, кто такой "все" ?

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Andrey Rahmatullin]

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

On Thu, Oct 02, 2008 at 05:30:54PM +0400, Sergey V Turchin wrote:
> > Т.е. ты всем предлагаешь ставить пакет с непонятным содержимым и
> > вагоном лишних зависимостей впридачу?
> Нет, ты.
Здесь мой шаблон порвался.
http://encyclopediadramatica.com/NO_U

-- 
WBR, wRAR (ALT Linux Team)
Powered by the ALT Linux fortune(8):

Предлагаю отнестись критически к рекомендациям по безопасности, почерпнутым из
мурзилок.
		-- sbolshakov in #10666

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Michael Shigorin]

On Thu, Oct 02, 2008 at 10:34:26PM +0600, Andrey Rahmatullin wrote:
> > > Т.е. ты всем предлагаешь ставить пакет с непонятным
> > > содержимым и вагоном лишних зависимостей впридачу?
> > Нет, ты.
> Здесь мой шаблон порвался.

(доставая запасной покрепче) Плохой, негодный щаблон.

Зерг действительно не нависал ни на кого с предложениями влепить
всё и вся зачем-то куда-нибудь.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Michael!

Thursday 02, at 11:50:15 PM you wrote:

> On Thu, Oct 02, 2008 at 10:34:26PM +0600, Andrey Rahmatullin wrote:
> > > > Т.е. ты всем предлагаешь ставить пакет с непонятным
> > > > содержимым и вагоном лишних зависимостей впридачу?
> > > Нет, ты.
> > Здесь мой шаблон порвался.
> 
> (доставая запасной покрепче) Плохой, негодный щаблон.
> 
> Зерг действительно не нависал ни на кого с предложениями влепить
> всё и вся зачем-то куда-нибудь.
При чем тут Зерг? Переключалка уже свое отжила вот и все.

-- 
WBR et al.

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

[devel] [JT] *sigh*

[Michael Shigorin]

On Fri, Oct 03, 2008 at 12:54:05AM +0400, Konstantin A. Lepikhov wrote:
> Переключалка уже свое отжила

Нет.

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

Re: [devel] [JT] *sigh*

[Konstantin A. Lepikhov]

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

Hi Michael!

Friday 03, at 12:09:10 AM you wrote:

> On Fri, Oct 03, 2008 at 12:54:05AM +0400, Konstantin A. Lepikhov wrote:
> > Переключалка уже свое отжила
> 
> Нет.
Показываю на примере:
$ cat ~/local/git/nvidia.xinf-modalias.uniq.list:
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000020sv*sd*bc*sc*i* nvidia # RIVA TNT
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000028sv*sd*bc*sc*i* nvidia # RIVA TNT2/TNT2 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000029sv*sd*bc*sc*i* nvidia # RIVA TNT2 Ultra
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d0000002Csv*sd*bc*sc*i* nvidia # Vanta/Vanta LT
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d0000002Dsv*sd*bc*sc*i* nvidia # RIVA TNT2 Model 64/Model 64 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000040sv*sd*bc*sc*i* nvidia # GeForce 6800 Ultra
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000041sv*sd*bc*sc*i* nvidia # GeForce 6800
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d00000045sv*sd*bc*sc*i* nvidia # GeForce 6800 GT
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d0000004Esv*sd*bc*sc*i* nvidia # Quadro FX 4000
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000012D2d000000A0sv*sd*bc*sc*i* nvidia # Aladdin TNT2
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000020sv*sd*bc*sc*i* nvidia # RIVA TNT
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000028sv*sd*bc*sc*i* nvidia # RIVA TNT2/TNT2 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000029sv*sd*bc*sc*i* nvidia # RIVA TNT2 Ultra
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd0000002Csv*sd*bc*sc*i* nvidia # Vanta/Vanta LT
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd0000002Dsv*sd*bc*sc*i* nvidia # RIVA TNT2 Model 64/Model 64 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd000000A0sv*sd*bc*sc*i* nvidia # Aladdin TNT2
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000100sv*sd*bc*sc*i* nvidia # GeForce 256
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000101sv*sd*bc*sc*i* nvidia # GeForce DDR
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000103sv*sd*bc*sc*i* nvidia # Quadro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000150sv*sd*bc*sc*i* nvidia # GeForce2 GTS/GeForce2 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000151sv*sd*bc*sc*i* nvidia # GeForce2 Ti
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000152sv*sd*bc*sc*i* nvidia # GeForce2 Ultra
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd00000153sv*sd*bc*sc*i* nvidia # Quadro2 Pro
nvidia.xinf-71.86.06-nospace:alias pcivideo:v000010DEd000001F0sv*sd*bc*sc*i* nvidia # GeForce4 MX Integrated GPU

т.е. это ровно те уникальные карты, поддержка которых есть _только_ в
nvidia_glx-71.86.06 и нигде больше. Объясните, какой смысл держать 250Mb
исходных текстов разных _glx, если реально нужна поддержка только кучки
окаменелостей за 500р, поддержка которых покрывается _одним_ модулем и
_одним_ glx. Что мешает вынести все, что связано с _glx-71.86.06 в
отдельный пакет, прикрутить к нему этот уникальный .xinf, поставить
conflicts: с текущей версией _glx и не заниматься ерундой? Работу по
переключению (точнее по доустановке необходимых пакетов) может делать
утилита, которая примет список provides: modalias:<xxxxx>, найдет
нужный modalias в системе через udev_trigger и вытянет пакет из
репозитория.

-- 
WBR et al.

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

Re: [devel] [JT] *sigh*

[Led]

On Friday, 03 October 2008 01:01:03 Konstantin A. Lepikhov wrote:
> Hi Michael!
>
> Friday 03, at 12:09:10 AM you wrote:
> > On Fri, Oct 03, 2008 at 12:54:05AM +0400, Konstantin A. Lepikhov wrote:
> > > Переключалка уже свое отжила
> >
> > Нет.
>
> Показываю на примере:
> $ cat ~/local/git/nvidia.xinf-modalias.uniq.list:
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000020sv*sd*bc*sc*i* nvidia # RIVA TNT
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000028sv*sd*bc*sc*i* nvidia # RIVA TNT2/TNT2 Pro
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000029sv*sd*bc*sc*i* nvidia # RIVA TNT2 Ultra
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d0000002Csv*sd*bc*sc*i* nvidia # Vanta/Vanta LT
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d0000002Dsv*sd*bc*sc*i* nvidia # RIVA TNT2 Model 64/Model
> 64 Pro nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000040sv*sd*bc*sc*i* nvidia # GeForce 6800 Ultra
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000041sv*sd*bc*sc*i* nvidia # GeForce 6800
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d00000045sv*sd*bc*sc*i* nvidia # GeForce 6800 GT
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d0000004Esv*sd*bc*sc*i* nvidia # Quadro FX 4000
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000012D2d000000A0sv*sd*bc*sc*i* nvidia # Aladdin TNT2
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000020sv*sd*bc*sc*i* nvidia # RIVA TNT
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000028sv*sd*bc*sc*i* nvidia # RIVA TNT2/TNT2 Pro
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000029sv*sd*bc*sc*i* nvidia # RIVA TNT2 Ultra
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd0000002Csv*sd*bc*sc*i* nvidia # Vanta/Vanta LT
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd0000002Dsv*sd*bc*sc*i* nvidia # RIVA TNT2 Model 64/Model
> 64 Pro nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd000000A0sv*sd*bc*sc*i* nvidia # Aladdin TNT2
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000100sv*sd*bc*sc*i* nvidia # GeForce 256
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000101sv*sd*bc*sc*i* nvidia # GeForce DDR
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000103sv*sd*bc*sc*i* nvidia # Quadro
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000150sv*sd*bc*sc*i* nvidia # GeForce2 GTS/GeForce2
> Pro nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000151sv*sd*bc*sc*i* nvidia # GeForce2 Ti
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000152sv*sd*bc*sc*i* nvidia # GeForce2 Ultra
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd00000153sv*sd*bc*sc*i* nvidia # Quadro2 Pro
> nvidia.xinf-71.86.06-nospace:alias
> pcivideo:v000010DEd000001F0sv*sd*bc*sc*i* nvidia # GeForce4 MX Integrated
> GPU
>
> т.е. это ровно те уникальные карты, поддержка которых есть _только_ в
> nvidia_glx-71.86.06 и нигде больше. Объясните, какой смысл держать 250Mb
> исходных текстов разных _glx, если реально нужна поддержка только кучки
> окаменелостей за 500р, поддержка которых покрывается _одним_ модулем и
> _одним_ glx. Что мешает вынести все, что связано с _glx-71.86.06 в
> отдельный пакет, прикрутить к нему этот уникальный .xinf, поставить
> conflicts: с текущей версией _glx и не заниматься ерундой?

Если ты ставишь единычные инсталляции, то кто-то делает НЕ-единичные. И 
этому "кому-то" НАФИГ (если не сказать грубее) не сдались эти "conflicts" при 
массовой инстялляции с помощью "dd-инсталлятора".

> Работу по 
> переключению (точнее по доустановке необходимых пакетов) может делать
> утилита, которая примет список provides: modalias:<xxxxx>, найдет
> нужный modalias в системе через udev_trigger и вытянет пакет из
> репозитория.

Кто за меня решил (своими conflicts) какие драйвера я хочу держать в системе? 
Может стоть подумать не только с точки зрения "домашнего юзера", а и с точки 
зрения "корпоративного админа"? а также вспомнить, что X Window - это прежде 
всего сетевая система (а уже потом подложка для былоигрушек) и с одним корнем 
может жыть НЕСКОЛЬКО клиентов, с РАЗНЫМИ адаптерами?

-- 
Led

Re: [devel] [JT] *sigh*

[Konstantin A. Lepikhov]

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

Hi Led!

Friday 03, at 01:15:31 AM you wrote:

<skip>
> > т.е. это ровно те уникальные карты, поддержка которых есть _только_ в
> > nvidia_glx-71.86.06 и нигде больше. Объясните, какой смысл держать 250Mb
> > исходных текстов разных _glx, если реально нужна поддержка только кучки
> > окаменелостей за 500р, поддержка которых покрывается _одним_ модулем и
> > _одним_ glx. Что мешает вынести все, что связано с _glx-71.86.06 в
> > отдельный пакет, прикрутить к нему этот уникальный .xinf, поставить
> > conflicts: с текущей версией _glx и не заниматься ерундой?
> 
> Если ты ставишь единычные инсталляции, то кто-то делает НЕ-единичные. И 
> этому "кому-то" НАФИГ (если не сказать грубее) не сдались эти "conflicts" при 
> массовой инстялляции с помощью "dd-инсталлятора".
Перечитай еще раз свой ответ и скажи, чем мешает тебе пакет с conflicts.
Пакеты не пересекаются по .xinf. Если у тебя инсталляция, собранная не
mkimage и не использующая alterator-x11, то это и не altlinux, который
здесь обсуждается.

> 
> > Работу по 
> > переключению (точнее по доустановке необходимых пакетов) может делать
> > утилита, которая примет список provides: modalias:<xxxxx>, найдет
> > нужный modalias в системе через udev_trigger и вытянет пакет из
> > репозитория.
> 
> Кто за меня решил (своими conflicts) какие драйвера я хочу держать в системе? 
> Может стоть подумать не только с точки зрения "домашнего юзера", а и с точки 
> зрения "корпоративного админа"? а также вспомнить, что X Window - это прежде 
> всего сетевая система (а уже потом подложка для былоигрушек) и с одним корнем 
> может жыть НЕСКОЛЬКО клиентов, с РАЗНЫМИ адаптерами?
"нужный modalias в системе вытягивается через udev_trigger". Чем
отличается в этом случае система с 2мя адаптерами? И что решит тебе
переключалка, если единовременно в системе все равно может быть только
одна рабочаяя копия при N установленных.

-- 
WBR et al.

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

Re: [devel] [JT] *sigh*

[Led]

On Friday, 03 October 2008 01:33:20 Konstantin A. Lepikhov wrote:
> Hi Led!
>
> Friday 03, at 01:15:31 AM you wrote:
>
> <skip>
>
> > > т.е. это ровно те уникальные карты, поддержка которых есть _только_ в
> > > nvidia_glx-71.86.06 и нигде больше. Объясните, какой смысл держать
> > > 250Mb исходных текстов разных _glx, если реально нужна поддержка только
> > > кучки окаменелостей за 500р, поддержка которых покрывается _одним_
> > > модулем и _одним_ glx. Что мешает вынести все, что связано с
> > > _glx-71.86.06 в отдельный пакет, прикрутить к нему этот уникальный
> > > .xinf, поставить conflicts: с текущей версией _glx и не заниматься
> > > ерундой?
> >
> > Если ты ставишь единычные инсталляции, то кто-то делает НЕ-единичные. И
> > этому "кому-то" НАФИГ (если не сказать грубее) не сдались эти "conflicts"
> > при массовой инстялляции с помощью "dd-инсталлятора".
>
> Перечитай еще раз свой ответ и скажи, чем мешает тебе пакет с conflicts.
> Пакеты не пересекаются по .xinf. Если у тебя инсталляция, собранная не
> mkimage и не использующая alterator-x11, то это и не altlinux, который
> здесь обсуждается.

Я сказал тебе про массовую инсталляцию с помощью dd и подобных инструментов - 
ты не заметил? или не понял о чём говорится? Хорошо, объясняю: я инсталлирую 
ОДИН раз, со ВСЕМИ видеодрайверами, ставлю в автозагрузку x11_autosetup (для 
первой загрузки) и дальше тупо размножаю систему на ЛЮБОЕ количесто винтов.

>
> > > Работу по
> > > переключению (точнее по доустановке необходимых пакетов) может делать
> > > утилита, которая примет список provides: modalias:<xxxxx>, найдет
> > > нужный modalias в системе через udev_trigger и вытянет пакет из
> > > репозитория.
> >
> > Кто за меня решил (своими conflicts) какие драйвера я хочу держать в
> > системе? Может стоть подумать не только с точки зрения "домашнего юзера",
> > а и с точки зрения "корпоративного админа"? а также вспомнить, что X
> > Window - это прежде всего сетевая система (а уже потом подложка для
> > былоигрушек) и с одним корнем может жыть НЕСКОЛЬКО клиентов, с РАЗНЫМИ
> > адаптерами?
>
> "нужный modalias в системе вытягивается через udev_trigger". Чем
> отличается в этом случае система с 2мя адаптерами? И что решит тебе
> переключалка, если единовременно в системе все равно может быть только
> одна рабочаяя копия при N установленных.

Ты не в теме:) Как раз на тонких клиентах переключалка решает, и клиенты с 
общим корнем и с РАЗНЫМИ адаптерами, поддерживаемыми РАЗНЫМИ версиями 
драйверов nvidia (в т.ч.) - РАБОТАЮТ:)
Открываю секрет:
man tmpfs
man mount (на предмет --bind)

-- 
Led

[devel] nvidia_glx-*

[Michael Shigorin]

On Fri, Oct 03, 2008 at 02:01:03AM +0400, Konstantin A. Lepikhov wrote:
> Что мешает вынести все, что связано с _glx-71.86.06 в отдельный
> пакет, прикрутить к нему этот уникальный .xinf, поставить
> conflicts: с текущей версией _glx и не заниматься ерундой?

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

Ты б ещё в lyx предложил поставить конфликт на openoffice.org,
потому как всё давно украдено до "офисов", как за-вещал vsl@.

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

Да, ещё про тонких клиентов просьба не забывать -- alterator-x11
вон теперь предстоит чинить назад от расчёта на hal'изацию.
Тут главная проблема -- отсутствие ручного вмешательства.

> Работу по переключению (точнее по доустановке необходимых
> пакетов) может делать утилита, которая примет список provides:
> modalias:<xxxxx>, найдет нужный modalias в системе через
> udev_trigger и вытянет пакет из репозитория.

Несуществующая утилита не может делать ничего.

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

Re: [devel] nvidia_glx-*

[Alexey Gladkov]

Michael Shigorin wrote:
>> Работу по переключению (точнее по доустановке необходимых
>> пакетов) может делать утилита, которая примет список provides:
>> modalias:<xxxxx>, найдет нужный modalias в системе через
>> udev_trigger и вытянет пакет из репозитория.
> 
> Несуществующая утилита не может делать ничего.

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

P.S. Давайте сбавим накал дискуссии. Для всех будет лучше, если эмоций 
в письмах будет меньше (Миш, это не конкретно тебе относится).

-- 
Rgrds, legion

Re: [devel] nvidia_glx-*

[Anton Farygin]

Alexey Gladkov пишет:
> Michael Shigorin wrote:
>>> Работу по переключению (точнее по доустановке необходимых
>>> пакетов) может делать утилита, которая примет список provides:
>>> modalias:<xxxxx>, найдет нужный modalias в системе через
>>> udev_trigger и вытянет пакет из репозитория.
>>
>> Несуществующая утилита не может делать ничего.
> 
> Часть этой утилиты уже была реализована. Её воскресить ничего не стоит. 
> Если тебе интересна идея, то можно попробовать сделать прототип.
> 
> P.S. Давайте сбавим накал дискуссии. Для всех будет лучше, если эмоций в 
> письмах будет меньше (Миш, это не конкретно тебе относится).

Кстати, очень интересная мысль - нам более актуально придумать схему, в 
которой X сервер будет запускаться при смене видеоадаптера.

Правда, тут может вылезти проблема - какому-то скрипту придётся лезть в 
xorg.conf и править его.

Либо, обнаружив смену видеоадаптера - запускать alterator-x11 в режиме 
vesa/fbdev.

Тут поле непахано.

Re: [devel] nvidia_glx-*

[Mikhail Gusarov]

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

Twas brillig at 11:27:40 03.10.2008 UTC+04 when rider@altlinux.com did gyre and gimble:

 AF> Либо, обнаружив смену видеоадаптера - запускать alterator-x11 в
 AF> режиме vesa/fbdev.

 AF> Тут поле непахано.

У убунты failsafe взять можно.

-- 

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

Re: [devel] nvidia_glx-*

[Anton Farygin]

Mikhail Gusarov пишет:
> Twas brillig at 11:27:40 03.10.2008 UTC+04 when rider@altlinux.com did gyre and gimble:
> 
>  AF> Либо, обнаружив смену видеоадаптера - запускать alterator-x11 в
>  AF> режиме vesa/fbdev.
> 
>  AF> Тут поле непахано.
> 
> У убунты failsafe взять можно.

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

Re: [devel] nvidia_glx-*

[Sergey V Turchin]

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

On Friday 03 October 2008, Anton Farygin wrote:

[...]
> Либо, обнаружив смену видеоадаптера - запускать alterator-x11 в
> режиме vesa/fbdev.
alterator-x11 наконец-то научился запускаться из консоли

-- 
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: 197 bytes --]

Re: [devel] nvidia_glx-*

[Michael Shigorin]

On Fri, Oct 03, 2008 at 03:58:29AM +0400, Alexey Gladkov wrote:
> >>Работу по переключению (точнее по доустановке необходимых
> >>пакетов) может делать утилита, которая примет список provides:
> >>modalias:<xxxxx>, найдет нужный modalias в системе через
> >>udev_trigger и вытянет пакет из репозитория.
> >Несуществующая утилита не может делать ничего.
> Часть этой утилиты уже была реализована. Её воскресить ничего
> не стоит. Если тебе интересна идея, то можно попробовать
> сделать прототип.

Давай попробуем.

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

> P.S. Давайте сбавим накал дискуссии. Для всех будет лучше,
> если эмоций в письмах будет меньше (Миш, это не конкретно тебе
> относится).

Но мне тоже так кажется.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Vitaly Ostanin]

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

Sergey V Turchin пишет:
> On Thursday 02 October 2008, Vitaly Ostanin wrote:
> 
> [...]
>> Спасибо, поставил. Хорошо бы этот пакет кто-нибудь вытягивал по
>> зависимостям, раз он такой полезный.
> Инсталлятор это делает со времен 3.0 (ранее в виде пакета hardware ( 
> x11_autosetup его obsolete))

Серверный не делает, кроме того, это не зависимость 
"системообразующего пакета" :) Нужно учитывать потребность в 
переключении server/desktop с помощью пакетной базы, а не 
установщика. Или хотя бы с помощью alterator-fbi.

Так получилось, что когда-то давно desktop x86_64 можно было 
получить, установив server x86_64. А партии нужны тестеры x86_64 
на desktop :)

-- 
Regards, Vyt
mailto:  vyt@altlinux.org
JID:     vitaly.ostanin@gmail.com


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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> > При запуске сервиса x11presetdrv запускаются все программы из
> > каталога /usr/libexec/X11/drvpre.d/ , одна из которых nvidia.
>
> Не запускаются:
Забыл, что было в 4.0 с fglrx ?

[...]

В bugzilla напиши, пожалуйста, с указанием куда ведут битые ссылки.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Thursday 02, at 02:11:34 PM you wrote:

> On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:
> 
> [...]
> > > При запуске сервиса x11presetdrv запускаются все программы из
> > > каталога /usr/libexec/X11/drvpre.d/ , одна из которых nvidia.
> >
> > Не запускаются:
> Забыл, что было в 4.0 с fglrx ?
> 
> [...]
У меня ничего не было. Кстати, и в 4.1 с fglrx полная фигня. Это ж "не
дистрибутивообразующий пакет" (с) boyarsh@ 

> 
> В bugzilla напиши, пожалуйста, с указанием куда ведут битые ссылки.
> 
Напишу. Только не в бранч, а в сизиф.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> У меня ничего не было.
> Кстати, и в 4.1 с fglrx полная фигня.
У меня никакой фигни нет ;-)

[...]
> Напишу.
Неправильный ответ. Правильный -- "написал".

[...]

-- 
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: 197 bytes --]

[devel] x11*drv

[Michael Shigorin]

On Thu, Oct 02, 2008 at 01:37:00PM +0400, Konstantin A. Lepikhov wrote:
> Стабильно после обновления ядра получаю мигание экрана вместо
> запуска xorg и битые симлинки в /etc/X11
> Помогает только повторная перезагрузка в single и запуск
> x11setupdrv руками.

BTW текущий update-kernel на эту тему исправлялся (но провести
столь же чистый эксперимент по обновлению с той поры не добирался).

> Здорово - если я обновлю ядро через rpm -Fhv, то в момент
> запуска "автоугадава" ядра у меня уже в системе не будет и
> /lib/modules/'uname -r' будет пуст. И далее вся эта мурдёная
> логика идет лесом.

Если к этому моменту у тебя не будет загружен модуль,
то всё равно уже к Dr. Reboot (или ставить текущее ядро).

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

Re: [devel] x11*drv

[Konstantin A. Lepikhov]

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

Hi Michael!

Thursday 02, at 05:09:08 PM you wrote:

> On Thu, Oct 02, 2008 at 01:37:00PM +0400, Konstantin A. Lepikhov wrote:
> > Стабильно после обновления ядра получаю мигание экрана вместо
> > запуска xorg и битые симлинки в /etc/X11
> > Помогает только повторная перезагрузка в single и запуск
> > x11setupdrv руками.
> 
> BTW текущий update-kernel на эту тему исправлялся (но провести
> столь же чистый эксперимент по обновлению с той поры не добирался).
Вообще-то такие действия можно сделать и руками.

> 
> > Здорово - если я обновлю ядро через rpm -Fhv, то в момент
> > запуска "автоугадава" ядра у меня уже в системе не будет и
> > /lib/modules/'uname -r' будет пуст. И далее вся эта мурдёная
> > логика идет лесом.
> 
> Если к этому моменту у тебя не будет загружен модуль,
> то всё равно уже к Dr. Reboot (или ставить текущее ядро).
Повторяю для тех, кто в танке - при последующей перезагрузке я получу
навечно мигающий монитор из-за битых симлинков на модули ядра. 

-- 
WBR et al.

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

Re: [devel] x11*drv

[Michael Shigorin]

On Thu, Oct 02, 2008 at 11:09:34PM +0400, Konstantin A. Lepikhov wrote:
> > > Стабильно после обновления ядра получаю мигание экрана
> > > вместо запуска xorg и битые симлинки в /etc/X11
> > > Помогает только повторная перезагрузка в single и запуск
> > > x11setupdrv руками.
> > BTW текущий update-kernel на эту тему исправлялся (но
> > провести столь же чистый эксперимент по обновлению с той поры
> > не добирался).
> Вообще-то такие действия можно сделать и руками.

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

> > > Здорово - если я обновлю ядро через rpm -Fhv, то в момент
> > > запуска "автоугадава" ядра у меня уже в системе не будет и
> > > /lib/modules/'uname -r' будет пуст. И далее вся эта
> > > мурдёная логика идет лесом.
> > Если к этому моменту у тебя не будет загружен модуль,
> > то всё равно уже к Dr. Reboot (или ставить текущее ядро).
> Повторяю для тех, кто в танке

Костик, дружище, почитай коммиты в update-kernel :-)

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

Пару недель тому и поймал (только не помню, какие именно симлинки
-- точно помню, что менялась рабочая версия nvidia_glx).
Добавил пять строк, поехал дальше.

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

Давай лучше в эту сторону чего сделаем, чем чинить то, что если 
и сломано, то гораздо меньше?

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

Re: [devel] x11*drv

[Led]

On Thursday, 02 October 2008 23:58:03 Michael Shigorin wrote:
> On Thu, Oct 02, 2008 at 11:09:34PM +0400, Konstantin A. Lepikhov wrote:
> > > > Стабильно после обновления ядра получаю мигание экрана
> > > > вместо запуска xorg и битые симлинки в /etc/X11
> > > > Помогает только повторная перезагрузка в single и запуск
> > > > x11setupdrv руками.
> > >
> > > BTW текущий update-kernel на эту тему исправлялся (но
> > > провести столь же чистый эксперимент по обновлению с той поры
> > > не добирался).
> >
> > Вообще-то такие действия можно сделать и руками.
>
> Конечно.  Вопрос в том, какие способы получается оградить от
> проблем автоматом, а какие -- сложно.
>
> > > > Здорово - если я обновлю ядро через rpm -Fhv, то в момент
> > > > запуска "автоугадава" ядра у меня уже в системе не будет и
> > > > /lib/modules/'uname -r' будет пуст. И далее вся эта
> > > > мурдёная логика идет лесом.
> > >
> > > Если к этому моменту у тебя не будет загружен модуль,
> > > то всё равно уже к Dr. Reboot (или ставить текущее ядро).
> >
> > Повторяю для тех, кто в танке
>
> Костик, дружище, почитай коммиты в update-kernel :-)
>
> > - при последующей перезагрузке я получу навечно мигающий
> > монитор из-за битых симлинков на модули ядра.
>
> Пару недель тому и поймал (только не помню, какие именно симлинки
> -- точно помню, что менялась рабочая версия nvidia_glx).
> Добавил пять строк, поехал дальше.
>
> На самом деле надо что-то сделать с _бесконечностью_ вываливания
> и тем, что никто не почешется попытаться сделать фолбэк на vesa
> или запуститься без конфига...

ИМХО перед "фолбэк на vesa" неплохо бы запустить x11_autosetup и попробовать 
загрузиться с сгенерированным им в /tmp xorg.conf.auto

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

-- 
Led

Re: [devel] x11*drv

[Anton Farygin]

Led пишет:
> On Thursday, 02 October 2008 23:58:03 Michael Shigorin wrote:
<skip>
>> На самом деле надо что-то сделать с _бесконечностью_ вываливания
>> и тем, что никто не почешется попытаться сделать фолбэк на vesa
>> или запуститься без конфига...
> 
> ИМХО перед "фолбэк на vesa" неплохо бы запустить x11_autosetup и попробовать 
> загрузиться с сгенерированным им в /tmp xorg.conf.auto

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

Re: [devel] x11*drv

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> Повторяю для тех, кто в танке - при последующей перезагрузке я
> получу навечно мигающий монитор из-за битых симлинков на модули
> ядра.
Человек, который не в состоянии разобраться с настройками, 
предлагает простым пользователям делать в ручную update_kernel? Так?

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:

[...]
> > Это лучше пусть расскажет мантейнер kernel-modules-nvidia.
> мантейнер прячется в кусты с дешевыми отмазками.
От такого бреда скоро начну.

> У меня,
> например, после его "переключения" стабильно слетают ссылки на
> драйвера _xorg_ при обновлении _ядра_.
Опять кривой пакет fglrx?
Номер баги?

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Wednesday 01 October 2008, Konstantin A. Lepikhov wrote:

[...]
> меня давно интересовало, зачем _это_
Что такое "_это_" ?

> засовывать в kernel-modules, да еще и в /var/lib
Сделай переключатель драйверов для fglrx -- сделаю, как у тебя.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Sergey!

Wednesday 01, at 08:26:39 PM you wrote:

> On Wednesday 01 October 2008, Konstantin A. Lepikhov wrote:
> 
> [...]
> > меня давно интересовало, зачем _это_
> Что такое "_это_" ?
Этот странный процесс, когда ты обновляешь модуль ядра, а он портит
настройки xorg.

> 
> > засовывать в kernel-modules, да еще и в /var/lib
> Сделай переключатель драйверов для fglrx -- сделаю, как у тебя.
fglrx прекрасно работает без переключателя.

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Sergey V Turchin]

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

On Thursday 02 October 2008, Konstantin A. Lepikhov wrote:
> Hi Sergey!

[...]
> > Что такое "_это_" ?
> Этот странный процесс, когда ты обновляешь модуль ядра, а он
> портит настройки xorg.
Ничего подобного нет в пакете kernel-modules-nvidia

> > > засовывать в kernel-modules, да еще и в /var/lib
> > Сделай переключатель драйверов для fglrx -- сделаю, как у тебя.
> fglrx прекрасно работает без переключателя.
Не замечал.

-- 
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: 197 bytes --]

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Michael Shigorin]

On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
> Кстати, насчет проверок. Есть мысль закрутить гайки совсем

Зачем?

PS: заметь, я не наезжаю и не шашкой с разбегу, а культурно.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Konstantin A. Lepikhov]

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

Hi Michael!

Thursday 02, at 04:47:13 PM you wrote:

> On Wed, Oct 01, 2008 at 04:13:48PM +0400, Konstantin A. Lepikhov wrote:
> > Кстати, насчет проверок. Есть мысль закрутить гайки совсем
> 
> Зачем?
> 
> PS: заметь, я не наезжаю и не шашкой с разбегу, а культурно.
Чтобы каждый раз лог cybertalk глазами не просматривать.

-- 
WBR et al.

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

[devel] [JT] "зачем?"

[Michael Shigorin]

On Thu, Oct 02, 2008 at 06:21:40PM +0400, Konstantin A. Lepikhov wrote:
> > > Кстати, насчет проверок. Есть мысль закрутить гайки совсем
> > Зачем?
> Чтобы каждый раз лог cybertalk глазами не просматривать.

Не просматривай.

Есть хороший принцип, родившийся из дискуссии с бздюками на почве
различия подхода к проведению наших осенних коференций:

	помогай или не мешай другим делать

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

Re: [devel] [JT] "зачем?"

[Konstantin A. Lepikhov]

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

Hi Michael!

Thursday 02, at 05:43:54 PM you wrote:

> On Thu, Oct 02, 2008 at 06:21:40PM +0400, Konstantin A. Lepikhov wrote:
> > > > Кстати, насчет проверок. Есть мысль закрутить гайки совсем
> > > Зачем?
> > Чтобы каждый раз лог cybertalk глазами не просматривать.
> 
> Не просматривай.
> 
> Есть хороший принцип, родившийся из дискуссии с бздюками на почве
> различия подхода к проведению наших осенних коференций:
> 
> 	помогай или не мешай другим делать
"тогда отойди и мешай" (с)

-- 
WBR et al.

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

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Dmitry V. Levin wrote:
> Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
> специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> Почему-то раньше это правило распространялось только на сторонние модули.
> 
> Впрочем, если есть совместное желание продлить действие этого исключения,
> то давайте зафиксируем этот факт и адаптируем sisyphus_check.

Вот например так:

http://git.altlinux.org/people/legion/packages/sisyphus_check.git?p=sisyphus_check.git;a=commit;h=24dc50454429e7a0f294b8be03efd511927b711c

-- 
Rgrds, legion

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 09:30:29 Alexey Gladkov wrote:
> Dmitry V. Levin wrote:
> > Считается, что имя релиза пакета kernel-modules-что-то-там должно иметь
> > специальный вид alt*.%KERNEL_MAGIC.%KERNEL_RELEASE
> > Почему-то раньше это правило распространялось только на сторонние модули.
> >
> > Впрочем, если есть совместное желание продлить действие этого исключения,
> > то давайте зафиксируем этот факт и адаптируем sisyphus_check.
>
> Вот например так:
>
> http://git.altlinux.org/people/legion/packages/sisyphus_check.git?p=sisyphu
>s_check.git;a=commit;h=24dc50454429e7a0f294b8be03efd511927b711c

По-моему, логично

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Led wrote:
>> http://git.altlinux.org/people/legion/packages/sisyphus_check.git?p=sisyphu
>> s_check.git;a=commit;h=24dc50454429e7a0f294b8be03efd511927b711c
> 
> По-моему, логично
> 

Сначала, предполагалось, что модули, собираемые с ядром, исправить 
будет можно, но выяснилось, что это сделать очень сложно.

-- 
Rgrds, legion

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Led]

On Wednesday, 01 October 2008 09:53:53 Alexey Gladkov wrote:
> Led wrote:
> >> http://git.altlinux.org/people/legion/packages/sisyphus_check.git?p=sisy
> >>phu s_check.git;a=commit;h=24dc50454429e7a0f294b8be03efd511927b711c
> >
> > По-моему, логично
>
> Сначала, предполагалось, что модули, собираемые с ядром, исправить
> будет можно, но выяснилось, что это сделать очень сложно.

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

-- 
Led

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Alexey Gladkov]

Alexey Gladkov wrote:
> Вот например так:

Дим, пока не делай новый релиз sisyphus_check только с этим 
изменением. У меня есть ощущение, что нужно дополнить 210-check-kernel 
ещё несколькими проверками.

-- 
Rgrds, legion

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Михаил Якушин]

Alexey Gladkov wrote:
> Alexey Gladkov wrote:
>> Вот например так:
> 
> Дим, пока не делай новый релиз sisyphus_check только с этим изменением. 
> У меня есть ощущение, что нужно дополнить 210-check-kernel ещё 
> несколькими проверками.
> 
Интересно какими? Хотелось быть в курсе.

Re: [devel] E: incoming i586 reject: kernel-image-led-tc-2.6.22-alt23

[Dmitry V. Levin]

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

On Wed, Oct 01, 2008 at 03:51:23PM +0400, Alexey Gladkov wrote:
> Alexey Gladkov wrote:
> >Вот например так:
> 
> Дим, пока не делай новый релиз sisyphus_check только с этим 
> изменением.

Поздно, уже сделал.
К тому же на него завязано ядро, которое пришло в incoming.


-- 
ldv

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