[yocto] Setting PV dynamically in a recipe

Fri Dec 20 03:26:29 PST 2013

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 at yoctoproject.org [yocto-bounces at yoctoproject.org] on behalf of Brad Litterell [brad at evidence.com]
> Sent: Friday, December 20, 2013 2:03 AM
> To: Martin Jansa
> Cc: Paul Eggleton; yocto at 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 at gmail.com]
> Sent: Friday, December 20, 2013 2:01 AM
> To: Brad Litterell
> Cc: Paul Eggleton; yocto at 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 at gmail.com]
> > Sent: Friday, December 20, 2013 1:34 AM
> > To: Brad Litterell
> > Cc: Paul Eggleton; yocto at 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 at gmail.com]
> > > Sent: Wednesday, December 18, 2013 1:36 AM
> > > To: Brad Litterell
> > > Cc: Paul Eggleton; yocto at 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 at linux.intel.com]
> > > > Sent: Tuesday, December 17, 2013 12:24 PM
> > > > To: Brad Litterell
> > > > Cc: zhenhua.luo at freescale.com; yocto at 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 at yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > --
> > > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> 
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131220/6ad9ecd0/attachment.pgp>