28138 2012-11-28 01:22:10 +0400 kernel-image-std-pae: синхронизировать с std-def 2012-12-24 14:32:23 +0400 1 1 4 Development Sisyphus kernel-image-std-pae unstable all Linux CLOSED FIXED P4 major --- 1 aris boyarsh boyarsh cas dd1email evg glebfm kernelbot ldv led mike mithraen pv rider sbolshakov shrek sin slava vitty vsu vt zerg qa-sisyphus oldest_to_newest 135513 0 aris 2012-11-28 01:22:10 +0400 Обеспечить синхронную сбоорку std-def и std-pae. 135514 1 aen 2012-11-28 02:19:37 +0400 Нужно ли нам std-pae, не являющееся основным ни для одного дистрибутива, в Сизифе и в p7? Если да, то нужно ли его обновление, синхронное с std-def, в Сизифе? В p7? Прошу мотивировать мнения. 135521 2 boyarsh 2012-11-28 10:35:59 +0400 Если судьба этого пакета кого-то интересует, можно подумать о роботизации сборки std-pae, но тогда оно выйдет на новый, уровень нетестируемости. 135542 3 mike 2012-11-28 16:00:35 +0400 (In reply to comment #1) > Нужно ли нам std-pae, не являющееся основным ни для одного дистрибутива, > в Сизифе и в p7? Оно является вспомогательным и, помнится, устанавливалось автоматически вместо std-def при соответствующем объёме памяти на некоторых дистрибутивах пятой/шестой ветки. > Если да, то нужно ли его обновление, синхронное с std-def, в Сизифе? В p7? Насчёт именно синхронности не уверен, но некоторый уровень поддержки обеспечить пока стоит. В частности, пользуюсь им на одном десктопе и пользовался на сизифном ноутбуке, пока не перевёл его под led-ws с потерей доступности гигабайта памяти из четырёх (переехать на x86_64 тут не представляется разумным по соображениям взаимозаменяемости X60/X61). 135558 4 aen 2012-11-29 05:14:47 +0400 Все же не блокер для p7. 136201 5 pv 2012-12-20 23:09:59 +0400 Не знаю, сколько таких как я, но мне std-pae актуален. У меня на ноуте 8Gb при этом система i586 (по работе нужно). Если можно "роботизировать", сделайте пожалуйста. Я готов как тестировать, в плане как минимум сообщать, если очередная сборка не заработает. 136202 6 aen 2012-12-20 23:14:27 +0400 (В ответ на комментарий №5) > Не знаю, сколько таких как я, но мне std-pae актуален. > > У меня на ноуте 8Gb при этом система i586 (по работе нужно). > > Если можно "роботизировать", сделайте пожалуйста. > Я готов как тестировать, в плане как минимум сообщать, > если очередная сборка не заработает. 2boyarsh: подумайте о роботизации, ok? В Новом году, сейчас действительно не до того. 136218 7 boris 2012-12-21 09:21:51 +0400 в debian wheezy, как и в последних ubuntu, x86 ядро только одно. И как раз только pae. не pae ядер для х86 там не осталось 136219 8 mike 2012-12-21 12:17:48 +0400 (In reply to comment #5) > Не знаю, сколько таких как я, но мне std-pae актуален. +1 (comment #3); вариантов для страждущих вижу два: - использовать el-smp или подобное, где PAE в i586 есть по постановке задачи; - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. BTW std-pae можно сразу собирать как i686 по оптимизации. (In reply to comment #7) > не pae ядер для х86 там не осталось Если это так, то они не работают на VIA C3/C7, ранних Pentium M (~1.4--1.5GHz) и тех процессорах, которые были просто раньше PAE (Pentium, K5...). Не знаю, есть ли варианты Atom без поддержки PAE, хорошо бы уточнить у железячников. 136222 9 pv 2012-12-21 12:40:11 +0400 (В ответ на комментарий №8) > (In reply to comment #5) > > Не знаю, сколько таких как я, но мне std-pae актуален. > +1 (comment #3); вариантов для страждущих вижу два: > - использовать el-smp или подобное, где PAE в i586 есть по постановке задачи; [root@pvbook ~]# update-kernel -t el-smp Try to install new kernel kernel-image-el-smp-2.6.32-alt39 and update its modules [y]/n? n C el-smp похоже дела совсем плохо.. > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. А в данном случае всё-таки требуется знания... 136223 10 mike 2012-12-21 12:44:02 +0400 (In reply to comment #9) > C el-smp похоже дела совсем плохо.. Почему, просто это el6. Если что, у меня ovz-el на текущем сизифе вовсю используется на сборочнице. > > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. > А в данном случае всё-таки требуется знания... Угу. Некоторый объём уже есть, некоторый приобретаем и трудами glebfm@ уже улучшился (недавно была реализована автоматизированная пересборка модулей ядра). 136224 11 mike 2012-12-21 12:46:01 +0400 Ещё можно попробовать обсудить с boyarsh@ включение PAE в un-def/i586. Тогда ядро по умолчанию [должно] будет устанавливаться на всё, что горит, и выбор тоже будет. 136226 12 aen 2012-12-21 12:55:46 +0400 (В ответ на комментарий №9) > (В ответ на комментарий №8) > > (In reply to comment #5) > > > Не знаю, сколько таких как я, но мне std-pae актуален. > > +1 (comment #3); вариантов для страждущих вижу два: > > - использовать el-smp или подобное, где PAE в i586 есть по постановке задачи; > [root@pvbook ~]# update-kernel -t el-smp > Try to install new kernel kernel-image-el-smp-2.6.32-alt39 and update its > modules [y]/n? n > > C el-smp похоже дела совсем плохо.. Зачем так говорить? el-smp основан на ядре RHEL и будет этой версии до выхода следующего RHEL. > > > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. > А в данном случае всё-таки требуется знания... Вы хотите, чтобы мы поддерживали для i586 и std-def, и std-pae в равной степени? Этого не будет, -- мы бы и рады удовлетворить все пожелания, но всего не охватишь и новое будет приоритетнее. Потому, помимо текущего, есть два варианта, обсуждаемых здесь: 1. сборка std-pae "без гарантий", но с учетом багов, если таковые будут в bugzilla. 2. включение pae в std-def. В варианте 2 меня беспокоит не столько отказ от совсем старого железа (насчет Atom надо выяснить, но верится с трудом), сколько возможные потери в производительности и памяти на системах с небольшим количеством RAM, коих в этом сегменте подавляющее большинство. 136227 13 aen 2012-12-21 12:57:37 +0400 (В ответ на комментарий №11) > Ещё можно попробовать обсудить с boyarsh@ включение PAE в un-def/i586. > Тогда ядро по умолчанию [должно] будет устанавливаться на всё, что горит, > и выбор тоже будет. un-def сугубо экспериментальное ядро, потому этот вариант аналогичен 1. 136229 14 pv 2012-12-21 13:15:23 +0400 (В ответ на комментарий №12) > > C el-smp похоже дела совсем плохо.. > > Зачем так говорить? el-smp основан на ядре RHEL и будет этой версии до выхода > следующего RHEL. Я прошу прощения, не хотел никого обидеть. Я как-раз не знаю, особенностей el-smp (и о его связи с RHEL). Если так, то и вопросов нет. Я как простой пользователь, лишь сравнил версии. Для меня (обычного пользователя), "циферки побольше" - означает "лучше"... А на текущий момент, меня вполне устраивает текущее std-pae-3.5.7-alt1. Ноут даже засыпает и просыпается... Проблему (для себя) я вижу только в будущем. Когда текущая версия ядра будет уходить всё дальше и дальше 3.6.xx (3.7.xx и т.п.), в нём будут какие-то улучшения по поддержке нового железа и т.п., а то и (как было с 2.6.xx) udev перестанет поддерживать версии ниже определённой или ещё чего.. а std-pae останется, на текущей версии. То для меня встанет непростой выбор... > > > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. > > А в данном случае всё-таки требуется знания... > > Вы хотите, чтобы мы поддерживали для i586 и std-def, и std-pae в равной > степени? Этого не будет, -- мы бы и рады удовлетворить все пожелания, но всего > не охватишь и новое будет приоритетнее. Тогда и вопроса нет, у меня было только "желание", если это возможно и конечно это не должно быть приоритетным для вас. > Потому, помимо текущего, есть два > варианта, обсуждаемых здесь: > 1. сборка std-pae "без гарантий", но с учетом багов, если таковые будут в > bugzilla. > 2. включение pae в std-def. > > В варианте 2 меня беспокоит не столько отказ от совсем старого железа (насчет > Atom надо выяснить, но верится с трудом), сколько возможные потери в > производительности и памяти на системах с небольшим количеством RAM, коих в > этом сегменте подавляющее большинство. В этом смысле меня первый вариант вполне устраивает.. Я готов, сообщать о "поломках". 136230 15 boris 2012-12-21 13:17:57 +0400 > 2. включение pae в std-def. > > В варианте 2 меня беспокоит не столько отказ от совсем старого железа (насчет > Atom надо выяснить, но верится с трудом), сколько возможные потери в > производительности и памяти на системах с небольшим количеством RAM, коих в > этом сегменте подавляющее большинство. вот тут новость недавно была что поддержку i386 убрали из ядра. это прогресс. я вообще сильно сомневаюсь, что на старом железе нужно именно 3.х ядро. Есть мысль, что 2.6 на таком железе будет работать лучше всегда про потери в производительности и памяти мне нечего сказать. хотя я насчёт большинства не уверен. 136244 16 led 2012-12-21 16:35:24 +0400 (В ответ на комментарий №8) > (In reply to comment #5) > > Не знаю, сколько таких как я, но мне std-pae актуален. > +1 (comment #3); вариантов для страждущих вижу два: > - использовать el-smp или подобное, где PAE в i586 есть по постановке задачи; > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. Что мешает собирать std-def и std-pae из одного src.rpm, кроме того, что нужно один раз доработать спек для этого? 136246 17 repository-robot 2012-12-21 17:38:17 +0400 kernel-image-std-pae-1:3.6.11-alt1 -> sisyphus: * Thu Dec 20 2012 Gleb F-Malinovskiy <glebfm@altlinux> 1:3.6.11-alt1 - 3.6.11 (closes: 28138) - Build using std-def config with config diff from 3.5.7. 136261 18 vsu 2012-12-21 21:22:34 +0400 (В ответ на комментарий №9) > C el-smp похоже дела совсем плохо.. С ним плохо только то, что его своевременно не обновляют в p6, где ему самое место (а вот в сизифном userspace совместимость с этим ядром вполне может и сломаться). (В ответ на комментарий №12) > 1. сборка std-pae "без гарантий", но с учетом багов, если таковые будут в > bugzilla. > 2. включение pae в std-def. 3. 2 + сборка std-nonpae "без гарантий" для старого железа (хотя в некоторых свежих дистрибутивах от совместимости с подобным старым железом вовсе отказались). Но тут возникает проблема с ядром в инсталяторе - разве что класть туда два образа (ifcpu.c32 позволяет выбирать поддерживаемый вариант автоматически; правда, от раздувания /lib/modules это не спасает). > В варианте 2 меня беспокоит не столько отказ от совсем старого железа (насчет > Atom надо выяснить, но верится с трудом), сколько возможные потери в > производительности и памяти на системах с небольшим количеством RAM, коих в > этом сегменте подавляющее большинство. В Atom, скорее всего, всё есть; нет в старых Pentium M. (В ответ на комментарий №16) > Что мешает собирать std-def и std-pae из одного src.rpm, кроме того, что нужно > один раз доработать спек для этого? До последнего времени для этого потребовалось бы копирование половины спека. Хотя раньше свежее std-def просто регулярно мержилось в ветку std-pae (в 99% случаев конфиг ядра при этом даже не приходилось править руками). Сейчас можно попробовать сгородить что-нибудь с использованием specsubst. Был ещё вариант со сборкой с PAE при выборе --target i686, но это не лезет ни в сборочную систему, ни потом в apt. 136264 19 led 2012-12-21 22:10:49 +0400 (В ответ на комментарий №18) > (В ответ на комментарий №16) > > Что мешает собирать std-def и std-pae из одного src.rpm, кроме того, что нужно > > один раз доработать спек для этого? > До последнего времени для этого потребовалось бы копирование половины спека. > Хотя раньше свежее std-def просто регулярно мержилось в ветку std-pae (в 99% > случаев конфиг ядра при этом даже не приходилось править руками). Сейчас можно > попробовать сгородить что-нибудь с использованием specsubst. Думаю, это можно и без specsubst, используя %include > > Был ещё вариант со сборкой с PAE при выборе --target i686, но это не лезет ни в > сборочную систему, ни потом в apt. А по факту сейчас и std-def, и std-pae - i686, потому как в обоих CONFIG_PENTIUMII=y. Т.о. репозитарий i586 - фикция, потому как ядра для него нет. 136302 20 pv 2012-12-23 17:53:24 +0400 (В ответ на комментарий №17) > kernel-image-std-pae-1:3.6.11-alt1 -> sisyphus: > > * Thu Dec 20 2012 Gleb F-Malinovskiy <glebfm@altlinux> 1:3.6.11-alt1 > - 3.6.11 (closes: 28138) > - Build using std-def config with config diff from 3.5.7. Обновился. Проверил. Работает (wifi,засыпание/просыпание). 136326 21 slava 2012-12-24 12:52:20 +0400 Сегодня обновилось по простому dist-upgrade (!), но только kernel-image без модулей drm, radeon и прочих. В результате после перезагрузки не стартовали иксы. Если apt лезет обновлять ядро, то он обязан проверить, чтобы видеодрайвера и другие пакеты с модулями также обновлялись бы для этого image. Оформить как баг? 136327 22 pv 2012-12-24 13:01:54 +0400 (В ответ на комментарий №21) > Сегодня обновилось по простому dist-upgrade (!), но только kernel-image без > модулей drm, radeon и прочих. В результате после перезагрузки не стартовали > иксы. Вообще вроде как dist-upgrade не должен приводить к обновлению ядра. > > Если apt лезет обновлять ядро, то он обязан проверить, чтобы видеодрайвера и > другие пакеты с модулями также обновлялись бы для этого image. Оформить как > баг? Нет. Т.к. для обновления ядра и необходимых модулей существует update-kernel -t kernel-type 136331 23 slava 2012-12-24 14:06:15 +0400 Тем не менее, сегодня apt установил пакет kernel-image-3.6.11-std-pae несмотря на Hold { ... "^kernel.*"; // New-style kernels. "^kernel-(image|modules).*"; // Old-style kernels. "^(kernel|alsa)[0-9]+-source"; }; в apt.conf. 136332 24 slava 2012-12-24 14:09:21 +0400 Поправка: Hold { ... "^kernel.*"; // Old-style kernels. "^(kernel|alsa)[0-9]+-source"; }; .* не распозналось как регулярное выражение? 136335 25 mike 2012-12-24 14:32:23 +0400 (In reply to comment #23) > Тем не менее, сегодня apt установил пакет kernel-image-3.6.11-std-pae У меня тоже ровно сегодня с apt странности: http://lists.altlinux.org/pipermail/sisyphus/2012-December/359264.html http://lists.altlinux.org/pipermail/sisyphus/2012-December/359267.html Слав, повесь отдельное что-нибудь на rpm -- из всего сколь-нибудь причастного со вчера на сегодня обновлялся вроде как только он. К этой баге подобное уже без отношения.