**** BEGIN LOGGING AT Tue May 21 09:33:43 2019 May 21 15:50:48 hi, I have a variable that is calculated from `git describe` across BBPATH, the build directory and the (repo) manifest used to populate the workspace May 21 15:51:18 this variable is assigned as PV to some packages, including packagegroups and images May 21 15:51:53 unfortunatelly, if anything changes on the workspace during the build, the signatures check goes bunkers May 21 15:52:12 s/bunkers/bonkers/ May 21 15:53:23 the variable in question is set on a bbclass via "${@....}" May 21 15:54:30 the most frustrating part is that is no way to recover from this basehash-changed state... not even `-c cleansstate` lets me carry on May 21 15:55:42 any suggestion on how to annotate this variable so it makes bitbake just build the new PV? or not recalculate the variable during the build? May 21 16:05:39 mnemoc: you need two passes here May 21 16:05:54 so have tooling to calculate it first and feed it into yocto metadata May 21 16:08:08 as environment when calling bitbake you mean? May 21 16:09:44 or there is a mechnamism without yocto for this pre-build pass? May 21 16:09:49 within* May 21 16:11:45 the latter .. May 21 16:13:25 khem: any suggestion on what to look at as example (or documentation?) May 21 16:17:06 fundamentally once you invoke bitbake then the metadata should be static until end of build May 21 16:17:24 so any setups you need to do need to happen before or after May 21 16:17:29 for best results May 21 16:17:35 I dont have any open example May 21 16:18:17 I assume you know best the logic your workspace is trying to execute so you probably can comeup with the separation logic May 21 16:21:16 khem: yes, the actual implementation is obviusly on me. i was wondering how to inject the variable into the metadata in a way that doesn't recalculate "accidentally" May 21 16:22:25 with my limited understanding of bitbake I can only think on wrapping `bitbake` and pass the value as an external literal May 21 16:22:38 but I got the impression there is a proper method May 21 16:29:23 and doing it externally I won't have BBPATH so I would need to understand bblayers May 21 16:29:26 :( May 21 16:30:10 you can generate say global conf/site.conf file May 21 16:30:17 externally May 21 16:35:24 how evil would be to generate a $TMPDIR/foo-${DATETIME) file from the distro conf and use it as cache? conf/site.conf surely sounds better than messing with the env, but I would make assumtions about the /user's/ build directory May 21 16:38:11 mnemoc: I always handle this sort of variable by wrapping bitbake, exporting it in the env and adding the variable to BB_ENV_EXTRAWHITE May 21 16:38:31 That way it doesn't get changed after bitbake has been invoked May 21 16:40:02 paulbarker: thanks, i'll bite that bullet May 21 16:43:58 i really really wanted to find a hook somewhere safe but under bitbake's control May 21 16:45:09 mnemoc: You may be able to do this by some magic but it's probably much simpler to just wrap bitbake May 21 16:45:52 very true. I've been three days fighting this thing already May 21 16:49:34 Setting PV dynamically is essentially a huge hassle as the working directory for the build is based on that value May 21 16:50:15 If you really want to go down the 'magic' route you should look into how ${AUTOREV} updates PV safely May 21 16:50:54 paulbarker: great pointer! May 21 16:52:34 Actually, the trick may be that it updates PKGV instead of PV so the workdir path doesn't change May 21 16:56:03 meta-oe/classes/gitpkgv.bbclass might help with that May 21 17:08:30 thanks a lot May 21 17:40:43 using PKGV instead of PV on the packagegroups didn't fix the /non determinism/ of the signature :( **** ENDING LOGGING AT Wed May 22 03:02:00 2019