Нужно ли нам  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 -- из всего сколь-нибудь причастного со вчера на сегодня обновлялся вроде как только он.

К этой баге подобное уже без отношения.