Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 10:11:43AM +, Brad Litterell wrote:
> Hi again,
> Is it possible I don't have sigdata files?
>
> I am trying bitbake-diffsigs -t
>
> 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-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on
> behalf of Brad Litterell [b...@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.ja...@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 +, 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.ja...@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 +, 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.ja...@gmail.com]
> > > Sent: Wednesday, December 18, 2013 1:36 AM
> > > To: Brad Litterell
> > > Cc: Paul Eggleton; yocto@yoctoproject.org
> > > S
Re: [yocto] Setting PV dynamically in a recipe
Hi again,
Is it possible I don't have sigdata files?
I am trying bitbake-diffsigs -t
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-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf
of Brad Litterell [b...@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.ja...@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 +, 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.ja...@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 +, 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.ja...@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 +, 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 reas
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.ja...@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 +, 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.ja...@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 +, 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.ja...@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 +, 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.
Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 09:39:13AM +, 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.ja...@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 +, 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.ja...@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 +, 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
> &
Re: [yocto] Setting PV dynamically in a recipe
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.ja...@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 +, 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.ja...@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 +, 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.eggle...@linux.intel.com]
> > Sent: Tuesday, December 17, 2013 12:24 PM
> > To: Brad Litterell
> > Cc: zhenhua@freescale.com; yocto@yoctoproject.org
> > Subject: Re: [yocto
Re: [yocto] Setting PV dynamically in a recipe
On Fri, Dec 20, 2013 at 03:09:31AM +, 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.ja...@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 +, 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.eggle...@linux.intel.com]
> > Sent: Tuesday, December 17, 2013 12:24 PM
> > To: Brad Litterell
> > Cc: zhenhua@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
> > &g
Re: [yocto] Setting PV dynamically in a recipe
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.ja...@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 +, 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.eggle...@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua@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.ja...@gmail.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
On Wed, Dec 18, 2013 at 01:29:25AM +, 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.eggle...@linux.intel.com]
> Sent: Tuesday, December 17, 2013 12:24 PM
> To: Brad Litterell
> Cc: zhenhua@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.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Setting PV dynamically in a recipe
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.eggle...@linux.intel.com]
Sent: Tuesday, December 17, 2013 12:24 PM
To: Brad Litterell
Cc: zhenhua....@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
Re: [yocto] Setting PV dynamically in a recipe
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@freescale.com [zhenhua@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-boun...@yoctoproject.org [mailto:yocto- > boun...@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 > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
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
Re: [yocto] Setting PV dynamically in a recipe
On Tue, Dec 17, 2013 at 08:16:40AM +, 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.ja...@gmail.com signature.asc Description: Digital signature ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 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-boun...@yoctoproject.org [mailto:yocto- > boun...@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 > ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[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
