Если мантейер модуля (в данном случае zerg@ ) не собирает его для тех или иных ядер, то кто ж может его заставить.

(В ответ на комментарий №1)
> Если мантейер модуля (в данном случае zerg@ ) не собирает его для тех или иных
> ядер, то кто ж может его заставить.

Там была какая-то несрастуха, и он вылетел из сизифа и p8. В сизифе уже вернули, а про p8 забыли.

В сизифе пакет собран.
https://packages.altlinux.org/en/Sisyphus/srpms/kernel-modules-nvidia-un-def

2016-09-08 Sergey V Turchin <zerg at altlinux.org> 367.35-alt1.263939.1

    - Build for kernel-image-un-def-4.7.3-alt1.

# apt-repo
rpm [updates] http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/branch x86_64 classic
rpm [updates] http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/branch noarch classic
rpm [updates] http://ftp.altlinux.org/pub/distributions/ALTLinux/p8/branch x86_64-i586 classic

# apt-cache search kernel-modules-nvidia
kernel-modules-nvidia-el-def - nVidia video card drivers
kernel-modules-nvidia-hpc-skif - nVidia video card drivers
kernel-modules-nvidia-led-vs - nVidia video card drivers
kernel-modules-nvidia-sec-def - nVidia video card drivers
kernel-modules-nvidia-std-def - nVidia video card drivers

Собрано  для всех ядер кроме un-def.

> 2016-09-08 Sergey V Turchin <zerg at altlinux.org> 367.35-alt1.263939.1
> 
>     - Build for kernel-image-un-def-4.7.3-alt1.
Если бы ты потратил 10 минут на то, чтоб понять workflow сборки ядер и модулей для них, ты бы понял, почему это мало что меняет. Да, собрать модуль в p8 несложно, но если в следующий раз, обновляя nvidia в p8 не соберёшь его для этого ядра -- зачем получать на свою голову мороку с несобирающимся заданием?

*** Bug 32257 has been marked as a duplicate of this bug. ***

Я так понял, p8 умер, еще толком не родившись...

(В ответ на комментарий №7)
> Я так понял, p8 умер, еще толком не родившись...
Это не про p8, а про kernel-modules-nvidia-un-def -- с которым есть как объективные проблемы (сборка отваливается, нвидия чинит асинхронно), так и субъективные -- кому именно с последствиями бороться...

Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер. Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич, поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности разработчиков NVidia, то будете недовольны.

2zerg: можно ли собирать этот драйвер для un-def в p8 "сбоку"? Без размещения в бранче и, тем более, дистрибутивах и оговаривая, что обновляться нужно осторожно, проверяя наличие сборки для текущего un-def?

(В ответ на комментарий №9)
> 2zerg: можно ли собирать этот драйвер для un-def в p8 "сбоку"?
Я пользуююсь std-def в p8.

(В ответ на комментарий №9)
> Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер.
> Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной
> разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич,
> поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности
> разработчиков NVidia, то будете недовольны.

Это смешно. Чуть ли не пол года тому модуль вылетел из сизифа, а соответственно и p8, т.к. не собрался на автомате с новым un-def, и в рассылке пояснили, что мантейнер, если не ошибаюсь, в отпуске. Мантейнер вышел из отпуска? Судя по тому, что модуль в сизифе вернулся - вышел. А вот в p8 его скопировать вместе с ядром уже не судьба?

Мой вопрос был еще в августе: https://lists.altlinux.org/pipermail/community/2016-August/685990.html

(В ответ на комментарий №12)
> Мой вопрос был еще в августе...

Это я заметил, что в сизифе модуль вернулся. А "отпускная" причина была озвучена здесь https://lists.altlinux.org/pipermail/sisyphus/2016-June/365429.html

Улетели модули в июне: https://lists.altlinux.org/pipermail/sisyphus/2016-June/365422.html

(В ответ на комментарий №11)
> (В ответ на комментарий №9)
> > Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер.
> > Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной
> > разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич,
> > поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности
> > разработчиков NVidia, то будете недовольны.
> 
> Это смешно. Чуть ли не пол года тому модуль вылетел из сизифа, а соответственно
> и p8, т.к. не собрался на автомате с новым un-def, и в рассылке пояснили, что
> мантейнер, если не ошибаюсь, в отпуске. Мантейнер вышел из отпуска? Судя по
> тому, что модуль в сизифе вернулся - вышел. А вот в p8 его скопировать вместе с
> ядром уже не судьба?
Ядро в p8 не копируется, а собирается там.
Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля следует собрать его для всех возможных ядер.
Мантейнер модуля nvidia считает, что при изменении версии модуля, для части ядер он соберёт его сам, а для остальных -- мантейнер ядра.
При том, что если уже есть коммит, на него можно поставить произвольное число тэгов и собрать их.

(В ответ на комментарий №15)
> Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля
> следует собрать его для всех возможных ядер.
Соглашусь лишь с тем, что считать, что другим следует делать что-то из того, что сам не делаешь, достаточно не сложно.

> Мантейнер модуля nvidia считает, что при изменении версии модуля, для части
> ядер он соберёт его сам, а для остальных -- мантейнер ядра.
Не для части, а только для одного -- std-def, но т.к. он еще и пользуется "последним стабильным бранчем" и имеет возможность сам собрать и проверить работоспособность на нем модуля для std-def, то бонусом делает это, т.к. не считает более правильным собирать "сбоку" для себя лично.

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

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

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

> Не для части, а только для одного -- std-def, но т.к. он еще и пользуется
> "последним стабильным бранчем" и имеет возможность сам собрать и проверить
> работоспособность на нем модуля для std-def, то бонусом делает это, т.к. не
> считает более правильным собирать "сбоку" для себя лично.
Мантейнер ядра un-def не пользуется проприретарным драйвером nvidia.

> p8 из этих мантейнеров есть только у мантейнера ядра,
> поэтому, как ни крути, ему собрать в p8 проще.
За acl бы дело не стало.

(В ответ на комментарий №17)
> > p8 из этих мантейнеров есть только у мантейнера ядра,
> > поэтому, как ни крути, ему собрать в p8 проще.
> За acl бы дело не стало.
Мне бы это помогло когда-нибуль собирать kernel-modules-crystalhd, разве что.

(В ответ на комментарий №17)
> Мантейнер ядра un-def не пользуется проприретарным драйвером nvidia.
Я и не предлагал кому-то еще пользоваться.

(В ответ на комментарий №17)
> > > Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля
> > > следует собрать его для всех возможных ядер.
> > Соглашусь лишь с тем, что считать, что другим следует делать что-то из того,
> > что сам не делаешь, достаточно не сложно.
> Да.

[...]
 
> При этом в ALT вообще говоря, не считается хорошим поступком
считать, что другим следует делать что-то из того, что сам не делаешь.

Ну и ко всему остальному: после того, как мантейнер модуля собрал nvidia-un-def, то в p8 вместе с новыми сборками kernel-un-def его никто зачем-то не собрал по меньшей мере 5 раз.

(В ответ на комментарий №21)
> Ну и ко всему остальному: после того, как мантейнер модуля собрал
> nvidia-un-def, то в p8 вместе с новыми сборками kernel-un-def его никто
> зачем-то не собрал по меньшей мере 5 раз.

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

(В ответ на комментарий №22)
> Чтоб ты поломал мне очередную сборку задания с ядром, выбив из под него
> исходники, но не собрав модуль?
Не сочиняй. Из p8 исходники не "выбивались" _никогда_ .

P.S.
И даже в Sisyphus давно удовлетворил твою жалобу.
https://lists.altlinux.org/pipermail/sisyphus/2016-June/365451.html

Коллеги, хватит. Давайте искать решение. Я пока вижу следующее:
1. Мы не можем гарантировать в un-def поддержку проприетарных драйверов.Это нужно публично заявить.
2. Нам нужно стараться дать возможность пользователям их использовать, предупреждая при выпадении таких драйверов из сборок новых ядер un-def.

[#171009] p8 DONE (try 2) kernel-modules.git=sisyphus/kernel-modules-nvidia-un-def-367.35-alt1

Спасибо!

(В ответ на комментарий №24)
> 1. Мы не можем гарантировать в un-def поддержку проприетарных драйверов.Это
> нужно публично заявить.
> 2. Нам нужно стараться дать возможность пользователям их использовать,
> предупреждая при выпадении таких драйверов из сборок новых ядер un-def.

1. Если это так то
2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного сизифа то, что сломает что-либо либо с отвалившимися частями/модулями. Кому нужен свежий экстрим - тот на сизиф может съехать всегда, а нам, пользователям бранчей, лучше на предыдущей версии чего-то, то без отвала сопутствующего компонента.

(В ответ на комментарий №26)

> 2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного
> сизифа то, что сломает что-либо либо с отвалившимися частями/модулями. Кому
> нужен свежий экстрим - тот на сизиф может съехать всегда, а нам, пользователям
> бранчей, лучше на предыдущей версии чего-то, то без отвала сопутствующего
> компонента.

Мне осталось непонятно, зачем Вы используете un-def, а не std-def. Ядро un-def не "переклаывается без огладки", оно вполне стабильно, нужно для поддержки нового железа и/или новых возможностей, но производители сторонних драйверов могут запаздывать и нельзя задерживать возможность использования нового железа, которая нужна нашим партнерам-OEM и пользователям новинок из-за них. 
Вместе с тем, поддержка драйвера nvidia завдомо обеспечивается в std-def.

?

(В ответ на комментарий №26)
> 2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного
> сизифа то, что сломает что-либо либо с отвалившимися частями/модулями.
Конкретно в случае ядра это сейчас не такая большая беда -- устанавливается-то оно всяко по явному указанию root@localhost, как и старые удаляются (разумеется, после проверки работоспособности нового)...

(В ответ на комментарий №27)
> Мне осталось непонятно, зачем Вы используете un-def, а не std-def.

На одной из материнок на работе у меня только на un-def заводится все, что у нее есть на борту.