Salut Arnaud,
On Fri, 10 Jun 2011 12:30:59 -0400, Arnaud Lacombe wrote:
> On Fri, Jun 10, 2011 at 1:16 AM, Arnaud Lacombe <lacombar@xxxxxxxxx> wrote:
> > I totally agree! But, it is a technical challenge to give a 2 digit
> > version number to an application expecting a 3 digit version number
> > without much control over its environment.
> >
> > Beside that, no matter what, you are about to break
> > `/usr/sbin/sensors-detect' (from my Fedora 14), which rely on a 3
> > digits version number:
> >
> > # [0] -> VERSION
> > # [1] -> PATCHLEVEL
> > # [2] -> SUBLEVEL
> > # [3] -> EXTRAVERSION
> > #
> > use vars qw(@kernel_version $kernel_arch);
> >
> > sub initialize_kernel_version
> > {
> > `uname -r` =~ /(\d+)\.(\d+)\.(\d+)(.*)/;
> > @kernel_version = ($1, $2, $3, $4);
> > chomp($kernel_arch = `uname -m`);
> >
> > # We only support kernels >= 2.6.5
> > if (!kernel_version_at_least(2, 6, 5)) {
> > print "Kernel version is unsupported (too old, >=
> > 2.6.5 needed)\n";
> > exit -1;
> > }
> > }
> >
> `sensors-detect's kernel version detection regexp is unable to parse 2
> digits kernel version number and dies with:
>
> [From Fedora 14's /usr/sbin/sensors-detect]
>
> Use of uninitialized value $kernel_version[0] in numeric gt (>) at
> ./sensors-detect line 2442.
> Use of uninitialized value $kernel_version[0] in numeric eq (==) at
> ./sensors-detect line 2442.
> Kernel version is unsupported (too old, >= 2.6.5 needed)
>
> I just checked the SVN repository, the issue still seems to be
> present. I am not sure if other lm-sensors part are affected. This
> will becomes an issue with the upcoming 3.x kernel serie.
Does the following patch help?
Index: prog/detect/sensors-detect
===================================================================
--- prog/detect/sensors-detect (révision 5979)
+++ prog/detect/sensors-detect (copie de travail)
@@ -2462,8 +2462,8 @@
sub initialize_kernel_version
{
- `uname -r` =~ /(\d+)\.(\d+)\.(\d+)(.*)/;
- @kernel_version = ($1, $2, $3, $4);
+ `uname -r` =~ /(\d+)\.(\d+)(?:\.(\d+))?(.*)/;
+ @kernel_version = ($1, $2, $3 || 0, $4);
chomp($kernel_arch = `uname -m`);
# We only support kernels >= 2.6.5
I don't expect any other breakage in lm-sensors, but I certainly do in
other packages. For example the function above exists in script
i2c-stub-from-dump in package i2c-tools too.
Honestly, this whole 2-digit kernel version seems like a major and
better avoided pain. The first stable series kernel for 3.0 will be
3.0.1, so it will have 3 digits again. Which means that in practice,
most distributions and users will still be running kernels with 3-digit
versions. Breaking dozens of scripts for what will end up being a mere
corner case seems silly to me. We all have better things to do than to
fix random user-space scripts, don't we?
I fail to see how numbering the next kernel "3.0" will make it any
cooler than numbering it "3.0.0". Especially when nobody will run it
for longer than 2 weeks.
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@xxxxxxxxxxxxxx
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
