Re: Bug#171555: ITP: kernel-patch-sensors Hardware health monitoring tool (kernel patch) . This package contains two kernel patches. For 2.4.19 and 2.4.20.
Robert Nagy <firstname.lastname@example.org> writes:
> * Package name : kernel-patch-sensors
> Version : 2.6.5
> Upstream Author : The Lm_sensors Group <email@example.com>
> * URL : http://www2.lm-sensors.nu/~lm78/
> * License : GPL
> Description : Lm-sensors is a hardware health monitoring package for Linux (kernel patch)
> I've created the patches on my own for 2.4.19 and 2.4.20 from the
> lm-sensors-source package.
> This patch allow you patch you kernel with lm_sensors.
Hmm. I (as the lm-sensors maintainer) am a little ambiguous about
this. It seems wrong to have two separate source packages for
lm-sensors when they both do the same thing. But I'm also unclear
whether the effort of maintaining a kernel-patch version of lm-sensors
in addition to the modules source is useful effort, since this sounds
like something that's hard to debug via the BTS.
How involved are the patches? (How does the kernel-package
patch_the_kernel option work?) Can you submit a wishlist bug against
lm-sensors-source, at least?
> This package Depends on kernel-patch-i2c.
How much "depends"? Right now the standalone kernel modules for
lm-sensors 2.6.5 depend on i2c 2.6.1 or newer, so the version of i2c
in kernels 2.4.13 or newer works fine too. There's magic in the
lm-sensors-source package to figure this out. Repeat everything I
said before about kernel patches, replacing lm-sensors with i2c
(including filing a wishlist bug against i2c-source).
David Maze firstname.lastname@example.org http://people.debian.org/~dmaze/
"Theoretical politics is interesting. Politicking should be illegal."
-- Abra Mitchell