[d-kernel] lm_sensors

[d-kernel] lm_sensors

[Ed V. Bartosh]

Hello,

А кто что скажет про включение kernel-source-sensors в спек
lm_sensors ?

Сейчас имеет место быть полное несоответствие версий:
в mainstream - 2.8.0
в lm_sensors - 2.6.5
в kernel-source-sensors - 2.7.0
Ерунда какая-то, IMHO.

Да и вообще зачем 2 пакета из одного тарбола по разным спекам
генерить ?

И еще - а почему собственно kernel-{source,modules}-sensors, а не 
kernel-{source,modules}-lm_sensors ? 

И еще - а не заапдейтиться ли до 2.8.0 ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] lm_sensors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Mon, Jul 21, 2003 at 06:39:55PM +0400, Ed V. Bartosh wrote:
> А кто что скажет про включение kernel-source-sensors в спек
> lm_sensors ?

Huh?

> Сейчас имеет место быть полное несоответствие версий:
> в mainstream - 2.8.0
> в lm_sensors - 2.6.5
> в kernel-source-sensors - 2.7.0
> Ерунда какая-то, IMHO.

Действительно.

> Да и вообще зачем 2 пакета из одного тарбола по разным спекам
> генерить ?

Чтобы отделить userspace от kernel?

> И еще - а почему собственно kernel-{source,modules}-sensors, а не 
> kernel-{source,modules}-lm_sensors ? 
> 
> И еще - а не заапдейтиться ли до 2.8.0 ?

Я не против.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] lm_sensors

[Ed V. Bartosh]

Hello,

>>>>> "DVL" == Dmitry V. Levin writes:

 >>  А кто что скажет про включение kernel-source-sensors в спек
 >>  lm_sensors ?
  
 DVL>  Huh?
???  

 >>  Да и вообще зачем 2 пакета из одного тарбола по разным спекам
 >>  генерить ?
  
 DVL>  Чтобы отделить userspace от kernel?
Да, только это отделение ведет к разброду в версиях и прочим
неприятностям типа включения одного и того же тарбола в разные src.rpm
Да и в mainstream-е это лежит в одном месте, зачем нам велосипед с
треугольными колесами ?
  
 >>  И еще - а почему собственно kernel-{source,modules}-sensors, а не
 >>  kernel-{source,modules}-lm_sensors ?
 >>  
 >>  И еще - а не заапдейтиться ли до 2.8.0 ?
  
 DVL>  Я не против.
Не против заапдейтиться или включить ?
Предлагаю сделать и первое и второе. Если мейнтейнеру некогда, то я
могу сделать, мне сейчас по работе все равно нужно это.
Только вот с названием kernel- пакета непонятно, для чего-то же его меняли.

PS: С FreeS/WAN-ом такая же песня - юзерспейс 1.99, в ядре
(kernel-feat-ipsec) - 2.0. Это вполне может влечь за собой
неработоспособность этой связки. Предлагаю все пакеты такого типа
поправить.
В качестве примера можно взять evms, спакетированый Женей (tren@).

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: [d-kernel] lm_sensors

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 >>   >>  А кто что скажет про включение kernel-source-sensors в спек
 >>   >>  lm_sensors ?
 >>
 >>   DVL>  Huh?
 >>  ???
  
 DVL>  Не понял.
Я раньше не понял :)
  
 >>   >>  Да и вообще зачем 2 пакета из одного тарбола по разным
 >>   >>  спекам генерить ?
 >>
 >>   DVL>  Чтобы отделить userspace от kernel?
 >>  Да, только это отделение ведет к разброду в версиях и прочим
 >>  неприятностям типа включения одного и того же тарбола в разные
 >>  src.rpm Да и в mainstream-е это лежит в одном месте, зачем нам
 >>  велосипед с треугольными колесами ?
  
 DVL>  Модуль приходится пересобирать под новые ядра, в то время как
 DVL>  userspace - нет.
Я про модуль не писал. Из этого пакета будут генериться
kernel-source-lm_sensors, модуль - это отдельная песня, нет смысла его
в этот же спек тащить.
  
...
  
 >>  PS: С FreeS/WAN-ом такая же песня - юзерспейс 1.99, в ядре
 >>  (kernel-feat-ipsec) - 2.0. Это вполне может влечь за собой
 >>  неработоспособность этой связки. Предлагаю все пакеты такого типа
 >>  поправить.
  
 DVL>  Это разумно (для lm_sensors это не страшно, а вот freeswan
 DVL>  должен быть одной версии).
  
 >>  В качестве примера можно взять evms, спакетированый Женей
 >>  (tren@).
  
 DVL>  Я не уверен, что мы хотим собирать kernel и userspace
 DVL>  одновременно.
Почему ?
В случае evms и FreeS/WANA-а это как раз таки нужно. Думаю, что и
остальным не завредит.

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: [d-kernel] lm_sensors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1670 bytes --]

Greetings!

On Tue, Jul 22, 2003 at 09:33:00AM +0400, Ed V. Bartosh wrote:
> >>>>> "DVL" == Dmitry V. Levin writes:
> 
>  >>  А кто что скажет про включение kernel-source-sensors в спек
>  >>  lm_sensors ?
>   
>  DVL>  Huh?
> ???  

Не понял.

>  >>  Да и вообще зачем 2 пакета из одного тарбола по разным спекам
>  >>  генерить ?
>   
>  DVL>  Чтобы отделить userspace от kernel?
> Да, только это отделение ведет к разброду в версиях и прочим
> неприятностям типа включения одного и того же тарбола в разные src.rpm
> Да и в mainstream-е это лежит в одном месте, зачем нам велосипед с
> треугольными колесами ?

Модуль приходится пересобирать под новые ядра, в то время как userspace -
нет.

Согласен, что tarball можно использовать один.

>  >>  И еще - а почему собственно kernel-{source,modules}-sensors, а не
>  >>  kernel-{source,modules}-lm_sensors ?
>  >>  
>  >>  И еще - а не заапдейтиться ли до 2.8.0 ?
>   
>  DVL>  Я не против.
> Не против заапдейтиться или включить ?

Я не против 2.8.0

> Предлагаю сделать и первое и второе. Если мейнтейнеру некогда, то я
> могу сделать, мне сейчас по работе все равно нужно это.

Я не против.

> Только вот с названием kernel- пакета непонятно, для чего-то же его меняли.

nidd?

> PS: С FreeS/WAN-ом такая же песня - юзерспейс 1.99, в ядре
> (kernel-feat-ipsec) - 2.0. Это вполне может влечь за собой
> неработоспособность этой связки. Предлагаю все пакеты такого типа
> поправить.

Это разумно (для lm_sensors это не страшно, а вот freeswan должен быть
одной версии).

> В качестве примера можно взять evms, спакетированый Женей (tren@).

Я не уверен, что мы хотим собирать kernel и userspace одновременно.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] Re: [d-kernel] lm_sensors

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 >>   DVL>  Я не уверен, что мы хотим собирать kernel и userspace
 >>   DVL>  одновременно.
 >>  Почему ?  В случае evms и FreeS/WANA-а это как раз таки
 >>  нужно. Думаю, что и остальным не завредит.
  
 DVL>  Поясню свою позицию: на kernel-source-XXX вместе с XXX-* я
 DVL>  согласен.

Ну вот и чудесно. Я именно это и имел в виду.

В evms почти так и сделано, кстати. 
Там генерится kernel-feat-evms. Но принцип от этого не меняется,
по-моему. То есть никаких сборок ядер совместно с юзерспейсом данная
схема не предполагает.

PS: А что еще есть из пакетов такого типа ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 SV>  Там с i2c-2.8.0 нужно ещё кучу всего вокруг патчить (в том числе
 SV>  kernel-feat-bttv). Эти патчи уже есть, только ещё одна бага
 SV>  осталась - почему-то перестала работать проверка на дублирование
 SV>  адресов. Сейчас буду смотреть.

Так ты сделаешь ? А то у меня с этим какие-то трудности наступили - не
собирается ничего толком без ядерных сорцов. Хотя
kernel-modules-sensors я как-то раньше умудрился собрать без них, только с
хедерами. А этот юзерспейсный утиль как-то упирается. Даже странно.

-- 
Best regards,
Ed V. Bartosh

Re: [devel] Re: [d-kernel] lm_sensors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]

On Tue, Jul 22, 2003 at 04:12:48PM +0400, Ed V. Bartosh wrote:
>  >>   >>  Да и вообще зачем 2 пакета из одного тарбола по разным
>  >>   >>  спекам генерить ?
>  >>
>  >>   DVL>  Чтобы отделить userspace от kernel?
>  >>  Да, только это отделение ведет к разброду в версиях и прочим
>  >>  неприятностям типа включения одного и того же тарбола в разные
>  >>  src.rpm Да и в mainstream-е это лежит в одном месте, зачем нам
>  >>  велосипед с треугольными колесами ?
>   
>  DVL>  Модуль приходится пересобирать под новые ядра, в то время как
>  DVL>  userspace - нет.
> Я про модуль не писал. Из этого пакета будут генериться
> kernel-source-lm_sensors, модуль - это отдельная песня, нет смысла его
> в этот же спек тащить.

В таком варианте согласен.

>  >>  PS: С FreeS/WAN-ом такая же песня - юзерспейс 1.99, в ядре
>  >>  (kernel-feat-ipsec) - 2.0. Это вполне может влечь за собой
>  >>  неработоспособность этой связки. Предлагаю все пакеты такого типа
>  >>  поправить.
>   
>  DVL>  Это разумно (для lm_sensors это не страшно, а вот freeswan
>  DVL>  должен быть одной версии).
>   
>  >>  В качестве примера можно взять evms, спакетированый Женей
>  >>  (tren@).
>   
>  DVL>  Я не уверен, что мы хотим собирать kernel и userspace
>  DVL>  одновременно.
> Почему ?
> В случае evms и FreeS/WANA-а это как раз таки нужно. Думаю, что и
> остальным не завредит.

Поясню свою позицию:
на kernel-source-XXX вместе с XXX-* я согласен.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] lm_sensors

[Sergey Vlasov]

On Tue, 22 Jul 2003 16:22:32 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> > PS: С FreeS/WAN-ом такая же песня - юзерспейс 1.99, в ядре
> > (kernel-feat-ipsec) - 2.0. Это вполне может влечь за собой
> > неработоспособность этой связки. Предлагаю все пакеты такого типа
> > поправить.
> 
> Это разумно (для lm_sensors это не страшно, а вот freeswan должен быть
> одной версии).

Для lm_sensors - тоже. Точнее, для собственно sensors это значения не
имеет (там используется sysctl), а вот для i2c* может - они там
ухитрились поменять размер некоторых структур, при этом не изменив
коды ioctl. Хотя для 2.7.0 -> 2.8.0 то, что собирается (i2cdetect,
i2cdump, i2cset), это изменение не затрагивает - тут поменяли struct
i2c_msg, она там не используется.

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Tue, 22 Jul 2003 09:33:00 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

>  >>  И еще - а почему собственно kernel-{source,modules}-sensors, а не
>  >>  kernel-{source,modules}-lm_sensors ?
>  >>  
>  >>  И еще - а не заапдейтиться ли до 2.8.0 ?
>   
>  DVL>  Я не против.
> Не против заапдейтиться или включить ?
> Предлагаю сделать и первое и второе. Если мейнтейнеру некогда, то я
> могу сделать, мне сейчас по работе все равно нужно это.

Там с i2c-2.8.0 нужно ещё кучу всего вокруг патчить (в том числе
kernel-feat-bttv). Эти патчи уже есть, только ещё одна бага осталась -
почему-то перестала работать проверка на дублирование адресов. Сейчас
буду смотреть.

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 SV>  Как будем класть - на место старого kernel-feat-i2c, или на
 SV>  всякий случай рядом - kernel-feat-i2c-2.8.0? Багу я вроде
 SV>  нашёл...
На место, конечно. И kernel-source-... назвать нужно как надо, если в этом
нет тайного смысла. И модули, соответственно.
  
 SV>  Там просто порядок применения поменяется - я всё-таки перенёс
 SV>  mkpatch на этап сборки kernel-feat-i2c-2.8.0, и применять надо
 SV>  обязательно после kernel-feat-bttv (его надо патчить).
  
 SV>  А userspace у меня собрался - он действительно сильно хочет
 SV>  собрать модули ядра, пришлось ему несколько Module.mk почистить.
Так заливай/выкладывай его куда-нибудь скорее, пожалуйста.
Я бы сразу бы и потестил.
kernel-source-lm_sensors генеришь там же ?

Попутно вопрос - мне нужно сделать на основе существующего
sensors-detect его неинтерактивный вариант. Это реально ? Какие грабли
могут ожидаться ? Он нужен в Сизифе ?

-- 
Best regards,
Ed V. Bartosh

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Tue, 22 Jul 2003 17:14:30 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> 
> >>>>> "SV" == Sergey Vlasov writes:
> 
>  SV>  Там с i2c-2.8.0 нужно ещё кучу всего вокруг патчить (в том числе
>  SV>  kernel-feat-bttv). Эти патчи уже есть, только ещё одна бага
>  SV>  осталась - почему-то перестала работать проверка на дублирование
>  SV>  адресов. Сейчас буду смотреть.
> 
> Так ты сделаешь ? А то у меня с этим какие-то трудности наступили - не
> собирается ничего толком без ядерных сорцов. Хотя
> kernel-modules-sensors я как-то раньше умудрился собрать без них, только с
> хедерами. А этот юзерспейсный утиль как-то упирается. Даже странно.

Как будем класть - на место старого kernel-feat-i2c, или на всякий
случай рядом - kernel-feat-i2c-2.8.0? Багу я вроде нашёл...

Там просто порядок применения поменяется - я всё-таки перенёс mkpatch
на этап сборки kernel-feat-i2c-2.8.0, и применять надо обязательно
после kernel-feat-bttv (его надо патчить).

А userspace у меня собрался - он действительно сильно хочет собрать
модули ядра, пришлось ему несколько Module.mk почистить.

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On Tue, 22 Jul 2003 19:44:49 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> 
> >>>>> "SV" == Sergey Vlasov writes:
> 
>  SV>  Как будем класть - на место старого kernel-feat-i2c, или на
>  SV>  всякий случай рядом - kernel-feat-i2c-2.8.0? Багу я вроде
>  SV>  нашёл...
> На место, конечно. И kernel-source-... назвать нужно как надо, если в этом
> нет тайного смысла. И модули, соответственно.

Это i2c-часть - про неё уже столько писано...

lm_sensors, естественно, в kernel-source- (всё-таки sensors или
lm_sensors?) и собирать отдельно.

>  SV>  Там просто порядок применения поменяется - я всё-таки перенёс
>  SV>  mkpatch на этап сборки kernel-feat-i2c-2.8.0, и применять надо
>  SV>  обязательно после kernel-feat-bttv (его надо патчить).
>   
>  SV>  А userspace у меня собрался - он действительно сильно хочет
>  SV>  собрать модули ядра, пришлось ему несколько Module.mk почистить.
> Так заливай/выкладывай его куда-нибудь скорее, пожалуйста.
> Я бы сразу бы и потестил.
> kernel-source-lm_sensors генеришь там же ?

Это я ещё не объединил - просто модифицировал те спеки, что были
раньше.

Ладно, залил пока то, что есть:

2c569cc54deec87ee63cfc548f355bf4  kernel-feat-i2c-2.8.0-alt1.src.rpm
ae13c0bf6aed66896cd2067c0093ebc4  kernel-source-sensors-2.8.0-2.8.0-alt1.src.rpm
a574c3d4bc108f729475b044c23a7296  lm_sensors-2.8.0-alt1.src.rpm

Объединять буду завтра, если кто-нибудь раньше не успеет :-)

> Попутно вопрос - мне нужно сделать на основе существующего
> sensors-detect его неинтерактивный вариант. Это реально ? Какие грабли
> могут ожидаться ? Он нужен в Сизифе ?

У меня sensors-detect вроде бы всегда работал пристойно - даже
сообразил, что два устройства, конфликтующие по адресам субклиентов
(0x48, 0x49), вместе работать не могут. Никак не пойму, что асусовцы
на этой A7V8X налепили - там мало того, что 0x2d - ASB100, ещё на 0x2f
что-то есть (sensors-detect видит W83791D, причём регистром 0x4a
субклиенты перемещаются - значит, что-то подобное всё-таки по этому
адресу есть), и ещё после издевательств над i2c-viapro на тему PEC
smbus-arp обнаруживает какую-то непонятную хреновину...

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors

[Michael Shigorin]

On Tue, Jul 22, 2003 at 07:44:49PM +0400, Ed V. Bartosh wrote:
> Попутно вопрос - мне нужно сделать на основе существующего
> sensors-detect его неинтерактивный вариант. Это реально ? Какие
> грабли могут ожидаться ? Он нужен в Сизифе ?

По крайней мере мне бы пригодился.  Грабли -- как понимаю, с
"вероятностью" оценки применимости драйвера (=> необходимость
пороговой отсечки, если до нее получится добраться) и ненулевые
шансы на lockup.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 >>   SV>  Как будем класть - на место старого kernel-feat-i2c, или на
 >>   SV>  всякий случай рядом - kernel-feat-i2c-2.8.0? Багу я вроде
 >>   SV>  нашёл...
 >>  На место, конечно. И kernel-source-... назвать нужно как надо,
 >>  если в этом нет тайного смысла. И модули, соответственно.
  
 SV>  Это i2c-часть - про неё уже столько писано...
Сори, я стормозил, думал, что речь идет об lm_sensors. С i2c все
понятно, я считаю, что нужно в kernel-feat-i2c, без версии, это
рядовой апдейт с 2.7.0 на 2.8.0.
  
 SV>  lm_sensors, естественно, в kernel-source- (всё-таки sensors или
 SV>  lm_sensors?) и собирать отдельно.
Я думаю, что lm_sensors, поскольку никто пока не признался зачем его
переименовали. kernel-source-lm_sensors собирать совместно с
lm_sensors, как договаривались.

 SV>  Ладно, залил пока то, что есть:
  
 SV>  2c569cc54deec87ee63cfc548f355bf4
 SV>  kernel-feat-i2c-2.8.0-alt1.src.rpm
 SV>  ae13c0bf6aed66896cd2067c0093ebc4
 SV>  kernel-source-sensors-2.8.0-2.8.0-alt1.src.rpm
 SV>  a574c3d4bc108f729475b044c23a7296 lm_sensors-2.8.0-alt1.src.rpm
  
 SV>  Объединять буду завтра, если кто-нибудь раньше не успеет :-)
Угу, большое спасибо. Кричи сюда, когда будут новости. Я тоже буду
собирать, скорее всего, синхронизируемся.
  
 >>  Попутно вопрос - мне нужно сделать на основе существующего
 >>  sensors-detect его неинтерактивный вариант. Это реально ? Какие
 >>  грабли могут ожидаться ? Он нужен в Сизифе ?
  
 SV>  У меня sensors-detect вроде бы всегда работал пристойно - даже
 SV>  сообразил, что два устройства, конфликтующие по адресам
 SV>  субклиентов (0x48, 0x49), вместе работать не могут. Никак не
 SV>  пойму, что асусовцы на этой A7V8X налепили - там мало того, что
 SV>  0x2d - ASB100, ещё на 0x2f что-то есть (sensors-detect видит
 SV>  W83791D, причём регистром 0x4a субклиенты перемещаются - значит,
 SV>  что-то подобное всё-таки по этому адресу есть), и ещё после
 SV>  издевательств над i2c-viapro на тему PEC smbus-arp обнаруживает
 SV>  какую-то непонятную хреновину...
Ясно. Проблемы возможны, но в основном должно работать. 
У меня вопрос был в основном об неинтерактивности - возможно ли 
добиться приличной степени детектирования ну хотя бы на
распространенных чипсетах ? Возможно ли задетектить проблемные вещи и 
как-то обойти проблемы ?

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 SV>  kernel-feat-i2c-2.8.0-alt1.src.rpm
А как ты смотришь на то, чтобы перенести возню с kernel-sources на
этап приложения патча ? А здесь просто положить сорцы куда надо.
А то как-то тяжеловесно выглядит вся эта распаковка.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]


>>>>> "SV" == Sergey Vlasov writes:

 >>   SV>  kernel-feat-i2c-2.8.0-alt1.src.rpm
 >>  А как ты смотришь на то, чтобы перенести возню с kernel-sources
 >>  на этап приложения патча ? А здесь просто положить сорцы куда
 >>  надо.  А то как-то тяжеловесно выглядит вся эта распаковка.
  
 SV>  Так было раньше. В принципе можно и вернуть, тогда к тому
 SV>  скрипту apply, который там был, ещё надо будет добавить
 SV>  возможность наложения патчей.
Ну и ладно. Зато кернеловые сорцы не нужно будет распаковывать каждый
раз. Впрочем смотри сам.
  
 SV>  Недостаток такой схемы, как я уже писал, в том, что при этом
 SV>  ранее наложенные на i2c патчи молча откатываются без сообщения
 SV>  об этом. Т.е.  нужно следить за порядком - patch по этому поводу
 SV>  ничего не скажет.  Только теперь kernel-feat-i2c не может быть
 SV>  первым - он должен идти после kernel-feat-bttv, либо надо
 SV>  править сам bttv (причём разработчики i2c не предусмотрели
 SV>  какого-либо #define с версией, пригодного для проверки - есть
 SV>  только строка; видимо, придётся цепляться к какому-то
 SV>  идентификатору, появившемуся в это время в linux/i2c-ids.h).
Нужна некая схема зависимостей на патчи, чтобы в неправильном порядке
нельзя было приложить, а еще лучше чтобы они прикладывались автоматом
при надобности. И было бы неплохо встроить это дело в apply_patches.

Я тут перенес в спек kernel-source-lm_sensors, спек и патчи приаттачиваю,
глянь, плз. 

Кроме того с i2c проблемы - конфликтует с kernel-headers
по поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
Я их пока убрал из спека, но в kernel-headers-..., собранном уже с
новым feat-i2c эти файлы почему-то другого размера, что есть странно и
неправильно, нужно разбираться.

-- 
Best regards,
Ed V. Bartosh


[-- Attachment #2: lm_sensors --]
[-- Type: application/octet-stream, Size: 8134 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: lm_sensors-2.8.0-makefile-fixes.patch --]
[-- Type: text/x-patch, Size: 1323 bytes --]

--- lm_sensors-2.8.0/prog/hotplug/Makefile.makefile-fixes	2001-03-24 21:35:13 +0300
+++ lm_sensors-2.8.0/prog/hotplug/Makefile	2003-04-01 17:49:09 +0400
@@ -18,7 +18,7 @@
 	$(CC) $(CFLAGS) -c $< -o $@
 
 install: all
-	install -o root -g root -m 644 $(OBJS) /lib/modules/$(VER)/kernel/drivers/i2c/busses
+	install -m 644 $(OBJS) /lib/modules/$(VER)/kernel/drivers/i2c/busses
 
 clean:
 	rm -f $(OBJS)
--- lm_sensors-2.8.0/prog/rrd/Makefile.makefile-fixes	2002-01-05 18:39:17 +0300
+++ lm_sensors-2.8.0/prog/rrd/Makefile	2003-04-01 17:48:46 +0400
@@ -41,10 +41,10 @@
 	install -d -o $(USER) -m 777 $(APACHDIR)/pix
 
 install: all $(RRDB) $(SENSDIR) $(CRONTAB) $(APACHDIR)/pix
-	install -o root -g root -m 755 sens_update_rrd $(BINPATH)
-	install -o root -g root -m 755 sens_week.cgi $(APACHDIR)
-	install -o root -g root -m 755 sens_day.cgi $(APACHDIR)
-	install -o root -g root -m 755 summ_week.cgi $(APACHDIR)
+	install -m 755 sens_update_rrd $(BINPATH)
+	install -m 755 sens_week.cgi $(APACHDIR)
+	install -m 755 sens_day.cgi $(APACHDIR)
+	install -m 755 summ_week.cgi $(APACHDIR)
 #	grep sens_update_rrd $(CRONTAB) > /dev/null 2>&1 || echo '*/5 * * * *	/usr/local/bin/sens_update_rrd' $(RRDB) $(SENSDEV) >> $(CRONTAB)
 	@echo
 	@echo Note!!! You must manually install the following line in the crontab for user $(USER):

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #4: lm_sensors-2.8.0-makefile-grep-fixes.patch --]
[-- Type: text/x-patch, Size: 16119 bytes --]

--- kernel-source-sensors-2.8.0/Makefile~	2002-12-04 18:44:32 +0300
+++ kernel-source-sensors-2.8.0/Makefile	2003-06-25 13:56:29 +0400
@@ -54,8 +54,7 @@
 
 # Uncomment the third line on SMP systems if the magic invocation fails. It
 # is a bit complicated because SMP configuration changed around kernel 2.1.130
-SMP := $(shell if grep -q '^SMP[[:space:]]*=' $(LINUX)/Makefile || \
-                  grep -q '^[[:space:]]*\#define[[:space:]]*CONFIG_SMP[[:space:]]*1' $(LINUX_HEADERS)/linux/autoconf.h ; \
+SMP := $(shell if grep -q '^[[:space:]]*\#define[[:space:]]*CONFIG_SMP[[:space:]]*1' $(LINUX_HEADERS)/linux/autoconf.h ; \
                then echo 1; else echo 0; fi)
 #SMP := 0
 #SMP := 1
--- kernel-source-sensors-2.8.0/kernel/busses/Module.mk.orig	2003-06-25 14:05:06 +0400
+++ kernel-source-sensors-2.8.0/kernel/busses/Module.mk	2003-06-25 14:23:33 +0400
@@ -26,68 +26,68 @@
 # These targets are NOT included in 'mkpatch' ...
 KERNELBUSSESTARGETS :=
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-nforce2.o
-ifeq ($(shell if grep -q '^CONFIG_IPMI_HANDLER=' $(LINUX)/.config; then echo 1; fi),1)
+ifeq ($(shell if grep -q '^\#define.*CONFIG_IPMI_HANDLER.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-ipmb.o
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-ipmi.o
 endif
 
 # These targets ARE included in 'mkpatch' ...
-ifneq ($(shell if grep -q '^CONFIG_I2C_ALI1535=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_ALI1535.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-ali1535.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_ALI15X3=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_ALI15X3.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-ali15x3.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_AMD756=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_AMD756.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-amd756.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_AMD8111=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_AMD8111.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-amd8111.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_HYDRA=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_HYDRA.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-hydra.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_I801=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_I801.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-i801.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_I810=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_I810.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-i810.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_ISA=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_ISA.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-isa.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_SIS5595=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_SIS5595.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-sis5595.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_SIS630=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_SIS630.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-sis630.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_SIS645=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_SIS645.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-sis645.o
 endif
 # don't compile dmi_scan unless x86 because it needs isa access
-ifneq ($(shell if grep -q '^CONFIG_I2C_PIIX4=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_PIIX4.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-piix4.o
-ifeq ($(shell if grep -q '^CONFIG_X86=y' $(LINUX)/.config; then echo 1; fi),1)
+ifeq ($(shell if grep -q '^\#define.*CONFIG_X86.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/dmi_scan.o
 endif
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_SAVAGE4=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_SAVAGE4.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-savage4.o
 endif
 # don't compile unless alpha because of kernel include-file dependencies
 ifeq ($(MACHINE),alpha)
-ifneq ($(shell if grep -q '^CONFIG_I2C_TSUNAMI=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_TSUNAMI.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-tsunami.o
 endif
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_VIA=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_VIA.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-via.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_VIAPRO=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_VIAPRO.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-viapro.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_I2C_VOODOO3=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_I2C_VOODOO3.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELBUSSESTARGETS += $(MODULE_DIR)/i2c-voodoo3.o
 endif
 
--- kernel-source-sensors-2.8.0/kernel/chips/Module.mk.orig	2003-06-25 14:12:25 +0400
+++ kernel-source-sensors-2.8.0/kernel/chips/Module.mk	2003-06-25 14:12:37 +0400
@@ -25,7 +25,7 @@
 # defined value verbatim into the command-list of rules...
 # These targets are NOT included in 'mkpatch' ...
 KERNELCHIPSTARGETS :=
-ifeq ($(shell if grep -q '^CONFIG_IPMI_HANDLER=' $(LINUX)/.config; then echo 1; fi),1)
+ifeq ($(shell if grep -q '^\#define.*CONFIG_IPMI_HANDLER.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/bmcsensors.o
 endif
 KERNELCHIPSTARGETS += $(MODULE_DIR)/ds1307.o
@@ -38,100 +38,100 @@
 
 # These targets ARE included in 'mkpatch', except for LTC1710, which we
 # leave here because it used to be in 'mkpatch' ...
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_ADM1021=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_ADM1021.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/adm1021.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_ADM1024=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_ADM1024.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/adm1024.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_ADM1025=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_ADM1025.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/adm1025.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_ADM1026=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_ADM1026.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/adm1026.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_ADM9240=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_ADM9240.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/adm9240.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_BT869=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_BT869.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/bt869.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_DDCMON=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_DDCMON.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/ddcmon.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_DS1621=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_DS1621.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/ds1621.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_EEPROM=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_EEPROM.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/eeprom.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_FSCPOS=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_FSCPOS.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/fscpos.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_FSCSCY=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_FSCSCY.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/fscscy.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_GL518SM=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_GL518SM.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/gl518sm.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_GL520SM=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_GL520SM.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/gl520sm.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_IT87=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_IT87.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/it87.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM75=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM75.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm75.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM78=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM78.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm78.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM80=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM80.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm80.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM85=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM85.*' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm85.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM87=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM87.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm87.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LM92=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LM92.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/lm92.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_LTC1710=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_LTC1710.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/ltc1710.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_MATORB=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_MATORB.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/matorb.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_MAXILIFE=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_MAXILIFE.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/maxilife.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_MTP008=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_MTP008.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/mtp008.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_PCF8574=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_PCF8574.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/pcf8574.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_PCF8591=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_PCF8591.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/pcf8591.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_SIS5595=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_SIS5595.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/sis5595.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_SMSC47M1=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_SMSC47M1.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/smsc47m1.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_THMC50=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_THMC50.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/thmc50.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_W83781D=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_W83781D.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/w83781d.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_VIA686A=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_VIA686A.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/via686a.o
 endif
-ifneq ($(shell if grep -q '^CONFIG_SENSORS_VT1211=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS_VT1211.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 KERNELCHIPSTARGETS += $(MODULE_DIR)/vt1211.o
 endif
 
--- kernel-source-sensors-2.8.0/kernel/Module.mk.orig	2003-06-25 14:15:55 +0400
+++ kernel-source-sensors-2.8.0/kernel/Module.mk	2003-06-25 14:16:45 +0400
@@ -24,7 +24,7 @@
 # Regrettably, even 'simply expanded variables' will not put their currently
 # defined value verbatim into the command-list of rules...
 KERNELTARGETS := 
-ifneq ($(shell if grep -q '^CONFIG_SENSORS=y' $(LINUX)/.config; then echo 1; fi),1)
+ifneq ($(shell if grep -q '^\#define.*CONFIG_SENSORS.*1' $(LINUX_HEADERS)/linux/autoconf.h; then echo 1; fi),1)
 # sensors.c moved to i2c-proc.c in i2c package
 #KERNELTARGETS += $(MODULE_DIR)/sensors.o
 endif

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Wed, 23 Jul 2003 12:24:05 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> >>>>> "SV" == Sergey Vlasov writes:
> 
>  SV>  kernel-feat-i2c-2.8.0-alt1.src.rpm
> А как ты смотришь на то, чтобы перенести возню с kernel-sources на
> этап приложения патча ? А здесь просто положить сорцы куда надо.
> А то как-то тяжеловесно выглядит вся эта распаковка.

Так было раньше. В принципе можно и вернуть, тогда к тому скрипту
apply, который там был, ещё надо будет добавить возможность наложения
патчей.

Недостаток такой схемы, как я уже писал, в том, что при этом ранее
наложенные на i2c патчи молча откатываются без сообщения об этом. Т.е.
нужно следить за порядком - patch по этому поводу ничего не скажет.
Только теперь kernel-feat-i2c не может быть первым - он должен идти
после kernel-feat-bttv, либо надо править сам bttv (причём
разработчики i2c не предусмотрели какого-либо #define с версией,
пригодного для проверки - есть только строка; видимо, придётся
цепляться к какому-то идентификатору, появившемуся в это время в
linux/i2c-ids.h).

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

 >>  Нужна некая схема зависимостей на патчи, чтобы в неправильном
 >>  порядке нельзя было приложить, а еще лучше чтобы они
 >>  прикладывались автоматом при надобности. И было бы неплохо
 >>  встроить это дело в apply_patches.
  
 VO>  Можно я опять влезу с XML ? :)
:) Любимое детище ?
  
 VO>  Можно (и несложно на практике) оформить зависимости патчей в
 VO>  XML, а потом генерировать из него скрипт в любой нужной форме.
Это по-моему из пушки по воробьям. проблема не в указании зависимостей
как таковых, а в реализации, в тех самых скриптах.
А скрипт(макрос) лучше написать один раз и использовать, а не генерить
каждый раз. Нерационально, словом. Но это только мое мнение.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:

 >>   >>   SV>  тяжеловесно выглядит вся эта распаковка.
 >>
 >>   SV>  Так было раньше. В принципе можно и вернуть, тогда к тому
 >>   SV>  скрипту apply, который там был, ещё надо будет добавить
 >>   SV>  возможность наложения патчей.
 >>  Ну и ладно. Зато кернеловые сорцы не нужно будет распаковывать
 >>  каждый раз. Впрочем смотри сам.
  
 SV>  Ладно, верну назад.
Угу, спасибо.
  
 >>  Нужна некая схема зависимостей на патчи, чтобы в неправильном
 >>  порядке нельзя было приложить, а еще лучше чтобы они
 >>  прикладывались автоматом при надобности. И было бы неплохо
 >>  встроить это дело в apply_patches.
  
 SV>  Это точно.
Кто у нас тут брался TODO вести. Я уже как минимум вот это начинаю
забывать :)
- пересборака FreeS/WAN-а - kernel-feat и юзерспейс из одной спеки
- Обновить kernel-fix-security патчами из последнего RH
- схема зависимостей между патчами
- включение .h из drivers/scsi в kernel-headers
- сборка scsi модулей (qla как минимум)

Если подумать, то и еще вспомню.
  
 >>  Я тут перенес в спек kernel-source-lm_sensors, спек и патчи
 >>  приаттачиваю, глянь, плз.
  
 SV>  +%__cp -R ./ ../kernel-source-%name-%version
 SV>  +
  
 SV>  Перед этим, вероятно, надо добавить
  
 SV>    %__rm -rf ../kernel-source-%name-%version
добавлено

 SV>  +%__mkdir_p
 SV>  +%buildroot%_defaultdocdir/kernel-doc-%module_name-%version
  
 SV>  А сюда, видимо, предполагалось положить содержимое каталога doc?
 SV>  Хотя это уже лежит в пакете lm_sensors...
убрано
  
 >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
 >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
  
 SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
 SV>  не должно - у меня его там нет.
Да, правильно, у меня тоже нет.

 >>  Я их пока убрал из спека, но в kernel-headers-..., собранном уже
 >>  с новым feat-i2c эти файлы почему-то другого размера, что есть
 >>  странно и неправильно, нужно разбираться.
  
 SV>  А это, похоже, дурь в lm_sensors. Файлы действительно разные -
 SV>  из того i2c-dev.h, что в i2c, выкинута вся userspace-часть. Но
 SV>  lm_sensors при сборке его не использует - он берёт свой
 SV>  i2c-dev.h, в котором есть ещё куча инлайнов. А sensors.h вообще
 SV>  генерируется из драйверов (kernel/chips/*.c). Устанавливаться
 SV>  эти файлы, похоже, вообще не должны - mkpatch в lm_sensors их не
 SV>  трогает.
Понятно. Значит я правильно сделал.

-- 
Best regards,
Ed V. Bartosh

[d-kernel] Re: lm_sensors

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

On Wed, 23 Jul 2003 15:35:55 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

<skipped/>

>  SV>  Недостаток такой схемы, как я уже писал, в том, что при
>  SV>  этом ранее наложенные на i2c патчи молча откатываются без
>  SV>  сообщения об этом. Т.е.  нужно следить за порядком -
>  SV>  patch по этому поводу ничего не скажет.  Только теперь
>  SV>  kernel-feat-i2c не может быть первым - он должен идти
>  SV>  после kernel-feat-bttv, либо надо править сам bttv
>  SV>  (причём разработчики i2c не предусмотрели какого-либо
>  SV>  #define с версией, пригодного для проверки - есть
>  SV>  только строка; видимо, придётся цепляться к какому-то
>  SV>  идентификатору, появившемуся в это время в
>  SV>  linux/i2c-ids.h).

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

Можно я опять влезу с XML ? :)

Можно (и несложно на практике) оформить зависимости патчей в XML,
а потом генерировать из него скрипт в любой нужной форме.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Wed, 23 Jul 2003 15:35:55 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> >>>>> "SV" == Sergey Vlasov writes:
> 
>  >>   SV>  kernel-feat-i2c-2.8.0-alt1.src.rpm
>  >>  А как ты смотришь на то, чтобы перенести возню с kernel-sources
>  >>  на этап приложения патча ? А здесь просто положить сорцы куда
>  >>  надо.  А то как-то тяжеловесно выглядит вся эта распаковка.
>   
>  SV>  Так было раньше. В принципе можно и вернуть, тогда к тому
>  SV>  скрипту apply, который там был, ещё надо будет добавить
>  SV>  возможность наложения патчей.
> Ну и ладно. Зато кернеловые сорцы не нужно будет распаковывать каждый
> раз. Впрочем смотри сам.

Ладно, верну назад.

>  SV>  Недостаток такой схемы, как я уже писал, в том, что при этом
>  SV>  ранее наложенные на i2c патчи молча откатываются без сообщения
>  SV>  об этом. Т.е.  нужно следить за порядком - patch по этому поводу
>  SV>  ничего не скажет.  Только теперь kernel-feat-i2c не может быть
>  SV>  первым - он должен идти после kernel-feat-bttv, либо надо
>  SV>  править сам bttv (причём разработчики i2c не предусмотрели
>  SV>  какого-либо #define с версией, пригодного для проверки - есть
>  SV>  только строка; видимо, придётся цепляться к какому-то
>  SV>  идентификатору, появившемуся в это время в linux/i2c-ids.h).
> Нужна некая схема зависимостей на патчи, чтобы в неправильном порядке
> нельзя было приложить, а еще лучше чтобы они прикладывались автоматом
> при надобности. И было бы неплохо встроить это дело в apply_patches.

Это точно.

> Я тут перенес в спек kernel-source-lm_sensors, спек и патчи приаттачиваю,
> глянь, плз. 

+%__cp -R  ./ ../kernel-source-%name-%version
+

Перед этим, вероятно, надо добавить

  %__rm -rf ../kernel-source-%name-%version

+%__mkdir_p %buildroot%_defaultdocdir/kernel-doc-%module_name-%version

А сюда, видимо, предполагалось положить содержимое каталога doc? Хотя
это уже лежит в пакете lm_sensors...

> Кроме того с i2c проблемы - конфликтует с kernel-headers
> по поводу /usr/include/linux/{i2c-dev.h,sensors.h}.

Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть не
должно - у меня его там нет.

> Я их пока убрал из спека, но в kernel-headers-..., собранном уже с
> новым feat-i2c эти файлы почему-то другого размера, что есть странно и
> неправильно, нужно разбираться.

А это, похоже, дурь в lm_sensors. Файлы действительно разные - из того
i2c-dev.h, что в i2c, выкинута вся userspace-часть. Но lm_sensors при
сборке его не использует - он берёт свой i2c-dev.h, в котором есть ещё
куча инлайнов. А sensors.h вообще генерируется из драйверов
(kernel/chips/*.c). Устанавливаться эти файлы, похоже, вообще не
должны - mkpatch в lm_sensors их не трогает.

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Wed, 23 Jul 2003 16:45:33 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> >>>>> "SV" == Sergey Vlasov writes:
> 
>  >>   >>   SV>  тяжеловесно выглядит вся эта распаковка.
>  >>
>  >>   SV>  Так было раньше. В принципе можно и вернуть, тогда к тому
>  >>   SV>  скрипту apply, который там был, ещё надо будет добавить
>  >>   SV>  возможность наложения патчей.
>  >>  Ну и ладно. Зато кернеловые сорцы не нужно будет распаковывать
>  >>  каждый раз. Впрочем смотри сам.
>   
>  SV>  Ладно, верну назад.
> Угу, спасибо.

Залил:

d0d7ca9e2e9a27bf3da80a137bc83182  kernel-feat-i2c-2.8.0-alt2.src.rpm

>  >>  Я тут перенес в спек kernel-source-lm_sensors, спек и патчи
>  >>  приаттачиваю, глянь, плз.
>   
>  SV>  +%__cp -R ./ ../kernel-source-%name-%version
>  SV>  +
>   
>  SV>  Перед этим, вероятно, надо добавить
>   
>  SV>    %__rm -rf ../kernel-source-%name-%version
> добавлено
> 
>  SV>  +%__mkdir_p
>  SV>  +%buildroot%_defaultdocdir/kernel-doc-%module_name-%version
>   
>  SV>  А сюда, видимо, предполагалось положить содержимое каталога doc?
>  SV>  Хотя это уже лежит в пакете lm_sensors...
> убрано

Ладно, жду заливки.

>  >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
>  >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
>   
>  SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
>  SV>  не должно - у меня его там нет.
> Да, правильно, у меня тоже нет.
> 
>  >>  Я их пока убрал из спека, но в kernel-headers-..., собранном уже
>  >>  с новым feat-i2c эти файлы почему-то другого размера, что есть
>  >>  странно и неправильно, нужно разбираться.
>   
>  SV>  А это, похоже, дурь в lm_sensors. Файлы действительно разные -
>  SV>  из того i2c-dev.h, что в i2c, выкинута вся userspace-часть. Но
>  SV>  lm_sensors при сборке его не использует - он берёт свой
>  SV>  i2c-dev.h, в котором есть ещё куча инлайнов. А sensors.h вообще
>  SV>  генерируется из драйверов (kernel/chips/*.c). Устанавливаться
>  SV>  эти файлы, похоже, вообще не должны - mkpatch в lm_sensors их не
>  SV>  трогает.
> Понятно. Значит я правильно сделал.

Ага.

Единственная проблема - нельзя собрать отдельно что-либо подобное
i2cdump (разве что носить нужный i2c-dev.h с собой).

Re: [d-kernel] Re: lm_sensors

[Ed V. Bartosh]

>>>>> "SV" == Sergey Vlasov writes:
...
 >>   SV>  А сюда, видимо, предполагалось положить содержимое каталога
 >>   SV>  doc?  Хотя это уже лежит в пакете lm_sensors...
 >>  убрано
  
 SV>  Ладно, жду заливки.
Угу, сегодня залью. Там достаточно много других изменений -
xfs новый (старый внезапно оказался без ACL-ей :)), под него пришлось
точить слегка ACPI и O(1)shed, может еще чего по мелочи.

 SV>  Единственная проблема - нельзя собрать отдельно что-либо
 SV>  подобное i2cdump (разве что носить нужный i2c-dev.h с собой).
Может его (i2c-dev.h) нужно таки положить в libdevel ?

-- 
Best regards,
Ed V. Bartosh

[d-kernel] Re: lm_sensors

[Vitaly Ostanin]

[-- Attachment #1: Type: text/plain, Size: 877 bytes --]

On Wed, 23 Jul 2003 16:12:12 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

> 
>  >>  Нужна некая схема зависимостей на патчи, чтобы в
>  >неправильном>  порядке нельзя было приложить, а еще лучше
>  >чтобы они>  прикладывались автоматом при надобности. И было
>  >бы неплохо>  встроить это дело в apply_patches.
>   
>  VO>  Можно я опять влезу с XML ? :)
> :) Любимое детище ?

Не моё и не самое любимое :) Просто самое логичное, из того, с
чем приходится работать.

>  VO>  Можно (и несложно на практике) оформить зависимости
>  VO>  патчей в XML, а потом генерировать из него скрипт в любой
>  VO>  нужной форме.
> Это по-моему из пушки по воробьям. проблема не в указании
> зависимостей как таковых, а в реализации, в тех самых скриптах.

Ага... Виноват, не так понял.

<skipped/>

-- 
Regards, Vyt
mailto:  vyt@vzljot.ru
JID:     vyt@vzljot.ru

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Thu, 24 Jul 2003 10:24:56 +0400
ed@altlinux.ru (Ed V. Bartosh) wrote:

>  SV>  Единственная проблема - нельзя собрать отдельно что-либо
>  SV>  подобное i2cdump (разве что носить нужный i2c-dev.h с собой).
> Может его (i2c-dev.h) нужно таки положить в libdevel ?

Нет - это всё-таки я напутал. В linux/i2c-dev.h всё есть, а тот
i2c-dev.h, что в lm_sensors - это объединение userspace-частей из
linux/i2c.h и linux/i2c-dev.h.

Re: [d-kernel] kernel security

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On Wed, Jul 23, 2003 at 04:45:33PM +0400, Ed V. Bartosh wrote:
> >>>>> "SV" == Sergey Vlasov writes:
[...]
> Кто у нас тут брался TODO вести. Я уже как минимум вот это начинаю
> забывать :)
[...]
> - Обновить kernel-fix-security патчами из последнего RH
[...]

Насколько я понимаю, самые неприятные ошибки были исправлены ещё в
kernel-fix-security-owl-2003.07.06-alt1; этот fix используется во всех
ядрах или нет?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [d-kernel] Re: lm_sensors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 655 bytes --]

On Wed, Jul 23, 2003 at 04:45:33PM +0400, Ed V. Bartosh wrote:
[...]
>  SV>  +%__cp -R ./ ../kernel-source-%name-%version
>  SV>  +
>   
>  SV>  Перед этим, вероятно, надо добавить
>   
>  SV>    %__rm -rf ../kernel-source-%name-%version
> добавлено

И в %clean то же самое надо добавить.

>  >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
>  >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
>   
>  SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
>  SV>  не должно - у меня его там нет.
> Да, правильно, у меня тоже нет.

А вот сам каталог /usr/include/sensors всё-таки нужен.

Ok, выложу сегодня -alt3.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Mon, 28 Jul 2003 19:36:40 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> >  >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
> >  >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
> >   
> >  SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
> >  SV>  не должно - у меня его там нет.
> > Да, правильно, у меня тоже нет.
> 
> А вот сам каталог /usr/include/sensors всё-таки нужен.
> 
> Ok, выложу сегодня -alt3.

Всё-таки с i2c-dev.h проблема есть - я посмотрел не на ту версию :-(

Тот i2c-dev.h, который lm_sensors пытается поставить в
/usr/include/linux, содержит inline-функции для доступа к I2C/SMBus из
userspace. А вот в файле <linux/i2c-dev.h>, попадающем в
kernel-headers-* (он происходит из kernel-feat-i2c), этих функций нет
(как оказалось, я посмотрел в файл от старой версии ядра - в i2c-2.7.0
они там были, а в i2c-2.8.0 их убрали).

Т.е. i2c-dev.h из lm_sensors надо бы сохранить, но ставить его туда,
куда он встаёт по умолчанию, нельзя. Куда его девать -
/usr/include/sensors или ещё куда?

Re: [d-kernel] Re: lm_sensors

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1223 bytes --]

On Mon, Jul 28, 2003 at 08:03:23PM +0400, Sergey Vlasov wrote:
> On Mon, 28 Jul 2003 19:36:40 +0400, Dmitry V. Levin wrote:
> > >  >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
> > >  >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
> > >   
> > >  SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
> > >  SV>  не должно - у меня его там нет.
> > > Да, правильно, у меня тоже нет.
> > 
> > А вот сам каталог /usr/include/sensors всё-таки нужен.
> > 
> > Ok, выложу сегодня -alt3.
> 
> Всё-таки с i2c-dev.h проблема есть - я посмотрел не на ту версию :-(
> 
> Тот i2c-dev.h, который lm_sensors пытается поставить в
> /usr/include/linux, содержит inline-функции для доступа к I2C/SMBus из
> userspace. А вот в файле <linux/i2c-dev.h>, попадающем в
> kernel-headers-* (он происходит из kernel-feat-i2c), этих функций нет
> (как оказалось, я посмотрел в файл от старой версии ядра - в i2c-2.7.0
> они там были, а в i2c-2.8.0 их убрали).
> 
> Т.е. i2c-dev.h из lm_sensors надо бы сохранить, но ставить его туда,
> куда он встаёт по умолчанию, нельзя. Куда его девать -
> /usr/include/sensors или ещё куда?

/usr/include/sensors/linux/i2c-dev.h?
А linux/sensors.h тоже там нужен?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[d-kernel] Re: lm_sensors

[Sergey Vlasov]

On Mon, 28 Jul 2003 20:12:24 +0400
"Dmitry V. Levin" <ldv@altlinux.org> wrote:

> On Mon, Jul 28, 2003 at 08:03:23PM +0400, Sergey Vlasov wrote:
> > On Mon, 28 Jul 2003 19:36:40 +0400, Dmitry V. Levin wrote:
> > > >  >>  Кроме того с i2c проблемы - конфликтует с kernel-headers по
> > > >  >>  поводу /usr/include/linux/{i2c-dev.h,sensors.h}.
> > > >   
> > > >  SV>  Oops - недочистил. Хотя sensors.h в kernel-headers вообще быть
> > > >  SV>  не должно - у меня его там нет.
> > > > Да, правильно, у меня тоже нет.
> > > 
> > > А вот сам каталог /usr/include/sensors всё-таки нужен.
> > > 
> > > Ok, выложу сегодня -alt3.
> > 
> > Всё-таки с i2c-dev.h проблема есть - я посмотрел не на ту версию :-(
> > 
> > Тот i2c-dev.h, который lm_sensors пытается поставить в
> > /usr/include/linux, содержит inline-функции для доступа к I2C/SMBus из
> > userspace. А вот в файле <linux/i2c-dev.h>, попадающем в
> > kernel-headers-* (он происходит из kernel-feat-i2c), этих функций нет
> > (как оказалось, я посмотрел в файл от старой версии ядра - в i2c-2.7.0
> > они там были, а в i2c-2.8.0 их убрали).
> > 
> > Т.е. i2c-dev.h из lm_sensors надо бы сохранить, но ставить его туда,
> > куда он встаёт по умолчанию, нельзя. Куда его девать -
> > /usr/include/sensors или ещё куда?
> 
> /usr/include/sensors/linux/i2c-dev.h?

Возможно. Хотя всё равно это странно. Пойду разработчиков спрашивать -
чего они хотели этим добиться.

> А linux/sensors.h тоже там нужен?

Не думаю - он используется при сборке libsensors, а за её пределами
вряд ли кому-то захочется лазить через sysctl - проще пойти в
/proc/sys/dev/sensors/... и не фиксировать набор доступных драйверов и
параметров.

Re: [d-kernel] kernel security

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 DVL>  Насколько я понимаю, самые неприятные ошибки были исправлены
 DVL>  ещё в kernel-fix-security-owl-2003.07.06-alt1; этот fix
 DVL>  используется во всех ядрах или нет?

Нет, конечно. Хотя бы потому, что там не только фиксы, а и фичи,
которые могут быть и не нужны.

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel security

[Ed V. Bartosh]

>>>>> "DVL" == Dmitry V. Levin writes:

 >>   DVL>  Насколько я понимаю, самые неприятные ошибки были
 >>   DVL>  исправлены ещё в kernel-fix-security-owl-2003.07.06-alt1;
 >>   DVL>  этот fix используется во всех ядрах или нет?
 >>   Нет, конечно. Хотя бы потому, что там не только фиксы, а и фичи,
 >>  которые могут быть и не нужны.
  
 DVL>  Тогда как нам поступить: - сплитить -ow нельзя; - фиксы из -ow
 DVL>  нужны всем.  ?
Сдублировать mandatory фиксы в kernel-fix-security и прикладывать их
только тогда, когда owl не прикладывается.

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

-- 
Best regards,
Ed V. Bartosh

Re: [d-kernel] kernel security

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 477 bytes --]

On Tue, Jul 29, 2003 at 02:03:47PM +0400, Ed V. Bartosh wrote:
> >>>>> "DVL" == Dmitry V. Levin writes:
> 
>  DVL>  Насколько я понимаю, самые неприятные ошибки были исправлены
>  DVL>  ещё в kernel-fix-security-owl-2003.07.06-alt1; этот fix
>  DVL>  используется во всех ядрах или нет?
> 
> Нет, конечно. Хотя бы потому, что там не только фиксы, а и фичи,
> которые могут быть и не нужны.

Тогда как нам поступить:
- сплитить -ow нельзя;
- фиксы из -ow нужны всем.
?


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]