[GIT] kbuild fixes for 3.0

[GIT] kbuild fixes for 3.0

[Michal Marek]

Hi Linus,

These are the fixes to make sure 3.0 relally is 3.0, plus one fix for
Makefile.asm-generic.  Please pull and unset the SUBLEVEL variable,
thanks.

Michal

The following changes since commit 55922c9d1b84b89cb946c777fddccb3247e7df2c:

  Linux 3.0-rc1 (2011-05-29 17:43:36 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git rc-fixes

Michal Marek (5):
      kbuild: Fix KERNELVERSION for empty SUBLEVEL or PATCHLEVEL
      kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL
      kbuild: Move depmod call to a separate script
      kbuild: Hack for depmod not handling X.Y versions
      perf: Use make kernelversion instead of parsing the Makefile

Peter Foley (1):
      kbuild: silence Nothing to be done for 'all' message

 Makefile                         |   16 ++----------
 scripts/Makefile.asm-generic     |    1 +
 scripts/depmod.sh                |   48 ++++++++++++++++++++++++++++++++++++++
 tools/perf/util/PERF-VERSION-GEN |    7 +----
 4 files changed, 53 insertions(+), 19 deletions(-)
 create mode 100755 scripts/depmod.sh

Re: [GIT] kbuild fixes for 3.0

[Linus Torvalds]

On Thu, Jun 9, 2011 at 2:42 PM, Michal Marek <mmarek@suse.cz> wrote:
>
>      kbuild: Hack for depmod not handling X.Y versions

This doesn't seem to be enough, I still get (on F-14):

  sh /home/torvalds/v2.6/linux/arch/x86/boot/install.sh
3.0-rc2-00251-g7f45e5cd1718-dirty arch/x86/boot/bzImage \
  	System.map "/boot"
  WARNING: Couldn't open directory
/tmp/initramfs.Z9p0zm/lib/modules/3.0.0-rc2-00191-g4c1f683a4a34-dirty:
No such file or directory
  FATAL: Could not open
/tmp/initramfs.Z9p0zm/lib/modules/3.0.0-rc2-00191-g4c1f683a4a34-dirty/modules.dep.temp
for writing: No such file or directory
  E: "depmod -a 3.0-rc2-00251-g7f45e5cd1718-dirty" failed.

from "make install" when I try to remove the SUBLEVEL.

As a result, the initrd is unusable, and has no modules in it.

                Linus

Re: [GIT] kbuild fixes for 3.0

[Arnaud Lacombe]

Hi,

On Thu, Jun 9, 2011 at 8:10 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jun 9, 2011 at 2:42 PM, Michal Marek <mmarek@suse.cz> wrote:
>>
>>      kbuild: Hack for depmod not handling X.Y versions
>
> This doesn't seem to be enough, I still get (on F-14):
>
>  sh /home/torvalds/v2.6/linux/arch/x86/boot/install.sh
> 3.0-rc2-00251-g7f45e5cd1718-dirty arch/x86/boot/bzImage \
>        System.map "/boot"
>  WARNING: Couldn't open directory
> /tmp/initramfs.Z9p0zm/lib/modules/3.0.0-rc2-00191-g4c1f683a4a34-dirty:
> No such file or directory
>  FATAL: Could not open
> /tmp/initramfs.Z9p0zm/lib/modules/3.0.0-rc2-00191-g4c1f683a4a34-dirty/modules.dep.temp
> for writing: No such file or directory
>  E: "depmod -a 3.0-rc2-00251-g7f45e5cd1718-dirty" failed.
>
> from "make install" when I try to remove the SUBLEVEL.
>
> As a result, the initrd is unusable, and has no modules in it.
>
any chance to share your .config ? x86-64's defconfig, plus Michal
branch merged on top of the tip of your tree, plus the following patch
removing the SUBLEVEL:

diff --git a/Makefile b/Makefile
index 72c0e32..5c75864 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
 VERSION = 3
 PATCHLEVEL = 0
-SUBLEVEL = 0
+SUBLEVEL =
 EXTRAVERSION = -rc2
 NAME = Sneaky Weasel

install is fine for me. What bugs me is that "git grep '\.temp'" in
that tree does not return anything relevant.

Thanks,
 - Arnaud

Re: [GIT] kbuild fixes for 3.0

[Linus Torvalds]

On Thu, Jun 9, 2011 at 8:14 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> any chance to share your .config ? x86-64's defconfig, plus Michal
> branch merged on top of the tip of your tree, plus the following patch
> removing the SUBLEVEL:
>
> diff --git a/Makefile b/Makefile
> index 72c0e32..5c75864 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1,6 +1,6 @@
>  VERSION = 3
>  PATCHLEVEL = 0
> -SUBLEVEL = 0
> +SUBLEVEL =
>  EXTRAVERSION = -rc2
>  NAME = Sneaky Weasel
>
> install is fine for me. What bugs me is that "git grep '\.temp'" in
> that tree does not return anything relevant.

"make install" just runs the distro install script, usually
/sbin/installkernel, which at least on F-14 will then run
/sbin/new-kernel-pkg /sbin/dracut to build the initrd etc.

And that runs "depmod", which seems to end up being confused: we give
it the new kernel version as an argument, but it seems to not like it,
so it decides to do "uname()" to get the _current_ kernel version
instead, and that is where the confusion comes from.

If it works for you, I suspect you're running a different distribution.

                  Linus

Re: [GIT] kbuild fixes for 3.0

[Arnaud Lacombe]

Hi,

On Thu, Jun 9, 2011 at 11:37 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jun 9, 2011 at 8:14 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>
>> any chance to share your .config ? x86-64's defconfig, plus Michal
>> branch merged on top of the tip of your tree, plus the following patch
>> removing the SUBLEVEL:
>>
>> diff --git a/Makefile b/Makefile
>> index 72c0e32..5c75864 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1,6 +1,6 @@
>>  VERSION = 3
>>  PATCHLEVEL = 0
>> -SUBLEVEL = 0
>> +SUBLEVEL =
>>  EXTRAVERSION = -rc2
>>  NAME = Sneaky Weasel
>>
>> install is fine for me. What bugs me is that "git grep '\.temp'" in
>> that tree does not return anything relevant.
>
> "make install" just runs the distro install script, usually
> /sbin/installkernel, which at least on F-14 will then run
> /sbin/new-kernel-pkg /sbin/dracut to build the initrd etc.
>
> And that runs "depmod", which seems to end up being confused: we give
> it the new kernel version as an argument, but it seems to not like it,
> so it decides to do "uname()" to get the _current_ kernel version
> instead, and that is where the confusion comes from.
>
> If it works for you, I suspect you're running a different distribution.
>
Actually, I was just installing as a user with INSTALL_PATH set, so it
did not get until the `new-kernel-pkg' step.

 - Arnaud


>                  Linus
>

Re: [GIT] kbuild fixes for 3.0

[Arnaud Lacombe]

Hi,

On Thu, Jun 9, 2011 at 11:37 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jun 9, 2011 at 8:14 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>
>> any chance to share your .config ? x86-64's defconfig, plus Michal
>> branch merged on top of the tip of your tree, plus the following patch
>> removing the SUBLEVEL:
>>
>> diff --git a/Makefile b/Makefile
>> index 72c0e32..5c75864 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -1,6 +1,6 @@
>>  VERSION = 3
>>  PATCHLEVEL = 0
>> -SUBLEVEL = 0
>> +SUBLEVEL =
>>  EXTRAVERSION = -rc2
>>  NAME = Sneaky Weasel
>>
>> install is fine for me. What bugs me is that "git grep '\.temp'" in
>> that tree does not return anything relevant.
>
> "make install" just runs the distro install script, usually
> /sbin/installkernel, which at least on F-14 will then run
> /sbin/new-kernel-pkg /sbin/dracut to build the initrd etc.
>
> And that runs "depmod", which seems to end up being confused: we give
> it the new kernel version as an argument, but it seems to not like it,
> so it decides to do "uname()" to get the _current_ kernel version
> instead, and that is where the confusion comes from.
>
For the record, this should have been fixed by Michal in:

commit 3328d178247017affd90b7897393699f2f45227d
Author: Michal Marek <mmarek@suse.cz>
Date:   Mon May 30 15:58:43 2011 +0200

    depmod: Handle X.Y kernel versions

    What a stupid check.

    Signed-off-by: Michal Marek <mmarek@suse.cz>
    Signed-off-by: Jon Masters <jcm@jonmasters.org>

from the module-init-tools git tree. Change is pretty trivial:

diff --git a/depmod.c b/depmod.c
index abfb11e..98a5efa 100644
--- a/depmod.c
+++ b/depmod.c
@@ -247,7 +247,7 @@ static int is_version_number(const char *version)
 {
        unsigned int dummy;

-       return (sscanf(version, "%u.%u.%u", &dummy, &dummy, &dummy) == 3);
+       return (sscanf(version, "%u.%u", &dummy, &dummy) == 2);
 }

 - Arnaud

> If it works for you, I suspect you're running a different distribution.
>
>                  Linus
>

Re: [GIT] kbuild fixes for 3.0

[Linus Torvalds]

On Thu, Jun 9, 2011 at 8:45 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>
> For the record, this should have been fixed by Michal in:

You're missing the problem: we can't assume that people have updated user land.

Furthermore, the very pull request I'm responding to actually tries to
handle this, see commit bfe5424a8b31 ("kbuild: Hack for depmod not
handling X.Y versions"), but it's just not working for me.

And it's not working, because it only handles the "modules_install"
case, not the case where the system install scripts do their own
depmod.

                       Linus

Re: [GIT] kbuild fixes for 3.0

[Arnaud Lacombe]

Hi,

On Thu, Jun 9, 2011 at 11:57 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Thu, Jun 9, 2011 at 8:45 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>
>> For the record, this should have been fixed by Michal in:
>
> You're missing the problem: we can't assume that people have updated user land.
>
I absolutely agree with you. But I am not the one about to decide to
break a 15 years old interface :) [I gave me a 5 year delta as I have
no idea how the version number was at that time; moreover, do not get
me wrong, I do not really care about the kernel version being 2 or 3
digits.].

> Furthermore, the very pull request I'm responding to actually tries to
> handle this, see commit bfe5424a8b31 ("kbuild: Hack for depmod not
> handling X.Y versions"), but it's just not working for me.
>
> And it's not working, because it only handles the "modules_install"
> case, not the case where the system install scripts do their own
> depmod.
>
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;
        }
}

sub kernel_version_at_least
{
        my ($vers, $plvl, $slvl) = @_;
        return 1 if ($kernel_version[0] > $vers ||
                     ($kernel_version[0] == $vers &&
                      ($kernel_version[1] > $plvl ||
                       ($kernel_version[1] == $plvl &&
                        ($kernel_version[2] >= $slvl)))));
        return 0;
}

would fail with:

Kernel version is unsupported (too old, >= 2.6.5 needed)

with "uname -r" being "3.0-rc2"

 - Arnaud

Re: [GIT] kbuild fixes for 3.0

[Ray Lee]

On Thu, Jun 9, 2011 at 10:16 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> 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:

Is there really any compelling technical reason to _not_ have Linus
release the kernels with a superfluous .0 on the end, with the
understanding that the -stable team gets to increment it for their
future releases? It'd make every kernel.org release exactly three
dotted decimals from here on out, which certainly simplifies things.

It seems like we're just borrowing trouble here by trying to drop it
down to two numbers.

(Not, mind you, that I give a damn at all one way or the other, but it
feels like you all are going to be spending a lot of time tripping
over poor assumptions in userspace rather than doing actual work.)

~r.

Re: [GIT] kbuild fixes for 3.0

[maximilian attems]

On Thu, Jun 09, 2011 at 10:53:34PM -0700, Ray Lee wrote:
> On Thu, Jun 9, 2011 at 10:16 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> > 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:
> 
> Is there really any compelling technical reason to _not_ have Linus
> release the kernels with a superfluous .0 on the end, with the
> understanding that the -stable team gets to increment it for their
> future releases? It'd make every kernel.org release exactly three
> dotted decimals from here on out, which certainly simplifies things.
> 
> It seems like we're just borrowing trouble here by trying to drop it
> down to two numbers.
> 
> (Not, mind you, that I give a damn at all one way or the other, but it
> feels like you all are going to be spending a lot of time tripping
> over poor assumptions in userspace rather than doing actual work.)

you have forgotten the rule that linus himself is allowed to break userland. :P

in Debian an three digit 3.0.0 release would also be very much appreciated as
dpkg will order wrongly 3.0.0~rcX to 3.0.

-- 
maks

Re: [GIT] kbuild fixes for 3.0

[Linus Torvalds]

On Fri, Jun 10, 2011 at 3:03 AM, maximilian attems <max@stro.at> wrote:
>
> you have forgotten the rule that linus himself is allowed to break userland. :P

No.

But Linus _is_ allowed to try to fix problems. So what I'm trying to do is:

 - see if we can find work-arounds for known broken packages (by
giving them a three-digit version number despite the kernel actually
only having two digits)

 - if no such work-arounds can be done without excessive hackery, at
least make sure that the packages in question know that they are
broken, so that they get fixed and we can drop the third digit later
even if we don't drop it at 3.0 itself.

It does look like there are too many problems to actually make it call
itself "3.0", and that's sad. That's not an excuse for not trying to
get those problems fixed, though.

                       Linus

Re: [GIT] kbuild fixes for 3.0

[Michal Marek]

Dne 10.6.2011 17:22, Linus Torvalds napsal(a):
>  - if no such work-arounds can be done without excessive hackery, at
> least make sure that the packages in question know that they are
> broken, so that they get fixed and we can drop the third digit later
> even if we don't drop it at 3.0 itself.

So can we fix the kernel package now, even if the version has to stay at
3.0.0? The depmod hack is probably superfluous, but the rest are either
cleanups or fixes to make a future NUM.NUM release:

      kbuild: Fix KERNELVERSION for empty SUBLEVEL or PATCHLEVEL
      kbuild: Fix <linux/version.h> for empty SUBLEVEL or PATCHLEVEL
      kbuild: Move depmod call to a separate script
      perf: Use make kernelversion instead of parsing the Makefile

and this one is a genuine regression fix:

      kbuild: silence Nothing to be done for 'all' message

So would pull the branch if I revert "kbuild: Hack for depmod not
handling X.Y versions"?

thanks,
Michal

Re: [GIT] kbuild fixes for 3.0

[Linus Torvalds]

On Fri, Jun 10, 2011 at 1:45 PM, Michal Marek <mmarek@suse.cz> wrote:
>
> So would pull the branch if I revert "kbuild: Hack for depmod not
> handling X.Y versions"?

Umm. I already pulled it yesterday. The reason I then replied to the
pull request was to report that it isn't enough to actually get things
working..

                    Linus

Re: [GIT] kbuild fixes for 3.0

[Andy Whitcroft]

On Fri, Jun 10, 2011 at 6:53 AM, Ray Lee <ray-lk@madrabbit.org> wrote:
> On Thu, Jun 9, 2011 at 10:16 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>> 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:
>
> Is there really any compelling technical reason to _not_ have Linus
> release the kernels with a superfluous .0 on the end, with the
> understanding that the -stable team gets to increment it for their
> future releases? It'd make every kernel.org release exactly three
> dotted decimals from here on out, which certainly simplifies things.
>
> It seems like we're just borrowing trouble here by trying to drop it
> down to two numbers.
>
> (Not, mind you, that I give a damn at all one way or the other, but it
> feels like you all are going to be spending a lot of time tripping
> over poor assumptions in userspace rather than doing actual work.)

As an experiment I have uploaded a 3.0 reporting kernel into Ubuntu
Oneiric.  So far we have had issues with:

 - depmod -- (as above)
 - procps (ps/top) -- reporting errors on startup
 - glibc version checks are preventing upgrade of that package

I am sure there will be others, but the last one above has me cornered
at the moment.  Cirtainly we can fix all of these but we are not going
to make it easy for people with un-upgraded userspace if my experience
is anything to go by.

-apw

Re: [GIT] kbuild fixes for 3.0

[Milan Broz]

On 06/10/2011 05:06 PM, Andy Whitcroft wrote:
> As an experiment I have uploaded a 3.0 reporting kernel into Ubuntu
> Oneiric.  So far we have had issues with:
> 
>  - depmod -- (as above)
>  - procps (ps/top) -- reporting errors on startup
>  - glibc version checks are preventing upgrade of that package
> 
> I am sure there will be others

All tools based on libdevmapper (lvm, cryptsetup, kpartx, ...)
fails in initialization. (fixed already in devel tree)

mdadm is broken with 3.0 as well (it fails to auto assemble devices)
because of misparsing kernel version.

Fedora was quite proactive and added uts name patch "3.0-rc1",
so you can see what it caused... (unbootable system in short)

https://bugzilla.redhat.com/show_bug.cgi?id=710646

Milan

Re: [GIT] kbuild fixes for 3.0

[Arnaud Lacombe]

Hi,

[following-up to lm-sensors@lm-sensors.org for bug-report.]

On Fri, Jun 10, 2011 at 1:16 AM, Arnaud Lacombe <lacombar@gmail.com> wrote:
> Hi,
>
> On Thu, Jun 9, 2011 at 11:57 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> On Thu, Jun 9, 2011 at 8:45 PM, Arnaud Lacombe <lacombar@gmail.com> wrote:
>>>
>>> For the record, this should have been fixed by Michal in:
>>
>> You're missing the problem: we can't assume that people have updated user land.
>>
> I absolutely agree with you. But I am not the one about to decide to
> break a 15 years old interface :) [I gave me a 5 year delta as I have
> no idea how the version number was at that time; moreover, do not get
> me wrong, I do not really care about the kernel version being 2 or 3
> digits.].
>
>> Furthermore, the very pull request I'm responding to actually tries to
>> handle this, see commit bfe5424a8b31 ("kbuild: Hack for depmod not
>> handling X.Y versions"), but it's just not working for me.
>>
>> And it's not working, because it only handles the "modules_install"
>> case, not the case where the system install scripts do their own
>> depmod.
>>
> 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.

Regards,
 - Arnaud

> sub kernel_version_at_least
> {
>        my ($vers, $plvl, $slvl) = @_;
>        return 1 if ($kernel_version[0] > $vers ||
>                     ($kernel_version[0] == $vers &&
>                      ($kernel_version[1] > $plvl ||
>                       ($kernel_version[1] == $plvl &&
>                        ($kernel_version[2] >= $slvl)))));
>        return 0;
> }
>
> would fail with:
>
> Kernel version is unsupported (too old, >= 2.6.5 needed)
>
> with "uname -r" being "3.0-rc2"
>
>  - Arnaud
>

Re: [lm-sensors] [GIT] kbuild fixes for 3.0

[Jean Delvare]

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@gmail.com> 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

Re: [GIT] kbuild fixes for 3.0

[Michal Marek]

On 10.6.2011 05:57, Linus Torvalds wrote:
> On Thu, Jun 9, 2011 at 8:45 PM, Arnaud Lacombe<lacombar@gmail.com>  wrote:
>>
>> For the record, this should have been fixed by Michal in:
>
> You're missing the problem: we can't assume that people have updated user land.
>
> Furthermore, the very pull request I'm responding to actually tries to
> handle this, see commit bfe5424a8b31 ("kbuild: Hack for depmod not
> handling X.Y versions"), but it's just not working for me.

It handles what can be handled inside the kernel build, i.e. the depmod 
called from the Makefile during modules_install.


> And it's not working, because it only handles the "modules_install"
> case, not the case where the system install scripts do their own
> depmod.

Yes, tools creating an initrd would need a similar workaround, that's a 
pity :-(.

Michal