32469 2016-09-03 17:40:53 +0300 Отсутствует модуль kernel-modules-nvidia-un-def 2016-10-21 02:12:31 +0300 1 1 3 Distributions Branch p8 kernel-image-un-def не указана all Linux CLOSED FIXED P3 normal --- 1 drool boyarsh aen alxste anubix cas mike zerg qa-p8 oldest_to_newest 158429 0 drool 2016-09-03 17:40:53 +0300 Может, уже пора вернуть в p8 kernel-modules-nvidia-un-def ? 158442 1 boyarsh 2016-09-05 13:54:33 +0300 Если мантейер модуля (в данном случае zerg@ ) не собирает его для тех или иных ядер, то кто ж может его заставить. 158446 2 drool 2016-09-05 21:10:23 +0300 (В ответ на комментарий №1) > Если мантейер модуля (в данном случае zerg@ ) не собирает его для тех или иных > ядер, то кто ж может его заставить. Там была какая-то несрастуха, и он вылетел из сизифа и p8. В сизифе уже вернули, а про p8 забыли. 158539 3 alxste 2016-09-10 17:07:12 +0300 В сизифе пакет собран. 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. 158543 4 alxste 2016-09-11 13:49:16 +0300 # 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. 158550 5 boyarsh 2016-09-12 11:42:32 +0300 > 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 не соберёшь его для этого ядра -- зачем получать на свою голову мороку с несобирающимся заданием? 158806 6 drool 2016-09-27 22:10:35 +0300 *** Bug 32257 has been marked as a duplicate of this bug. *** 158922 7 drool 2016-10-03 02:22:21 +0300 Я так понял, p8 умер, еще толком не родившись... 158942 8 mike 2016-10-03 14:13:36 +0300 (В ответ на комментарий №7) > Я так понял, p8 умер, еще толком не родившись... Это не про p8, а про kernel-modules-nvidia-un-def -- с которым есть как объективные проблемы (сборка отваливается, нвидия чинит асинхронно), так и субъективные -- кому именно с последствиями бороться... 159219 9 aen 2016-10-15 23:28:24 +0300 Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер. Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич, поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности разработчиков NVidia, то будете недовольны. 2zerg: можно ли собирать этот драйвер для un-def в p8 "сбоку"? Без размещения в бранче и, тем более, дистрибутивах и оговаривая, что обновляться нужно осторожно, проверяя наличие сборки для текущего un-def? 159221 10 anubix 2016-10-16 08:40:13 +0300 (В ответ на комментарий №9) > 2zerg: можно ли собирать этот драйвер для un-def в p8 "сбоку"? Я пользуююсь std-def в p8. 159225 11 drool 2016-10-16 21:57:21 +0300 (В ответ на комментарий №9) > Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер. > Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной > разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич, > поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности > разработчиков NVidia, то будете недовольны. Это смешно. Чуть ли не пол года тому модуль вылетел из сизифа, а соответственно и p8, т.к. не собрался на автомате с новым un-def, и в рассылке пояснили, что мантейнер, если не ошибаюсь, в отпуске. Мантейнер вышел из отпуска? Судя по тому, что модуль в сизифе вернулся - вышел. А вот в p8 его скопировать вместе с ядром уже не судьба? 159226 12 drool 2016-10-16 22:00:32 +0300 Мой вопрос был еще в августе: https://lists.altlinux.org/pipermail/community/2016-August/685990.html 159227 13 drool 2016-10-16 22:02:48 +0300 (В ответ на комментарий №12) > Мой вопрос был еще в августе... Это я заметил, что в сизифе модуль вернулся. А "отпускная" причина была озвучена здесь https://lists.altlinux.org/pipermail/sisyphus/2016-June/365429.html 159228 14 drool 2016-10-16 22:05:21 +0300 Улетели модули в июне: https://lists.altlinux.org/pipermail/sisyphus/2016-June/365422.html 159242 15 boyarsh 2016-10-17 12:47:41 +0300 (В ответ на комментарий №11) > (В ответ на комментарий №9) > > Проблема в непредсказуемости появления версий драйверов nvidia для новых ядер. > > Не думаю, что будет правильно блокировать новые ядра в p8 из-за проприетарной > > разработки. Геннадий, Вы ведь и сами используете un-def из-за новых фич, > > поддержки нового железа и, если мы затормозим его сборку из-за нерасторопности > > разработчиков NVidia, то будете недовольны. > > Это смешно. Чуть ли не пол года тому модуль вылетел из сизифа, а соответственно > и p8, т.к. не собрался на автомате с новым un-def, и в рассылке пояснили, что > мантейнер, если не ошибаюсь, в отпуске. Мантейнер вышел из отпуска? Судя по > тому, что модуль в сизифе вернулся - вышел. А вот в p8 его скопировать вместе с > ядром уже не судьба? Ядро в p8 не копируется, а собирается там. Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля следует собрать его для всех возможных ядер. Мантейнер модуля nvidia считает, что при изменении версии модуля, для части ядер он соберёт его сам, а для остальных -- мантейнер ядра. При том, что если уже есть коммит, на него можно поставить произвольное число тэгов и собрать их. 159248 16 anubix 2016-10-17 16:41:49 +0300 (В ответ на комментарий №15) > Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля > следует собрать его для всех возможных ядер. Соглашусь лишь с тем, что считать, что другим следует делать что-то из того, что сам не делаешь, достаточно не сложно. > Мантейнер модуля nvidia считает, что при изменении версии модуля, для части > ядер он соберёт его сам, а для остальных -- мантейнер ядра. Не для части, а только для одного -- std-def, но т.к. он еще и пользуется "последним стабильным бранчем" и имеет возможность сам собрать и проверить работоспособность на нем модуля для std-def, то бонусом делает это, т.к. не считает более правильным собирать "сбоку" для себя лично. > При том, что если уже есть коммит, на него можно поставить произвольное число > тэгов и собрать их. Права на новые пакеты в p8 из этих мантейнеров есть только у мантейнера ядра, поэтому, как ни крути, ему собрать в p8 проще. 159249 17 boyarsh 2016-10-17 17:24:17 +0300 > > Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля > > следует собрать его для всех возможных ядер. > Соглашусь лишь с тем, что считать, что другим следует делать что-то из того, > что сам не делаешь, достаточно не сложно. Да. Наша система сборки модулей ядра позволяет не беспокоить мантейнеров модулей при минорных обновлениях ядра и не беспокоить мантейнеров ядра при обновлении модулей. При этом в ALT вообще говоря, не считается хорошим поступком сломать собираемость пакета, когда этого можно легко избежать. Для регулярно пересобираемых пакетов, таких как ядра, это тем более важно. > Не для части, а только для одного -- std-def, но т.к. он еще и пользуется > "последним стабильным бранчем" и имеет возможность сам собрать и проверить > работоспособность на нем модуля для std-def, то бонусом делает это, т.к. не > считает более правильным собирать "сбоку" для себя лично. Мантейнер ядра un-def не пользуется проприретарным драйвером nvidia. > p8 из этих мантейнеров есть только у мантейнера ядра, > поэтому, как ни крути, ему собрать в p8 проще. За acl бы дело не стало. 159253 18 anubix 2016-10-17 19:14:37 +0300 (В ответ на комментарий №17) > > p8 из этих мантейнеров есть только у мантейнера ядра, > > поэтому, как ни крути, ему собрать в p8 проще. > За acl бы дело не стало. Мне бы это помогло когда-нибуль собирать kernel-modules-crystalhd, разве что. 159254 19 anubix 2016-10-17 19:17:04 +0300 (В ответ на комментарий №17) > Мантейнер ядра un-def не пользуется проприретарным драйвером nvidia. Я и не предлагал кому-то еще пользоваться. 159255 20 anubix 2016-10-17 19:20:39 +0300 (В ответ на комментарий №17) > > > Мантейнер ядра считает, что при изменении версии модуля, мантейнеру модуля > > > следует собрать его для всех возможных ядер. > > Соглашусь лишь с тем, что считать, что другим следует делать что-то из того, > > что сам не делаешь, достаточно не сложно. > Да. [...] > При этом в ALT вообще говоря, не считается хорошим поступком считать, что другим следует делать что-то из того, что сам не делаешь. 159256 21 anubix 2016-10-17 20:27:41 +0300 Ну и ко всему остальному: после того, как мантейнер модуля собрал nvidia-un-def, то в p8 вместе с новыми сборками kernel-un-def его никто зачем-то не собрал по меньшей мере 5 раз. 159261 22 boyarsh 2016-10-18 10:16:11 +0300 (В ответ на комментарий №21) > Ну и ко всему остальному: после того, как мантейнер модуля собрал > nvidia-un-def, то в p8 вместе с новыми сборками kernel-un-def его никто > зачем-то не собрал по меньшей мере 5 раз. Чтоб ты поломал мне очередную сборку задания с ядром, выбив из под него исходники, но не собрав модуль? 159263 23 zerg 2016-10-18 11:47:42 +0300 (В ответ на комментарий №22) > Чтоб ты поломал мне очередную сборку задания с ядром, выбив из под него > исходники, но не собрав модуль? Не сочиняй. Из p8 исходники не "выбивались" _никогда_ . P.S. И даже в Sisyphus давно удовлетворил твою жалобу. https://lists.altlinux.org/pipermail/sisyphus/2016-June/365451.html 159264 24 aen 2016-10-18 11:54:55 +0300 Коллеги, хватит. Давайте искать решение. Я пока вижу следующее: 1. Мы не можем гарантировать в un-def поддержку проприетарных драйверов.Это нужно публично заявить. 2. Нам нужно стараться дать возможность пользователям их использовать, предупреждая при выпадении таких драйверов из сборок новых ядер un-def. 159285 25 aen 2016-10-19 21:00:33 +0300 [#171009] p8 DONE (try 2) kernel-modules.git=sisyphus/kernel-modules-nvidia-un-def-367.35-alt1 Спасибо! 159294 26 drool 2016-10-20 11:30:03 +0300 (В ответ на комментарий №24) > 1. Мы не можем гарантировать в un-def поддержку проприетарных драйверов.Это > нужно публично заявить. > 2. Нам нужно стараться дать возможность пользователям их использовать, > предупреждая при выпадении таких драйверов из сборок новых ядер un-def. 1. Если это так то 2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного сизифа то, что сломает что-либо либо с отвалившимися частями/модулями. Кому нужен свежий экстрим - тот на сизиф может съехать всегда, а нам, пользователям бранчей, лучше на предыдущей версии чего-то, то без отвала сопутствующего компонента. 159297 27 aen 2016-10-20 11:45:01 +0300 (В ответ на комментарий №26) > 2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного > сизифа то, что сломает что-либо либо с отвалившимися частями/модулями. Кому > нужен свежий экстрим - тот на сизиф может съехать всегда, а нам, пользователям > бранчей, лучше на предыдущей версии чего-то, то без отвала сопутствующего > компонента. Мне осталось непонятно, зачем Вы используете un-def, а не std-def. Ядро un-def не "переклаывается без огладки", оно вполне стабильно, нужно для поддержки нового железа и/или новых возможностей, но производители сторонних драйверов могут запаздывать и нельзя задерживать возможность использования нового железа, которая нужна нашим партнерам-OEM и пользователям новинок из-за них. Вместе с тем, поддержка драйвера nvidia завдомо обеспечивается в std-def. ? 159312 28 mike 2016-10-20 14:01:07 +0300 (В ответ на комментарий №26) > 2. Не нужно в стабильные бранчи без оглядки перекладывать из нестабильного > сизифа то, что сломает что-либо либо с отвалившимися частями/модулями. Конкретно в случае ядра это сейчас не такая большая беда -- устанавливается-то оно всяко по явному указанию root@localhost, как и старые удаляются (разумеется, после проверки работоспособности нового)... 159338 29 drool 2016-10-21 02:12:31 +0300 (В ответ на комментарий №27) > Мне осталось непонятно, зачем Вы используете un-def, а не std-def. На одной из материнок на работе у меня только на un-def заводится все, что у нее есть на борту.