Setting PV dynamically in a recipe

Setting PV dynamically in a recipe

[Brad Litterell]

Hi,

I have a few recipes in my image that represent my own custom code.  I would like to generate PV dynamically from my source code, but since the recipe is parsed before the code is extracted from the tarball, that's not easy to do.

The Poky reference manual implies this is possible:
PV is generally not overridden within a recipe unless it is building an unstable (i.e. development) version from a source code repository (e.g. Git or Subversion).

However, I have not found an actual example. Is there a recommended way to do this?

Thanks,
Brad

Re: Setting PV dynamically in a recipe

[zhenhua.luo]

AUTOREV might be what you are looking for.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-AUTOREV


Best Regards,

Zhenhua

> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-
> bounces@yoctoproject.org] On Behalf Of Brad Litterell
> Sent: Tuesday, December 17, 2013 4:17 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] Setting PV dynamically in a recipe
> 
> Hi,
> 
> I have a few recipes in my image that represent my own custom code.  I
> would like to generate PV dynamically from my source code, but since the
> recipe is parsed before the code is extracted from the tarball, that's
> not easy to do.
> 
> The Poky reference manual implies this is possible:
> PV is generally not overridden within a recipe unless it is building an
> unstable (i.e. development) version from a source code repository (e.g.
> Git or Subversion).
> 
> However, I have not found an actual example. Is there a recommended way
> to do this?
> 
> Thanks,
> Brad
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
> 

Re: Setting PV dynamically in a recipe

[Brad Litterell]

Hi Zhenhua,

Thank you for the reply.  However, That's not what I'm looking for.  I already get the latest version of the source code.

What I'm really after is the ability to generate output packages that have increasing version numbers so I can use the package manager to update them.

I think Martin's subsequent reply is the secret to use PKGV.  I didn't know about that variable.

Cheers,
Brad


________________________________________
From: zhenhua.luo@freescale.com [zhenhua.luo@freescale.com]
Sent: Tuesday, December 17, 2013 1:41 AM
To: Brad Litterell
Cc: yocto@yoctoproject.org
Subject: RE: Setting PV dynamically in a recipe

AUTOREV might be what you are looking for.

http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-AUTOREV


Best Regards,

Zhenhua

> -----Original Message-----
> From: yocto-bounces@yoctoproject.org [mailto:yocto-
> bounces@yoctoproject.org] On Behalf Of Brad Litterell
> Sent: Tuesday, December 17, 2013 4:17 PM
> To: yocto@yoctoproject.org
> Subject: [yocto] Setting PV dynamically in a recipe
>
> Hi,
>
> I have a few recipes in my image that represent my own custom code.  I
> would like to generate PV dynamically from my source code, but since the
> recipe is parsed before the code is extracted from the tarball, that's
> not easy to do.
>
> The Poky reference manual implies this is possible:
> PV is generally not overridden within a recipe unless it is building an
> unstable (i.e. development) version from a source code repository (e.g.
> Git or Subversion).
>
> However, I have not found an actual example. Is there a recommended way
> to do this?
>
> Thanks,
> Brad
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

Re: Setting PV dynamically in a recipe

[Paul Eggleton]

Hi Brad,

On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> Thank you for the reply.  However, That's not what I'm looking for.  I
> already get the latest version of the source code.
> 
> What I'm really after is the ability to generate output packages that have
> increasing version numbers so I can use the package manager to update them.
> 
> I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> about that variable.

You don't need to use any special classes to get this behaviour. Put this in
your recipe (replacing 1.2.3 with the appropriate base version you are
building):

PV = "1.2.3+git${SRCPV}"

and enable the PR service, which will ensure SRCREV changes always increment
the version properly:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Setting PV dynamically in a recipe

[Brad Litterell]

Hi Paul,

Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.  

In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)

What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:

SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'

or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.

It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).

Any suggestions?

Thanks,
Brad
________________________________________
From: Paul Eggleton [paul.eggleton@linux.intel.com]
Sent: Tuesday, December 17, 2013 12:24 PM
To: Brad Litterell
Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

Hi Brad,

On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> Thank you for the reply.  However, That's not what I'm looking for.  I
> already get the latest version of the source code.
>
> What I'm really after is the ability to generate output packages that have
> increasing version numbers so I can use the package manager to update them.
>
> I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> about that variable.

You don't need to use any special classes to get this behaviour. Put this in
your recipe (replacing 1.2.3 with the appropriate base version you are
building):

PV = "1.2.3+git${SRCPV}"

and enable the PR service, which will ensure SRCREV changes always increment
the version properly:

http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Re: Setting PV dynamically in a recipe

[Martin Jansa]

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

On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> Hi Paul,
> 
> Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.  
> 
> In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> 
> What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> 
> SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> 
> or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> 
> It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> 
> Any suggestions?

Don't use *IMAGE_FEATURES* to in recipe conditionals.

When you're building some package you don't know in which image it will
be included so you cannot know with which *IMAGE_FEATURES* it should be
built.

It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
still it's unsafe to assume they are "global". With improved
base_contains and sstate interaction, using some flag in DISTRO_FEATURES
shouldn't cause so many packages to rebuild, so it could be usable for
"debug-build" flag.

> ________________________________________
> From: Paul Eggleton [paul.eggleton@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
> 
> Hi Brad,
> 
> On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > Thank you for the reply.  However, That's not what I'm looking for.  I
> > already get the latest version of the source code.
> >
> > What I'm really after is the ability to generate output packages that have
> > increasing version numbers so I can use the package manager to update them.
> >
> > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > about that variable.
> 
> You don't need to use any special classes to get this behaviour. Put this in
> your recipe (replacing 1.2.3 with the appropriate base version you are
> building):
> 
> PV = "1.2.3+git${SRCPV}"
> 
> and enable the PR service, which will ensure SRCREV changes always increment
> the version properly:
> 
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

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

Re: Setting PV dynamically in a recipe

[Brad Litterell]

Hi Martin,

I decided just to create my own feature list:

MY_FEATURES="debug"

and I can happily query it in my custom recipes.

However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:

ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)

Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?

Thanks,
Brad
________________________________________
From: Martin Jansa [martin.jansa@gmail.com]
Sent: Wednesday, December 18, 2013 1:36 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> Hi Paul,
>
> Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
>
> In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
>
> What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
>
> SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
>
> or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
>
> It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
>
> Any suggestions?

Don't use *IMAGE_FEATURES* to in recipe conditionals.

When you're building some package you don't know in which image it will
be included so you cannot know with which *IMAGE_FEATURES* it should be
built.

It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
still it's unsafe to assume they are "global". With improved
base_contains and sstate interaction, using some flag in DISTRO_FEATURES
shouldn't cause so many packages to rebuild, so it could be usable for
"debug-build" flag.

> ________________________________________
> From: Paul Eggleton [paul.eggleton@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> Hi Brad,
>
> On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > Thank you for the reply.  However, That's not what I'm looking for.  I
> > already get the latest version of the source code.
> >
> > What I'm really after is the ability to generate output packages that have
> > increasing version numbers so I can use the package manager to update them.
> >
> > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > about that variable.
>
> You don't need to use any special classes to get this behaviour. Put this in
> your recipe (replacing 1.2.3 with the appropriate base version you are
> building):
>
> PV = "1.2.3+git${SRCPV}"
>
> and enable the PR service, which will ensure SRCREV changes always increment
> the version properly:
>
> http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

Re: Setting PV dynamically in a recipe

[Martin Jansa]

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

On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> Hi Martin,
> 
> I decided just to create my own feature list:
> 
> MY_FEATURES="debug"
> 
> and I can happily query it in my custom recipes.
> 
> However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
> 
> ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> 
> Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?

Depends on where you're using MY_FEATURES variable in the recipe, in
most cases it should be included in sstate signature and rebuilt
automatically (with the same version) when MY_FEATURES is changes.

If you're using latest oe-core, that error is QA check, which can be
disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
WARN_QA in distro config.

> ________________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Wednesday, December 18, 2013 1:36 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
> 
> On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > Hi Paul,
> >
> > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> >
> > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> >
> > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> >
> > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> >
> > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> >
> > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> >
> > Any suggestions?
> 
> Don't use *IMAGE_FEATURES* to in recipe conditionals.
> 
> When you're building some package you don't know in which image it will
> be included so you cannot know with which *IMAGE_FEATURES* it should be
> built.
> 
> It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> still it's unsafe to assume they are "global". With improved
> base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> shouldn't cause so many packages to rebuild, so it could be usable for
> "debug-build" flag.
> 
> > ________________________________________
> > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > Sent: Tuesday, December 17, 2013 12:24 PM
> > To: Brad Litterell
> > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > Hi Brad,
> >
> > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > already get the latest version of the source code.
> > >
> > > What I'm really after is the ability to generate output packages that have
> > > increasing version numbers so I can use the package manager to update them.
> > >
> > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > about that variable.
> >
> > You don't need to use any special classes to get this behaviour. Put this in
> > your recipe (replacing 1.2.3 with the appropriate base version you are
> > building):
> >
> > PV = "1.2.3+git${SRCPV}"
> >
> > and enable the PR service, which will ensure SRCREV changes always increment
> > the version properly:
> >
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

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

Re: Setting PV dynamically in a recipe

[Brad Litterell]

I'm using it in a task, like this:
do_install_prepend() {
    if [ ! -z ${ETM_DEBUG} ]; then
...        do debugging stuff   ...
    fi
}

but having it in a task definition doesn't seem to taint the sstate.  Trying to figure out what other variables go into it. E.g. does DESCRIPTION get included in the sstate? (I'd assume not).  Is there a meta-list somewhere of what goes in the state hash?

 _______________________________________
From: Martin Jansa [martin.jansa@gmail.com]
Sent: Friday, December 20, 2013 1:34 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> Hi Martin,
>
> I decided just to create my own feature list:
>
> MY_FEATURES="debug"
>
> and I can happily query it in my custom recipes.
>
> However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
>
> ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
>
> Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?

Depends on where you're using MY_FEATURES variable in the recipe, in
most cases it should be included in sstate signature and rebuilt
automatically (with the same version) when MY_FEATURES is changes.

If you're using latest oe-core, that error is QA check, which can be
disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
WARN_QA in distro config.

> ________________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Wednesday, December 18, 2013 1:36 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > Hi Paul,
> >
> > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> >
> > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> >
> > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> >
> > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> >
> > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> >
> > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> >
> > Any suggestions?
>
> Don't use *IMAGE_FEATURES* to in recipe conditionals.
>
> When you're building some package you don't know in which image it will
> be included so you cannot know with which *IMAGE_FEATURES* it should be
> built.
>
> It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> still it's unsafe to assume they are "global". With improved
> base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> shouldn't cause so many packages to rebuild, so it could be usable for
> "debug-build" flag.
>
> > ________________________________________
> > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > Sent: Tuesday, December 17, 2013 12:24 PM
> > To: Brad Litterell
> > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > Hi Brad,
> >
> > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > already get the latest version of the source code.
> > >
> > > What I'm really after is the ability to generate output packages that have
> > > increasing version numbers so I can use the package manager to update them.
> > >
> > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > about that variable.
> >
> > You don't need to use any special classes to get this behaviour. Put this in
> > your recipe (replacing 1.2.3 with the appropriate base version you are
> > building):
> >
> > PV = "1.2.3+git${SRCPV}"
> >
> > and enable the PR service, which will ensure SRCREV changes always increment
> > the version properly:
> >
> > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> >
> > Cheers,
> > Paul
> >
> > --
> >
> > Paul Eggleton
> > Intel Open Source Technology Centre
> > _______________________________________________
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

Re: Setting PV dynamically in a recipe

[Martin Jansa]

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

On Fri, Dec 20, 2013 at 09:39:13AM +0000, Brad Litterell wrote:
> I'm using it in a task, like this:
> do_install_prepend() {
>     if [ ! -z ${ETM_DEBUG} ]; then
> ...        do debugging stuff   ...
>     fi
> }
> 
> but having it in a task definition doesn't seem to taint the sstate.  Trying to figure out what other variables go into it. E.g. does DESCRIPTION get included in the sstate? (I'd assume not).  Is there a meta-list somewhere of what goes in the state hash?

You can use bitbake-diffsigs command on one of sigdata files from your
recipe to see if the variable is included.

But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
> 
>  _______________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Friday, December 20, 2013 1:34 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
> 
> On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> > Hi Martin,
> >
> > I decided just to create my own feature list:
> >
> > MY_FEATURES="debug"
> >
> > and I can happily query it in my custom recipes.
> >
> > However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
> >
> > ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> >
> > Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?
> 
> Depends on where you're using MY_FEATURES variable in the recipe, in
> most cases it should be included in sstate signature and rebuilt
> automatically (with the same version) when MY_FEATURES is changes.
> 
> If you're using latest oe-core, that error is QA check, which can be
> disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> WARN_QA in distro config.
> 
> > ________________________________________
> > From: Martin Jansa [martin.jansa@gmail.com]
> > Sent: Wednesday, December 18, 2013 1:36 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > > Hi Paul,
> > >
> > > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> > >
> > > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> > >
> > > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> > >
> > > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> > >
> > > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> > >
> > > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> > >
> > > Any suggestions?
> >
> > Don't use *IMAGE_FEATURES* to in recipe conditionals.
> >
> > When you're building some package you don't know in which image it will
> > be included so you cannot know with which *IMAGE_FEATURES* it should be
> > built.
> >
> > It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> > still it's unsafe to assume they are "global". With improved
> > base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> > shouldn't cause so many packages to rebuild, so it could be usable for
> > "debug-build" flag.
> >
> > > ________________________________________
> > > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > > Sent: Tuesday, December 17, 2013 12:24 PM
> > > To: Brad Litterell
> > > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > > Subject: Re: [yocto] Setting PV dynamically in a recipe
> > >
> > > Hi Brad,
> > >
> > > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > > already get the latest version of the source code.
> > > >
> > > > What I'm really after is the ability to generate output packages that have
> > > > increasing version numbers so I can use the package manager to update them.
> > > >
> > > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > > about that variable.
> > >
> > > You don't need to use any special classes to get this behaviour. Put this in
> > > your recipe (replacing 1.2.3 with the appropriate base version you are
> > > building):
> > >
> > > PV = "1.2.3+git${SRCPV}"
> > >
> > > and enable the PR service, which will ensure SRCREV changes always increment
> > > the version properly:
> > >
> > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> > >
> > > Cheers,
> > > Paul
> > >
> > > --
> > >
> > > Paul Eggleton
> > > Intel Open Source Technology Centre
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

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

Re: Setting PV dynamically in a recipe

[Brad Litterell]

I'll have a look at diffsigs.  ${ETM_DEBUG} is the parsed representation of just the debug flag in MY_FEATURES (assuming I'll have more than one flag in MY_FEATURES eventually).  So, in this case, yes they are referring to the same.  Thanks for asking though.

________________________________________
From: Martin Jansa [martin.jansa@gmail.com]
Sent: Friday, December 20, 2013 2:01 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

On Fri, Dec 20, 2013 at 09:39:13AM +0000, Brad Litterell wrote:
> I'm using it in a task, like this:
> do_install_prepend() {
>     if [ ! -z ${ETM_DEBUG} ]; then
> ...        do debugging stuff   ...
>     fi
> }
>
> but having it in a task definition doesn't seem to taint the sstate.  Trying to figure out what other variables go into it. E.g. does DESCRIPTION get included in the sstate? (I'd assume not).  Is there a meta-list somewhere of what goes in the state hash?

You can use bitbake-diffsigs command on one of sigdata files from your
recipe to see if the variable is included.

But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
>
>  _______________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Friday, December 20, 2013 1:34 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> > Hi Martin,
> >
> > I decided just to create my own feature list:
> >
> > MY_FEATURES="debug"
> >
> > and I can happily query it in my custom recipes.
> >
> > However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
> >
> > ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> >
> > Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?
>
> Depends on where you're using MY_FEATURES variable in the recipe, in
> most cases it should be included in sstate signature and rebuilt
> automatically (with the same version) when MY_FEATURES is changes.
>
> If you're using latest oe-core, that error is QA check, which can be
> disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> WARN_QA in distro config.
>
> > ________________________________________
> > From: Martin Jansa [martin.jansa@gmail.com]
> > Sent: Wednesday, December 18, 2013 1:36 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > > Hi Paul,
> > >
> > > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> > >
> > > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> > >
> > > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> > >
> > > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> > >
> > > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> > >
> > > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> > >
> > > Any suggestions?
> >
> > Don't use *IMAGE_FEATURES* to in recipe conditionals.
> >
> > When you're building some package you don't know in which image it will
> > be included so you cannot know with which *IMAGE_FEATURES* it should be
> > built.
> >
> > It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> > still it's unsafe to assume they are "global". With improved
> > base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> > shouldn't cause so many packages to rebuild, so it could be usable for
> > "debug-build" flag.
> >
> > > ________________________________________
> > > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > > Sent: Tuesday, December 17, 2013 12:24 PM
> > > To: Brad Litterell
> > > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > > Subject: Re: [yocto] Setting PV dynamically in a recipe
> > >
> > > Hi Brad,
> > >
> > > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > > already get the latest version of the source code.
> > > >
> > > > What I'm really after is the ability to generate output packages that have
> > > > increasing version numbers so I can use the package manager to update them.
> > > >
> > > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > > about that variable.
> > >
> > > You don't need to use any special classes to get this behaviour. Put this in
> > > your recipe (replacing 1.2.3 with the appropriate base version you are
> > > building):
> > >
> > > PV = "1.2.3+git${SRCPV}"
> > >
> > > and enable the PR service, which will ensure SRCREV changes always increment
> > > the version properly:
> > >
> > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> > >
> > > Cheers,
> > > Paul
> > >
> > > --
> > >
> > > Paul Eggleton
> > > Intel Open Source Technology Centre
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

Re: Setting PV dynamically in a recipe

[Brad Litterell]

Hi again,
Is it possible I don't have sigdata files?

I am trying bitbake-diffsigs -t <recipe> <task>

For recipe, I've tried the package name: "etm-core" & file name "etm-core.bb"  for task, I've tried fetch, configure, compile, install, do_install.

All come back with same message "no sigdata files found matching ...."

Is there a way to list all the possible inputs of sigfiles that exist?

Disclaimer - Yocto 1.3 - possibly known issue?
________________________________________
From: yocto-bounces@yoctoproject.org [yocto-bounces@yoctoproject.org] on behalf of Brad Litterell [brad@evidence.com]
Sent: Friday, December 20, 2013 2:03 AM
To: Martin Jansa
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

I'll have a look at diffsigs.  ${ETM_DEBUG} is the parsed representation of just the debug flag in MY_FEATURES (assuming I'll have more than one flag in MY_FEATURES eventually).  So, in this case, yes they are referring to the same.  Thanks for asking though.

________________________________________
From: Martin Jansa [martin.jansa@gmail.com]
Sent: Friday, December 20, 2013 2:01 AM
To: Brad Litterell
Cc: Paul Eggleton; yocto@yoctoproject.org
Subject: Re: [yocto] Setting PV dynamically in a recipe

On Fri, Dec 20, 2013 at 09:39:13AM +0000, Brad Litterell wrote:
> I'm using it in a task, like this:
> do_install_prepend() {
>     if [ ! -z ${ETM_DEBUG} ]; then
> ...        do debugging stuff   ...
>     fi
> }
>
> but having it in a task definition doesn't seem to taint the sstate.  Trying to figure out what other variables go into it. E.g. does DESCRIPTION get included in the sstate? (I'd assume not).  Is there a meta-list somewhere of what goes in the state hash?

You can use bitbake-diffsigs command on one of sigdata files from your
recipe to see if the variable is included.

But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
>
>  _______________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Friday, December 20, 2013 1:34 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
>
> On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> > Hi Martin,
> >
> > I decided just to create my own feature list:
> >
> > MY_FEATURES="debug"
> >
> > and I can happily query it in my custom recipes.
> >
> > However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
> >
> > ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> >
> > Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?
>
> Depends on where you're using MY_FEATURES variable in the recipe, in
> most cases it should be included in sstate signature and rebuilt
> automatically (with the same version) when MY_FEATURES is changes.
>
> If you're using latest oe-core, that error is QA check, which can be
> disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> WARN_QA in distro config.
>
> > ________________________________________
> > From: Martin Jansa [martin.jansa@gmail.com]
> > Sent: Wednesday, December 18, 2013 1:36 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > > Hi Paul,
> > >
> > > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> > >
> > > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> > >
> > > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> > >
> > > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> > >
> > > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> > >
> > > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> > >
> > > Any suggestions?
> >
> > Don't use *IMAGE_FEATURES* to in recipe conditionals.
> >
> > When you're building some package you don't know in which image it will
> > be included so you cannot know with which *IMAGE_FEATURES* it should be
> > built.
> >
> > It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> > still it's unsafe to assume they are "global". With improved
> > base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> > shouldn't cause so many packages to rebuild, so it could be usable for
> > "debug-build" flag.
> >
> > > ________________________________________
> > > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > > Sent: Tuesday, December 17, 2013 12:24 PM
> > > To: Brad Litterell
> > > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > > Subject: Re: [yocto] Setting PV dynamically in a recipe
> > >
> > > Hi Brad,
> > >
> > > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > > already get the latest version of the source code.
> > > >
> > > > What I'm really after is the ability to generate output packages that have
> > > > increasing version numbers so I can use the package manager to update them.
> > > >
> > > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > > about that variable.
> > >
> > > You don't need to use any special classes to get this behaviour. Put this in
> > > your recipe (replacing 1.2.3 with the appropriate base version you are
> > > building):
> > >
> > > PV = "1.2.3+git${SRCPV}"
> > >
> > > and enable the PR service, which will ensure SRCREV changes always increment
> > > the version properly:
> > >
> > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> > >
> > > Cheers,
> > > Paul
> > >
> > > --
> > >
> > > Paul Eggleton
> > > Intel Open Source Technology Centre
> > > _______________________________________________
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

--
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: Setting PV dynamically in a recipe

[Martin Jansa]

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

On Fri, Dec 20, 2013 at 10:11:43AM +0000, Brad Litterell wrote:
> Hi again,
> Is it possible I don't have sigdata files?
> 
> I am trying bitbake-diffsigs -t <recipe> <task>
> 
> For recipe, I've tried the package name: "etm-core" & file name "etm-core.bb"  for task, I've tried fetch, configure, compile, install, do_install.
> 
> All come back with same message "no sigdata files found matching ...."
> 
> Is there a way to list all the possible inputs of sigfiles that exist?

Try

bitbake -S etm-core

you should find sigdata files in tmp-eglibc/stamps directory after that.

> Disclaimer - Yocto 1.3 - possibly known issue?

My answer about QA check for version going backwards was assuming 1.4 or
newer, if I recall correctly when the change to use QA api for those
warnings was merged.

> ________________________________________
> From: yocto-bounces@yoctoproject.org [yocto-bounces@yoctoproject.org] on behalf of Brad Litterell [brad@evidence.com]
> Sent: Friday, December 20, 2013 2:03 AM
> To: Martin Jansa
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
> 
> I'll have a look at diffsigs.  ${ETM_DEBUG} is the parsed representation of just the debug flag in MY_FEATURES (assuming I'll have more than one flag in MY_FEATURES eventually).  So, in this case, yes they are referring to the same.  Thanks for asking though.
> 
> ________________________________________
> From: Martin Jansa [martin.jansa@gmail.com]
> Sent: Friday, December 20, 2013 2:01 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto@yoctoproject.org
> Subject: Re: [yocto] Setting PV dynamically in a recipe
> 
> On Fri, Dec 20, 2013 at 09:39:13AM +0000, Brad Litterell wrote:
> > I'm using it in a task, like this:
> > do_install_prepend() {
> >     if [ ! -z ${ETM_DEBUG} ]; then
> > ...        do debugging stuff   ...
> >     fi
> > }
> >
> > but having it in a task definition doesn't seem to taint the sstate.  Trying to figure out what other variables go into it. E.g. does DESCRIPTION get included in the sstate? (I'd assume not).  Is there a meta-list somewhere of what goes in the state hash?
> 
> You can use bitbake-diffsigs command on one of sigdata files from your
> recipe to see if the variable is included.
> 
> But here you're showing ETM_DEBUG not MY_FEATURES, is it the same?
> >
> >  _______________________________________
> > From: Martin Jansa [martin.jansa@gmail.com]
> > Sent: Friday, December 20, 2013 1:34 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto@yoctoproject.org
> > Subject: Re: [yocto] Setting PV dynamically in a recipe
> >
> > On Fri, Dec 20, 2013 at 03:09:31AM +0000, Brad Litterell wrote:
> > > Hi Martin,
> > >
> > > I decided just to create my own feature list:
> > >
> > > MY_FEATURES="debug"
> > >
> > > and I can happily query it in my custom recipes.
> > >
> > > However, I haven't quite figured out the best way to taint the status hashes for my packages so that changes to this flag force a rebuild.  I originally tried putting the marking in PR, which works for causing the right things to rebuild, but when I switch from debug to release, I get errors like this:
> > >
> > > ERROR: Package version for package my-config-files went backwards which would break package feeds from (0:2.0.0.0-r0-debug to 0:2.0.0.0-r0)
> > >
> > > Is there a way I can taint my recipes so that changing MY_FEATURES causes them all to be evaluated as out of date.  I don't care if that causes some extra rebuilds when I switch MY_FEATURES - I care more about avoiding the error message.  Or is there a way I can turn off this particular error message on specific recipes?
> >
> > Depends on where you're using MY_FEATURES variable in the recipe, in
> > most cases it should be included in sstate signature and rebuilt
> > automatically (with the same version) when MY_FEATURES is changes.
> >
> > If you're using latest oe-core, that error is QA check, which can be
> > disabled with SKIP_INSANE (per package) or moved from ERROR_QA to
> > WARN_QA in distro config.
> >
> > > ________________________________________
> > > From: Martin Jansa [martin.jansa@gmail.com]
> > > Sent: Wednesday, December 18, 2013 1:36 AM
> > > To: Brad Litterell
> > > Cc: Paul Eggleton; yocto@yoctoproject.org
> > > Subject: Re: [yocto] Setting PV dynamically in a recipe
> > >
> > > On Wed, Dec 18, 2013 at 01:29:25AM +0000, Brad Litterell wrote:
> > > > Hi Paul,
> > > >
> > > > Thanks for that tip.  For my private packages I don't build directly from git, but from a tarball (in turn created from my working directory) because I want to be able to build the source I'm working on without committing it to git.
> > > >
> > > > In an ideal world, I'd like to to be able to build in two modes: dev & release.  Release mode would use the git-based solution (and enforce building from git), and in the dev mode, build from something like externalsrc.  (The reason I don't use externalsrc directly is because it didn't detect changes in the underlying external source, so I created a script that does and updates the tarball.)
> > > >
> > > > What is the best way to switch recipes between dev & test modes like that.  It appears debug-tweaks is only used in image recipes, so I don't know whether I should (or could) use something like this in a package recipe:
> > > >
> > > > SRC_URI += '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweaks", "...tarball...", "...git..."}'
> > > >
> > > > or whether something like that is asking for trouble.  My current solution is manual - edit the recipe, but that feels kinda lame.
> > > >
> > > > It seems like most of the yocto build tools assume building directly from git (or with external-src but without dependency checking).
> > > >
> > > > Any suggestions?
> > >
> > > Don't use *IMAGE_FEATURES* to in recipe conditionals.
> > >
> > > When you're building some package you don't know in which image it will
> > > be included so you cannot know with which *IMAGE_FEATURES* it should be
> > > built.
> > >
> > > It's true that EXTRA_IMAGE_FEATURES are often set in DISTRO config, but
> > > still it's unsafe to assume they are "global". With improved
> > > base_contains and sstate interaction, using some flag in DISTRO_FEATURES
> > > shouldn't cause so many packages to rebuild, so it could be usable for
> > > "debug-build" flag.
> > >
> > > > ________________________________________
> > > > From: Paul Eggleton [paul.eggleton@linux.intel.com]
> > > > Sent: Tuesday, December 17, 2013 12:24 PM
> > > > To: Brad Litterell
> > > > Cc: zhenhua.luo@freescale.com; yocto@yoctoproject.org
> > > > Subject: Re: [yocto] Setting PV dynamically in a recipe
> > > >
> > > > Hi Brad,
> > > >
> > > > On Tuesday 17 December 2013 19:46:11 Brad Litterell wrote:
> > > > > Thank you for the reply.  However, That's not what I'm looking for.  I
> > > > > already get the latest version of the source code.
> > > > >
> > > > > What I'm really after is the ability to generate output packages that have
> > > > > increasing version numbers so I can use the package manager to update them.
> > > > >
> > > > > I think Martin's subsequent reply is the secret to use PKGV.  I didn't know
> > > > > about that variable.
> > > >
> > > > You don't need to use any special classes to get this behaviour. Put this in
> > > > your recipe (replacing 1.2.3 with the appropriate base version you are
> > > > building):
> > > >
> > > > PV = "1.2.3+git${SRCPV}"
> > > >
> > > > and enable the PR service, which will ensure SRCREV changes always increment
> > > > the version properly:
> > > >
> > > > http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#working-with-a-pr-service
> > > >
> > > > Cheers,
> > > > Paul
> > > >
> > > > --
> > > >
> > > > Paul Eggleton
> > > > Intel Open Source Technology Centre
> > > > _______________________________________________
> > > > yocto mailing list
> > > > yocto@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
> > > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

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

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

Re: Setting PV dynamically in a recipe

[Martin Jansa]

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

On Tue, Dec 17, 2013 at 08:16:40AM +0000, Brad Litterell wrote:
> Hi,
> 
> I have a few recipes in my image that represent my own custom code.  I would like to generate PV dynamically from my source code, but since the recipe is parsed before the code is extracted from the tarball, that's not easy to do.
> 
> The Poky reference manual implies this is possible:
> PV is generally not overridden within a recipe unless it is building an unstable (i.e. development) version from a source code repository (e.g. Git or Subversion).
> 
> However, I have not found an actual example. Is there a recommended way to do this?

Do you really need to change PV? Check PKGV,
meta-openembedded/meta-oe/classes/gitpkgv.bbclass could be interesting
example for you.

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

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