Обеспечить синхронную сбоорку std-def и std-pae.
Нужно ли нам std-pae, не являющееся основным ни для одного дистрибутива, в Сизифе и в p7? Если да, то нужно ли его обновление, синхронное с std-def, в Сизифе? В p7? Прошу мотивировать мнения.
Если судьба этого пакета кого-то интересует, можно подумать о роботизации сборки std-pae, но тогда оно выйдет на новый, уровень нетестируемости.
(In reply to comment #1) > Нужно ли нам std-pae, не являющееся основным ни для одного дистрибутива, > в Сизифе и в p7? Оно является вспомогательным и, помнится, устанавливалось автоматически вместо std-def при соответствующем объёме памяти на некоторых дистрибутивах пятой/шестой ветки. > Если да, то нужно ли его обновление, синхронное с std-def, в Сизифе? В p7? Насчёт именно синхронности не уверен, но некоторый уровень поддержки обеспечить пока стоит. В частности, пользуюсь им на одном десктопе и пользовался на сизифном ноутбуке, пока не перевёл его под led-ws с потерей доступности гигабайта памяти из четырёх (переехать на x86_64 тут не представляется разумным по соображениям взаимозаменяемости X60/X61).
Все же не блокер для p7.
Не знаю, сколько таких как я, но мне std-pae актуален. У меня на ноуте 8Gb при этом система i586 (по работе нужно). Если можно "роботизировать", сделайте пожалуйста. Я готов как тестировать, в плане как минимум сообщать, если очередная сборка не заработает.
(В ответ на комментарий №5) > Не знаю, сколько таких как я, но мне std-pae актуален. > > У меня на ноуте 8Gb при этом система i586 (по работе нужно). > > Если можно "роботизировать", сделайте пожалуйста. > Я готов как тестировать, в плане как минимум сообщать, > если очередная сборка не заработает. 2boyarsh: подумайте о роботизации, ok? В Новом году, сейчас действительно не до того.
в debian wheezy, как и в последних ubuntu, x86 ядро только одно. И как раз только pae. не pae ядер для х86 там не осталось
(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, хорошо бы уточнить у железячников.
(В ответ на комментарий №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 похоже дела совсем плохо.. > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. А в данном случае всё-таки требуется знания...
(In reply to comment #9) > C el-smp похоже дела совсем плохо.. Почему, просто это el6. Если что, у меня ovz-el на текущем сизифе вовсю используется на сборочнице. > > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. > А в данном случае всё-таки требуется знания... Угу. Некоторый объём уже есть, некоторый приобретаем и трудами glebfm@ уже улучшился (недавно была реализована автоматизированная пересборка модулей ядра).
Ещё можно попробовать обсудить с boyarsh@ включение PAE в un-def/i586. Тогда ядро по умолчанию [должно] будет устанавливаться на всё, что горит, и выбор тоже будет.
(В ответ на комментарий №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, коих в этом сегменте подавляющее большинство.
(В ответ на комментарий №11) > Ещё можно попробовать обсудить с boyarsh@ включение PAE в un-def/i586. > Тогда ядро по умолчанию [должно] будет устанавливаться на всё, что горит, > и выбор тоже будет. un-def сугубо экспериментальное ядро, потому этот вариант аналогичен 1.
(В ответ на комментарий №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, коих в > этом сегменте подавляющее большинство. В этом смысле меня первый вариант вполне устраивает.. Я готов, сообщать о "поломках".
> 2. включение pae в std-def. > > В варианте 2 меня беспокоит не столько отказ от совсем старого железа (насчет > Atom надо выяснить, но верится с трудом), сколько возможные потери в > производительности и памяти на системах с небольшим количеством RAM, коих в > этом сегменте подавляющее большинство. вот тут новость недавно была что поддержку i386 убрали из ядра. это прогресс. я вообще сильно сомневаюсь, что на старом железе нужно именно 3.х ядро. Есть мысль, что 2.6 на таком железе будет работать лучше всегда про потери в производительности и памяти мне нечего сказать. хотя я насчёт большинства не уверен.
(В ответ на комментарий №8) > (In reply to comment #5) > > Не знаю, сколько таких как я, но мне std-pae актуален. > +1 (comment #3); вариантов для страждущих вижу два: > - использовать el-smp или подобное, где PAE в i586 есть по постановке задачи; > - перехватывать сборку на себя и по мере лени [помогать] роботизировать её. Что мешает собирать std-def и std-pae из одного src.rpm, кроме того, что нужно один раз доработать спек для этого?
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.
(В ответ на комментарий №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.
(В ответ на комментарий №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 - фикция, потому как ядра для него нет.
(В ответ на комментарий №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,засыпание/просыпание).
Сегодня обновилось по простому dist-upgrade (!), но только kernel-image без модулей drm, radeon и прочих. В результате после перезагрузки не стартовали иксы. Если apt лезет обновлять ядро, то он обязан проверить, чтобы видеодрайвера и другие пакеты с модулями также обновлялись бы для этого image. Оформить как баг?
(В ответ на комментарий №21) > Сегодня обновилось по простому dist-upgrade (!), но только kernel-image без > модулей drm, radeon и прочих. В результате после перезагрузки не стартовали > иксы. Вообще вроде как dist-upgrade не должен приводить к обновлению ядра. > > Если apt лезет обновлять ядро, то он обязан проверить, чтобы видеодрайвера и > другие пакеты с модулями также обновлялись бы для этого image. Оформить как > баг? Нет. Т.к. для обновления ядра и необходимых модулей существует update-kernel -t kernel-type
Тем не менее, сегодня 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.
Поправка: Hold { ... "^kernel.*"; // Old-style kernels. "^(kernel|alsa)[0-9]+-source"; }; .* не распозналось как регулярное выражение?
(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 -- из всего сколь-нибудь причастного со вчера на сегодня обновлялся вроде как только он. К этой баге подобное уже без отношения.
