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-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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
