Bug#219172: RFA: lm-sensors, i2c
I'm looking for someone to take over maintenance of the lm-sensors
hardware monitoring package, along with the corresponding i2c interface
kernel modules. These two packages have the same upstream and they're
pretty closely related, so it'd be nice if they had the same maintainer.
Both packages involve kernel modules. The lm-sensors package also
involves a shared library and a few userspace packages. I'd like to say
that these are clean friendly packages; they're at least lintian-clean,
and the packaging is fairly sane (and debhelperful, if that matters to
you), but there are Issues...
(1) lm-sensors 2.8 userspace depends on lm-sensors 2.8 kernel modules,
which depend on i2c 2.8 kernel modules. But the Linux kernel has
i2c 2.6 kernel modules, and mix-and-match ==> kernel panic. See
bug #209228. I haven't figured out a good way around this yet.
Also, you can't just patch the kernel to use the newer i2c modules,
since i2c support bleeds over into several other kernel modules.
(2) The library's soname has changed recently. This wouldn't be so
bad, but lm-sensors 2.7.0 contained a different libsensors1 from
lm-sensors 2.6.5, so later versions of lm-sensors 2.7.0 had a
libsensors-1debian1. Upstream did fix the soname, so now lm-sensors
2.8.0 has libsensors2. But, meanwhile, kdebase has a package
(ksysguardd) that got compiled against libsensors-1debian1, and
went into testing (!) in spite of the corresponding libsensors
never having made it.
(3) Minor i18n things that I've never gotten to looking at, mostly with
the output wanting to use a "degree" character.
I haven't really been using my one machine that can use lm-sensors
much, and my current housemates object to it being left on (it's loud),
so I don't have good access to a machine to test it on. If you're
looking at this package, you should definitely have hardware that
can make use of this package, and maybe you're using it already.
-- System Information:
Debian Release: testing/unstable
Kernel: Linux everett 2.4.21-3-everett #1 Thu Aug 7 13:20:54 UTC 2003 i686
Locale: LANG=C, LC_CTYPE=C