linux-kernel - Re: [PATCH] Linux 3.8-merge version information

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <50C78A96.8000705@hartkopp.net>
Date:	Tue, 11 Dec 2012 20:33:42 +0100
From:	Oliver Hartkopp <socketcan@...tkopp.net>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Linux 3.8-merge version information

Thanks for your explanation.

Indeed i was not really aware of commit counter as the first number, even if i
used CONFIG_LOCALVERSION_AUTO=y for a while now.

The obviously outdated Kconfig help of CONFIG_LOCALVERSION_AUTO told me:

	A string of the format -gxxxxxxxx will be added to the localversion
	if a git-based tree is found.  The string generated by this will be
	appended after any matching localversion* files, and after the value
	set in CONFIG_LOCALVERSION.

	(The actual string used here is the first eight characters produced
	by running the command:

	$ git rev-parse --verify HEAD

	which is done within the script "scripts/setlocalversion".)

Maybe you can integrate parts of your comprehensive answer into this help
text, as it will fit better than my awkward English %-)

Tnx & best regards,
Oliver


On 11.12.2012 19:57, Linus Torvalds wrote:

> On Tue, Dec 11, 2012 at 5:06 AM, Oliver Hartkopp <socketcan@...tkopp.net> wrote:
>> As the automatically generated git version information is misleading in the
>> merge window, name the kernel in the merge window as 3.8-merge .
> 
> This really doesn't help.
> 
> 90% of the commits during the merge window wouldn't be based on that
> Makefile change anyway, but on some much older version. So when
> bisecting, for example, you'll see Makefiles with much older version
> numbers, even though the commits got merged into the 3.8 merge window.
> 
> Also, we have code to generate the version number automatically. In
> particular, I encourage people to use git trees and
> CONFIG_LOCALVERSION_AUTO=y, because then your /var/log/messages (and
> uname -r) will contain the exact git version of your kernel. So when
> you see something like
> 
>     Linux version 3.7.0-rc8-00041-gcaf491916b1c
> 
> in your message log, you'll know that the kernel you were running back
> then was 41 commits past -rc8, and had git commit ID of caf491916b1c.
> And that is really useful for things like bisections ("Ok, I know it
> worked three days ago - what kernel was I running then?") much more so
> than a Makefile change would be (never mind how unreliable the version
> info in the makefile is).
> 
> So this is why we only change the version in the Makefile when we do a
> new tagged release.
> 
>                     Linus


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/