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 [off-list ref] wrote:

quoted

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