From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id 37D25E00809 for ; Fri, 20 Dec 2013 03:25:57 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so995337eaj.40 for ; Fri, 20 Dec 2013 03:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=VBWrDRafpjtJRd5URADk/7K1Ze6VOOif7iSLRDak8J0=; b=sFt52h762ld5QTXeJN0L7shc00yJLqx7rSYa86FvoGvlVkg0goSsq810praQgKdQGJ 2GwwlF/AWfRQt78nhzeH8Ik2eKmAlP2qlx0SXemerLmVZMf4SXC8yLjXjoy88dinW5K6 Z33LSCbAT/+CkTyfdXLVFaRpxg4XVsTIY9JiljGfBWR/75XVaSZWiDWbUBAo0/JiPx0l Mm4iyWod2HX/2OJ8XUJjI7GzFr5fbu2fkNLBK2Bquxw/GE4R5upf5Q29iOfwDS80duUE 6Z3qMvoaG8GuFiKKtnBX9sn7TK98ikUT1SKT1lw/zq9MpVheNSXwMfrOjkQtwYpNcWkp mqtw== X-Received: by 10.14.204.135 with SMTP id h7mr2186611eeo.104.1387538756706; Fri, 20 Dec 2013 03:25:56 -0800 (PST) Received: from localhost (ip-89-176-104-107.net.upcbroadband.cz. [89.176.104.107]) by mx.google.com with ESMTPSA id l4sm17688254een.13.2013.12.20.03.25.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Dec 2013 03:25:55 -0800 (PST) Date: Fri, 20 Dec 2013 12:26:29 +0100 From: Martin Jansa To: Brad Litterell Message-ID: <20131220112629.GT3706@jama> References: <14453943.1Qpn4azGq8@helios> <20131218093624.GK3706@jama> <20131220093433.GQ3706@jama> <20131220100106.GS3706@jama> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Paul Eggleton , "yocto@yoctoproject.org" Subject: Re: Setting PV dynamically in a recipe X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 11:26:02 -0000 X-Groupsio-MsgNum: 17607 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HACzHn9G0kmbdSJa" Content-Disposition: inline --HACzHn9G0kmbdSJa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 20, 2013 at 10:11:43AM +0000, Brad Litterell wrote: > Hi again, > Is it possible I don't have sigdata files? >=20 > I am trying bitbake-diffsigs -t >=20 > For recipe, I've tried the package name: "etm-core" & file name "etm-core= =2Ebb" for task, I've tried fetch, configure, compile, install, do_install. >=20 > All come back with same message "no sigdata files found matching ...." >=20 > 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 >=20 > 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 fla= g in MY_FEATURES eventually). So, in this case, yes they are referring to = the same. Thanks for asking though. >=20 > ________________________________________ > 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 >=20 > 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. T= rying 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 somewhe= re of what goes in the state hash? >=20 > You can use bitbake-diffsigs command on one of sigdata files from your > recipe to see if the variable is included. >=20 > 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=3D"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 or= iginally 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 l= ike this: > > > > > > ERROR: Package version for package my-config-files went backwards whi= ch 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 ca= uses 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 directl= y 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 commit= ting it to git. > > > > > > > > In an ideal world, I'd like to to be able to build in two modes: de= v & release. Release mode would use the git-based solution (and enforce bu= ilding from git), and in the dev mode, build from something like externalsr= c. (The reason I don't use externalsrc directly is because it didn't detec= t changes in the underlying external source, so I created a script that doe= s and updates the tarball.) > > > > > > > > What is the best way to switch recipes between dev & test modes lik= e 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 recip= e: > > > > > > > > SRC_URI +=3D '${@base_contains("EXTRA_IMAGE_FEATURES", "debug-tweak= s", "...tarball...", "...git..."}' > > > > > > > > or whether something like that is asking for trouble. My current s= olution is manual - edit the recipe, but that feels kinda lame. > > > > > > > > It seems like most of the yocto build tools assume building directl= y 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 wi= ll > > > 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, b= ut > > > still it's unsafe to assume they are "global". With improved > > > base_contains and sstate interaction, using some flag in DISTRO_FEATU= RES > > > 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 fo= r. 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 up= date them. > > > > > > > > > > I think Martin's subsequent reply is the secret to use PKGV. I d= idn't know > > > > > about that variable. > > > > > > > > You don't need to use any special classes to get this behaviour. Pu= t this in > > > > your recipe (replacing 1.2.3 with the appropriate base version you = are > > > > building): > > > > > > > > PV =3D "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 >=20 > -- > Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto --=20 Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com --HACzHn9G0kmbdSJa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlK0KWUACgkQN1Ujt2V2gBxmAwCfTSk0uVZBHm3Eu+OiGJkuLZ9d QioAoItmA59TUem0kRrhUawnIDbjy04s =dn75 -----END PGP SIGNATURE----- --HACzHn9G0kmbdSJa--