[lm-sensors,GIT] kbuild fixes for 3.0

Commit Message

Jean Delvare June 10, 2011, 7:31 p.m. UTC

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 <[e-mail]> 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?


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.

Patch

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