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-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 +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.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 +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.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 +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.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
> >
> > --
> > Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
>
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
> _______________________________________________
> 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
