does a normal OE kernel build negate the ability to generate a local version string?

does a normal OE kernel build negate the ability to generate a local version string?

[Robert P. J. Day]

  i was just playing with wind river linux 8 and trying to figure out
why i couldn't generate a local version string that contained the git
commit ID, so i zipped over to oe-core to see how it was done there,
and it seems to be the same way, so can someone clarify that my
understanding here is correct?

  normally, if i want to add the git commit ID ("-gxxxxxxxx") to the
kernel version string so it's available via "uname", i'm used to
selecting the kernel config option CONFIG_LOCALVERSION_AUTO, which
uses:

 $ git rev-parse --verify HEAD

to extract the first 8 characters of the commit ID. so i selected that
option, but wasn't getting that string.

  poking around further, i saw this in scripts/setlocalversion:

scm_version()
{
        local short
        short=false

        cd "$srctree"
        if test -e .scmversion; then
                cat .scmversion
                return
        fi
        ... snip ...

so if the file ".scmversion" exists, its contents are used instead.
now *i* never set that file, but lo and behold, in the kernel source
tree, there it was, empty, which explains why i wasn't getting any
local version string.

  and where did that empty .scmversion file come from? i see this in
kernel.bbclass:

kernel_do_configure() {
        # fixes extra + in /lib/modules/2.6.37+
        # $ scripts/setlocalversion . => +
        # $ make kernelversion => 2.6.37
        # $ make kernelrelease => 2.6.37+
        touch ${B}/.scmversion ${S}/.scmversion    <---- there
        ... snip ...

which clearly appears to touch that empty file. is that deliberate? is
this an explicit decision by this bbclass file to prevent people from
generating that local version string? am i reading all this correctly?

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: does a normal OE kernel build negate the ability to generate a local version string?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2130 bytes --]

On Fri, Apr 08, 2016 at 09:57:02AM -0400, Robert P. J. Day wrote:
> 
>   i was just playing with wind river linux 8 and trying to figure out
> why i couldn't generate a local version string that contained the git
> commit ID, so i zipped over to oe-core to see how it was done there,
> and it seems to be the same way, so can someone clarify that my
> understanding here is correct?
> 
>   normally, if i want to add the git commit ID ("-gxxxxxxxx") to the
> kernel version string so it's available via "uname", i'm used to
> selecting the kernel config option CONFIG_LOCALVERSION_AUTO, which
> uses:
> 
>  $ git rev-parse --verify HEAD
> 
> to extract the first 8 characters of the commit ID. so i selected that
> option, but wasn't getting that string.
> 
>   poking around further, i saw this in scripts/setlocalversion:
> 
> scm_version()
> {
>         local short
>         short=false
> 
>         cd "$srctree"
>         if test -e .scmversion; then
>                 cat .scmversion
>                 return
>         fi
>         ... snip ...
> 
> so if the file ".scmversion" exists, its contents are used instead.
> now *i* never set that file, but lo and behold, in the kernel source
> tree, there it was, empty, which explains why i wasn't getting any
> local version string.
> 
>   and where did that empty .scmversion file come from? i see this in
> kernel.bbclass:
> 
> kernel_do_configure() {
>         # fixes extra + in /lib/modules/2.6.37+
>         # $ scripts/setlocalversion . => +
>         # $ make kernelversion => 2.6.37
>         # $ make kernelrelease => 2.6.37+
>         touch ${B}/.scmversion ${S}/.scmversion    <---- there
>         ... snip ...
> 
> which clearly appears to touch that empty file. is that deliberate? is
> this an explicit decision by this bbclass file to prevent people from
> generating that local version string? am i reading all this correctly?

Yes, see
http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053263.html
for more details

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: does a normal OE kernel build negate the ability to generate a local version string?

[Robert P. J. Day]

On Fri, 8 Apr 2016, Martin Jansa wrote:

> On Fri, Apr 08, 2016 at 09:57:02AM -0400, Robert P. J. Day wrote:
> >
> >   i was just playing with wind river linux 8 and trying to figure out
> > why i couldn't generate a local version string that contained the git
> > commit ID, so i zipped over to oe-core to see how it was done there,
> > and it seems to be the same way, so can someone clarify that my
> > understanding here is correct?
> >
> >   normally, if i want to add the git commit ID ("-gxxxxxxxx") to the
> > kernel version string so it's available via "uname", i'm used to
> > selecting the kernel config option CONFIG_LOCALVERSION_AUTO, which
> > uses:
> >
> >  $ git rev-parse --verify HEAD
> >
> > to extract the first 8 characters of the commit ID. so i selected that
> > option, but wasn't getting that string.
> >
> >   poking around further, i saw this in scripts/setlocalversion:
> >
> > scm_version()
> > {
> >         local short
> >         short=false
> >
> >         cd "$srctree"
> >         if test -e .scmversion; then
> >                 cat .scmversion
> >                 return
> >         fi
> >         ... snip ...
> >
> > so if the file ".scmversion" exists, its contents are used instead.
> > now *i* never set that file, but lo and behold, in the kernel source
> > tree, there it was, empty, which explains why i wasn't getting any
> > local version string.
> >
> >   and where did that empty .scmversion file come from? i see this in
> > kernel.bbclass:
> >
> > kernel_do_configure() {
> >         # fixes extra + in /lib/modules/2.6.37+
> >         # $ scripts/setlocalversion . => +
> >         # $ make kernelversion => 2.6.37
> >         # $ make kernelrelease => 2.6.37+
> >         touch ${B}/.scmversion ${S}/.scmversion    <---- there
> >         ... snip ...
> >
> > which clearly appears to touch that empty file. is that deliberate? is
> > this an explicit decision by this bbclass file to prevent people from
> > generating that local version string? am i reading all this correctly?
>
> Yes, see
> http://lists.openembedded.org/pipermail/openembedded-core/2011-December/053263.html
> for more details

  hmmmmm ... that's disappointing as i could have used that feature. i
guess i can always tweak a recipe that removes those files.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================