**** BEGIN LOGGING AT Thu Aug 13 02:59:59 2015 Aug 13 06:17:13 khem: regarding my toolchain issue from yesterday, any idea where I should start to dig? Aug 13 06:17:17 good morning :) Aug 13 06:18:15 gm Aug 13 06:18:26 explain it to me Aug 13 06:18:36 how did you generate the SDK Aug 13 06:18:43 and how are you using it Aug 13 06:22:39 I've created my own image to compile for Jetson TK1, using a meta-jetson-tk1 layer I found online. I have a toolchain recipe that for now just requires recipes-core/meta/meta-toolchain.bb. That toolchain only contains arm-poky-linux-gnueabi-*, and I suspect I should have had arm-poky-linux-gnueabihf-* Aug 13 06:23:53 Both sdk and rootfs have ld-linux-armhf.so.3, but a binary compiled with the toochain looks for ld-linux.so.3 instead Aug 13 06:24:12 I suspect that is because my sdk does not support hard float Aug 13 06:25:18 I'm working with Dizzy/1.7.2 Aug 13 06:31:23 meta-jetson-tk1 from my github ? Aug 13 06:31:36 since thats most uptodate with OE master Aug 13 06:32:27 in OE we dont do the debian way where they change the target triplet Aug 13 06:32:43 so linux-gnueabihf is non issue Aug 13 06:33:33 khem`: ok. what is your github? I've been using https://github.com/cubicool/meta-jetson-tk1 Aug 13 06:33:47 thats old Aug 13 06:33:47 found it :) Aug 13 06:34:01 so do you have to use dizzy ? Aug 13 06:34:16 if you used my github layer you could use 1.8 or even master Aug 13 06:34:23 and this issue would go away Aug 13 06:34:25 no, that was just because the cubicool layer was old :) Aug 13 06:34:55 I'll switch to 1.8 and your layer and recompile. Aug 13 06:35:02 OK Aug 13 06:35:20 So is it a previously known issue? Aug 13 06:35:24 whats the app that you compile with the SDK Aug 13 06:35:40 Just a simple hello world written in C Aug 13 06:35:43 sometimes Apps have weird makefiles Aug 13 06:35:47 ah ok Aug 13 06:39:01 see http://paste.ubuntu.com/12069106/ Aug 13 06:39:14 thats jetson SDK generated by me Aug 13 06:39:32 its using angstrom master Aug 13 06:39:37 everything is good Aug 13 06:40:45 jetson is a supposted BSP layer with angstrom Aug 13 06:41:14 khem`: that decides the Q I was going to ask :) Aug 13 06:41:47 we used angstrom on the previous product, and now I was considering if I should use that again. Aug 13 06:44:02 by all means Aug 13 06:44:53 its the only opensource yocto compatible distro Aug 13 06:46:01 khem`: that decides it then, and my workday is filled :) Aug 13 06:46:31 good luck Aug 13 06:47:05 khem`: do you use the setup-scripts? Aug 13 06:48:23 no I use repo manifest Aug 13 06:48:45 https://github.com/Angstrom-distribution/angstrom-manifest Aug 13 06:49:09 khem`: great. that is my current poison as well. Aug 13 06:49:11 you can build angstrom-v2015.06-yocto1.8 Aug 13 06:49:20 using manifests Aug 13 06:49:33 final Q. which command do you use for generating the Jetson SDK? Aug 13 06:49:33 angstrom has moved to using repo Aug 13 06:49:50 yeah. noticed there was no 1.8 in the setup script Aug 13 06:49:52 it depends as to what your target is Aug 13 06:49:52 s Aug 13 06:50:03 I do bitbake -cpopulate_sdk systemd-image Aug 13 06:50:39 what is your end target ? Aug 13 06:50:46 is it an app ? Aug 13 06:50:51 that was what I was after. I've always been bitbaking a meta-toolchain recipe. Aug 13 06:51:21 no. an embedded system where I must provide both rootfs and applications Aug 13 06:54:20 should probably create my own fork if I want to add my own layer. I could not phrase that as a Q, since I claimed the last was the final :) Aug 13 06:55:40 well usually you are welcome to folk it on github Aug 13 06:55:44 its easy Aug 13 06:56:11 many folks do that Aug 13 06:56:59 khem`: ymmd! "welcome to folk it on github" Aug 13 06:57:09 :) Aug 13 06:57:43 perhaps I should put on some "fork music" Aug 13 06:58:05 damn thick fingers Aug 13 06:59:21 c'mon, you're not the stereotype 300lbs hacker. Aug 13 07:00:01 it depends on keyboard Aug 13 07:00:15 you have a 300lbs keyboard?!? Aug 13 07:06:53 bit by bit trolls take my sanity away Aug 13 07:07:53 me->sleep() Aug 13 07:08:09 gn8 Aug 13 07:17:03 so, what is a sane starting point for a powerful command-line image in angstrom? Aug 13 08:16:59 morning all Aug 13 08:18:19 gm Aug 13 08:18:30 I'm on the way to cccamp15 Aug 13 08:19:59 Crofton: hey... I saw on FB that you were in Europe Aug 13 08:20:07 hope you have a good time :) Aug 13 08:21:40 Great time, should have stayed in Austria :) but need some form of work to spend my company funds Aug 13 08:50:49 nrossi, gm Aug 13 08:55:12 morning Crofton Aug 13 08:56:08 and fray read my mind about explaing the gplv2 background Aug 13 09:02:56 Crofton: any Dolomites climbing this time? Aug 13 09:05:39 just Austrian climbing Aug 13 09:12:52 this sommer was special: 0° C at 5.000 mt Aug 13 09:13:04 I bet there are any glaciers anymore Aug 13 09:13:33 eek.. summer (get used to german btw) Aug 13 09:51:02 I'm trying to add my layer to the angstrom manifest, but it does not checkout the branch I want. I have created a branch called angstrom-v2015.06-yocto1.8 in my layer, but it still checks out master. Aug 13 10:00:13 eh. not that odd, since that is what the manifest specifies.. Aug 13 11:23:25 is "bitbake -cpopulate_sdk my-image-name" the preferred way to create an sdk? Aug 13 11:34:13 tasslehoff: AFAIK yes. Aug 13 12:01:14 tasslehoff: yes Aug 13 12:01:52 great. then I won't have to fiddle with my toolchain recipes anymore :) Aug 13 12:04:59 that's the idea :) Aug 13 12:20:47 tasslehoff, I've had very good luck with populate_sdk Aug 13 12:23:37 :) Aug 13 12:23:48 seems my luck will hold as well Aug 13 12:24:31 I come from the past. I've been stuck on 1.4 on our old product. Aug 13 12:29:41 It is always good to keep an eye on current work Aug 13 12:30:13 Crofton: nah. that was just depressing when I knew I could not use it ;) Aug 13 16:07:34 rburton: did you get some build results with glibc 2.22 on AB Aug 13 16:07:58 khem: it appeared to build mostly fine but sanity testing totally broke with something unrelated Aug 13 16:19:39 rburton: ok Aug 13 16:19:56 for my interest is there any errors.yp.org link ? Aug 13 16:20:31 I also need a run with gcc5 + glibc2.22 when AB allows Aug 13 16:20:31 nothing failed to build Aug 13 16:20:35 totally Aug 13 16:20:44 that matches my results :) Aug 13 16:20:47 on OE-Core Aug 13 16:21:30 we had few issues reported with gcc5 on x86/x86_64 which should also be fixed with 2.22 Aug 13 16:21:41 so a run with gcc5 would be nice too Aug 13 18:41:20 fray, thanks for answering my question twice, once before I asked it Aug 13 18:44:49 * fray notes he wasn't fully awake this morning, so the typo's are pretty aweful.. and apparently my 'r' wasn't always working.. ;) Aug 13 18:46:26 what was the question Aug 13 18:47:06 GPLv2 stuff Aug 13 18:50:58 ah Aug 13 18:51:14 you had some helpful input Aug 13 18:51:20 about why it will not bitrit Aug 13 18:51:23 bitrot Aug 13 18:51:39 I mention that too, Aug 13 18:51:43 we use it at work Aug 13 18:51:43 yeah Aug 13 18:51:57 and if something breaks we inform or provide patch Aug 13 18:52:00 eitherway Aug 13 18:52:14 The mention of Poky about made me fall on the floor doubled over in laughter Aug 13 18:52:29 ya.. our guys (WR) have been dealing with security issues with the GPLv2 versions as well.. so it shouldn't be a big deal as far as that is concerned either Aug 13 18:52:33 I also sell it as a unique proposition so it had to live well whereever it is in OE-Core or separate layer doesnt matter Aug 13 18:52:35 btw I am at cccamp15 this weekend Aug 13 18:52:40 right Aug 13 18:52:58 the key thing is we revisit the concept from time to time Aug 13 18:53:03 Crofton: bikinh ? Aug 13 18:53:19 last week was for fun Aug 13 18:53:25 the gnutls stuff that has popped up recently is the one thing I might have to do something about.. Aug 13 18:53:26 this week is sort of work Aug 13 18:53:51 witht he one thing it requires (gmp) needing an LGPLv3 version.. I may have to see if I can get an older version of gmp to keep gnutls as LGPLv2+ Aug 13 18:54:17 souds fun Aug 13 18:54:20 (but I need to look at our usage of gnutls a bit more to see if it's really an issue) Aug 13 18:54:26 older gmp is no big deal though.. Aug 13 18:54:28 I'm glad people are dealing with the issues :) Aug 13 18:55:24 GPLv3 doesn't annoy me nearly as much as LGPLv3.. that is just infectious to the point it makes doing seeming normal things very difficult Aug 13 18:56:17 whew, I think I'm finally happy with the usage of the git shallow tarball support i'm working on. it's opt-in, per-url, with a single url parameter which can specify the depth either as an integer (how many commits behind SRCREV to keep) or a ref or commit hash, to keep everything up to that, and all commits *after* SRCREV on the branch= are removed as well Aug 13 18:56:42 e.g. in a bsp kernel one could set ;shallow=v3.14 to remove the history that came from kernel.org, but keep the bsp-specific branch commits Aug 13 18:57:09 I haven't yet encoded that information in the tarball filename, though Aug 13 18:57:14 just revision/branch there atm Aug 13 18:57:42 hmmmm Aug 13 19:36:05 gmp 6.0 onwards is dual licences Aug 13 19:36:28 I thought someone was saying it was (library wise) LGPLv3+.. maybe I'm wrong? Aug 13 19:36:50 I hope you are let me check Aug 13 19:37:30 Since version 6, GMP is distributed under the dual licenses, GNU LGPL v3 and GNU GPL v2 Aug 13 19:37:42 ya.. thats the problem.. Aug 13 19:37:50 LGPLv3..... Aug 13 19:37:59 or is it saying the -library- is LGPLv3 or GPLv2? Aug 13 19:38:14 you can choose Aug 13 19:38:26 GPLv2 is compatible with LGPLv3 Aug 13 19:38:28 yes, that is better.. not perfect but better Aug 13 19:38:42 still ends up contaminating things like gnutls... Aug 13 19:39:59 just dont use it Aug 13 19:40:10 use OpenSSL or libressl's TLS impl Aug 13 19:40:26 ya.. there were a few things at one point where gnutls was required.. no OpenSSL compatibility existed.. Aug 13 19:40:31 but I'd MUCH rather use openssl.. Aug 13 19:41:00 openssl also has advertisement clause do you know that Aug 13 19:41:19 Much like "intel Inside" you have to say "this product runs openssl" Aug 13 19:41:26 music is optional Aug 13 19:41:56 I've never heard of any objections to the advertising clause Aug 13 19:42:30 its easy to miss out Aug 13 19:42:34 from compliance Aug 13 19:43:27 and that also makes it incompatible with GPL Aug 13 19:44:26 yup.. but luckily I'm not usually worried about GPL when it comes to encryption.. I'm usually more worried about other things.. proprietary or linkage as a library.. Aug 13 19:45:26 GPL --apps-- that is.. Aug 13 19:45:37 the apps are concerned though usually with GPL in the encryption side Aug 13 19:49:51 isn't openssl going to remove the advertising clause? Aug 13 19:49:54 (eventually) Aug 13 19:50:48 dunno Aug 13 19:51:47 my primary concern for OpenSSL is the FIPS module.. Aug 13 19:51:59 makes FIPS certification much nicer.. :) Aug 13 19:52:37 kernel question. I want to add a firmware to the kernel. the firmware binary is generated by the kernel makefiles out of a .hex file that is included in the kernel. Aug 13 19:53:03 however, I cannot just specify "firmware" as the directory, because then it will look in the work-shared directory. but there is only an .ihex file. Aug 13 19:53:10 the work directory does have the .bin Aug 13 19:53:37 libressl is probably more promising Aug 13 19:53:37 poky/build/tmp/work-shared/cubox-i/kernel-source/firmware/imx/sdma/sdma-imx6q.bin.ihex vs. poky/build/tmp/work/cubox_i-poky-linux-gnueabi/linux-cubox-i/3.14.44-r0/build/firmware/imx/sdma/sdma-imx6q.bin Aug 13 19:53:58 khem` I actually find libressl (so far) less promising.. Aug 13 19:54:02 how can I make the build process pick the correct path without manually adding it in menuconfig? Aug 13 19:54:07 a lot of hand waving, a lot of complaining.. but not a lot of useful development Aug 13 19:54:08 (I am using fido) Aug 13 19:54:29 I also don't expect libressl to do any FIPS certification or similar Aug 13 19:57:05 well if openbsd can use it and morover a security component in openbsd Aug 13 19:57:12 it must be good Aug 13 19:57:40 I don't believe that.. :) Aug 13 19:57:49 I agree it's probably not "bad".. :) but good is subjective.. Aug 13 19:59:13 fact that google also forked their own boringssl Aug 13 19:59:29 there must be something fundamentally wrong with openssl Aug 13 19:59:37 google for better or worse has a history of forking.. so I don't put a lot of credence in that either.. Aug 13 20:00:00 there was a problem w/ openssl, but I don't consider it technical.. it was structural.. and everything I've seen they've fixed that and now the technical work is getting better due to it.. Aug 13 20:00:23 time will tell Aug 13 20:00:33 the problem w/ openssl for a long time is they had lots of users and very little "support".. suddenly something went wrong and the immediate reaction wasn't to fix the problems.. but to fork it because of governance issues.. Aug 13 20:00:45 once the governance was fixed.. it's hard to go back from the fork in some cases.. Aug 13 20:01:02 it still it a blackhole development model Aug 13 20:01:17 OpenBSD has a history of not playing nice with others.. (which is their perogative) but doesn't help me.. Aug 13 20:01:28 Hmm, I haven't seen that int he least 6 months or so.. Aug 13 20:01:38 patches go in and I see them get merged or rejected with comments.. Aug 13 20:01:44 much less blackholing then before.. Aug 13 20:02:05 OpenBSD is the most conservative BSD distro Aug 13 20:02:17 yes and no.. Aug 13 20:02:27 and security is their top prio Aug 13 20:02:31 they're conservative when it comes to configurations, but far from it when they don't get their own way Aug 13 20:02:41 if they don't get their way they fork and ignore.. Aug 13 20:02:47 I don't call that 'conservative'.. Aug 13 20:04:16 I dont really care what they do but I was stating their goals Aug 13 20:04:47 I don't disagree with their goals.. I just have disagreements with how they go about it.. but not my problem.. :) Aug 13 20:05:24 I still would like to use BSD 'tools' (open, free, net...) witha Linux kernel to build a 'GNU-less' system.. Aug 13 20:05:30 but I've never had the time to prototype it Aug 13 20:09:28 i've thought about that too Aug 13 20:09:30 would be interesting Aug 13 20:11:02 ya.. the biggest problem I see for a 'usable' system is the GNU extensions.. I'm curious how many are really used a lot and what it would take to re-implement them Aug 13 20:18:02 a rm that supports -rf anywhere is a basic human right Aug 13 20:18:16 it still takes me two goes to delete a file on my mac Aug 13 20:19:47 and also treat wifi access along side fundamental rights like food, clothing and shelter Aug 13 20:20:36 lol Aug 13 20:21:20 rburton 'er? (on my mac) Aug 13 20:21:20 bash-3.2$ mkdir foo Aug 13 20:21:21 bash-3.2$ touch foo/bar Aug 13 20:21:25 bash-3.2$ /bin/rm -rf foo Aug 13 20:21:25 bash-3.2$ Aug 13 20:21:28 what isn't working? Aug 13 20:21:40 rm foo -rf Aug 13 20:21:43 wont Aug 13 20:21:54 nice.. Aug 13 20:22:01 where as on gnu coreutils it will Aug 13 20:22:03 I rarely use that order.. but ya.. that should work Aug 13 20:22:06 yeah, my muscle memory says rm foo -rf Aug 13 20:22:23 ohh I always learned command, options, args :) Aug 13 20:22:34 $ rm foo -rf Aug 13 20:22:34 rm: foo: is a directory Aug 13 20:22:34 rm: -rf: No such file or directory Aug 13 20:22:37 STAB STAB STAB Aug 13 20:22:52 see, just doing the cleanup of that example, and guess what happened? Aug 13 20:22:54 I DID IT AGAIN Aug 13 20:23:05 you still can install coreutils on mac Aug 13 20:23:08 yeah i have it Aug 13 20:23:23 but i was too scared to get it to be the system binaries in case it breaks Aug 13 20:23:38 bsd find is also useless Aug 13 20:24:29 ya, I know BSD find is an issue.. I replaced find.. ;) Aug 13 20:24:53 all tools suck some suck less Aug 13 20:25:00 challange is to find which ones Aug 13 20:25:10 those are Aug 13 20:27:30 man of the things (like the option/arg order) I could live w/.. find thought probably not Aug 13 20:27:39 (live with on a Linux system w/ the goal of no GNU) Aug 13 20:28:04 well.. may no GNU isn't the right term.. no GNU in the primary tools.. ;) Aug 13 20:28:17 then we can call it Linux/BSD and miss off both Theo and Richard Aug 13 20:28:28 s/m/p Aug 13 20:29:10 primarily no-gpl in userspace was a big sell of android Aug 13 20:29:29 ya.. google (OHA) and their members basically said no GNU... Aug 13 20:29:39 GPL was a secondary benefit.. but FSF/GNU was a big concern for them Aug 13 20:29:45 (due to GPLv3) Aug 13 20:30:07 I have clang+musl+toybox+linux kernel going Aug 13 20:30:12 so step by step Aug 13 20:30:20 :) Aug 13 20:35:52 rburton: not sure about bash, but on zsh you can set up a keybind which pulls up the previous command and puts the cursor before hte first argument Aug 13 20:35:54 quite handy Aug 14 01:42:33 hello Aug 14 01:44:44 i have a problem with bitbake generating images with outdated packages. Aug 14 01:45:02 in a recipe, ive specified SRC_URI = "some git repo" and SRCREV = "AUTOINC" Aug 14 01:45:31 now my assumption would have been that if i update the branch specified in SRC_URI, that the next time i bitbake an image, the image would contain the latest revision on that branch ("AUTOINC") Aug 14 01:45:36 this is not the case Aug 14 01:45:46 how do i begin to debug this? Aug 14 01:48:40 do i need to mark the recipe "nostamp" ? Aug 14 01:48:48 for AUTOINC to do the right thing? Aug 14 01:58:33 edmund: most likely you didn't add the appropriate bits to the version of the recipe Aug 14 01:58:43 setting srcrev alone won't cause the automatic rebuilds of it at this time Aug 14 01:58:56 set PV to something like 1.0+git${SRCPV} (assuming it's based on 1.0) Aug 14 01:59:03 interesting ok Aug 14 01:59:14 i was just lookinga t something like that, now another question: Aug 14 01:59:14 srcpv is a generated version string appropriate for the binary packages which comes from SRCREV Aug 14 01:59:46 so SRVPV contains the git hash somehow? Aug 14 01:59:47 e.g. it adds an automatically incrementing number, so package upgrades work as new commits are added.. you can't just compare a git commit hash and know which is newer :) Aug 14 01:59:52 and then PV is included in the default stamp? Aug 14 01:59:53 yep Aug 14 01:59:56 yep Aug 14 01:59:59 cool another Q Aug 14 02:00:04 im looking at /edison-tmp/stamps/core2-32-poky-linux/pin-controller Aug 14 02:00:09 where pin-controller is my outdated package Aug 14 02:00:20 i dont see a task that looks like "git" or "fetch"? Aug 14 02:01:01 id really like to see the stamp for the git-fetch task so i can confirm that something's wrong now, and that when your suggestion fixes it i can see how.. :) Aug 14 02:01:44 the stamp will just be named by recipe name / version / checksum. it won't tell you anything about the checksum Aug 14 02:02:01 there should be a stamp for the do_fetch task, however Aug 14 02:02:24 10.2-r0.do_build.2712be9293aff96638be13b43c5eb43b Aug 14 02:02:24 0.2-r0.do_packagedata_setscene.3ed3953507cc84c7c3a551948f80d137.edison Aug 14 02:02:24 0.2-r0.do_package_qa_setscene.2b24ed2512759af5cc8ad0971271053e Aug 14 02:02:24 0.2-r0.do_package_write_ipk_setscene.99dcaac319d5797bcab191831ae79cc1 Aug 14 02:02:24 0.2-r0.do_populate_lic_setscene.a8400d5202f2421c072ddf2608a6077c Aug 14 02:02:26 0.2-r0.do_populate_sysroot_setscene.89cb9b747c73b827caf5c0e7893e81a0.edison Aug 14 02:02:31 er, ignore the leading 1 Aug 14 02:02:35 there's no *fetch* task Aug 14 02:04:20 it didn't need to fetch Aug 14 02:04:25 the recipe was built from sstate, the binary cache Aug 14 02:04:32 it wasn't built from scratch at all Aug 14 02:04:34 hmmm Aug 14 02:04:42 when it comes from the cache, there's no need to fetch sources, since it's not building sources Aug 14 02:04:44 oh, that makes sense Aug 14 02:04:54 so this is related to another problem ive been having Aug 14 02:04:58 bitbake -C fetch yourrecipe will force a build from scratch Aug 14 02:05:18 it's likely that it's pulling the old cache, and isn't rebuilding from scratch when you want, because SRCPV isn't in PV. Aug 14 02:05:28 without that, bitbake doesn't realize that a change to SRCREV should force a re-run of do_fetch Aug 14 02:05:41 (debatable whether that's good behavior, folks have argued it should regardless of PV) Aug 14 02:05:54 it's a little unexpected Aug 14 02:06:52 it can be useful to examine the siginfo/sigdata files, either those in the STAMPS_DIR or those in SSTATE_DIR Aug 14 02:07:02 that has the details about what went into the metadata checksum for the task Aug 14 02:07:13 bitbake-dumpsig will dump the info from the siginfo/sigdata file Aug 14 02:07:29 see also bitbake-diffsigs, also bitbake -C printdiff and bitbake-whatchanged Aug 14 02:07:40 oh, that's exactly what i want to lok at Aug 14 02:08:12 er, bitbake -S printdiff, not -C Aug 14 02:13:24 just found out the difference between .= and += :c Aug 14 02:14:21 heh :) that space is important at times Aug 14 02:14:33 0.2+gitAUTOINC+4ae27f6a01-r0.do_fetch.sigdata.6e0786d84739fc2fd2843fe78edf20ef Aug 14 02:14:34 huzzah Aug 14 02:14:52 kergoth: the space introduced by += caused a git command to fail with "too many args" :) Aug 14 02:15:03 some insufficient escaping somewhere. Aug 14 02:15:13 when i did PV += Aug 14 02:15:51 ah, yes, spaces aren't allowed in PV Aug 14 02:22:27 cool, package got updated in the image Aug 14 02:22:39 one more Q Aug 14 02:22:49 im poking at the sigdata files like you suggested Aug 14 02:23:24 the do_fetch file (decoded with bitbake-dumpsig) doesn't make a mention of PV Aug 14 02:23:32 uhhh, what would the toplevel task be called Aug 14 02:25:11 there's a do_build stamp (but no sigdata) Aug 14 02:26:42 do_build doesn't actually do anything, it's just the default task, a placeholder. it depends on the tasks that do the real work Aug 14 02:27:49 oh Aug 14 02:38:39 so poking around the dep graph generated by bitbake -g .. Aug 14 02:38:40 "edison-image.do_rootfs" -> "pin-controller.do_packagedata" Aug 14 02:38:43 "edison-image.do_rootfs" -> "pin-controller.do_package_write_ipk" Aug 14 02:40:04 "pin-controller.do_package" -> "glibc.do_packagedata" Aug 14 02:41:33 "pin-controller.do_package" -> "pin-controller.do_install" Aug 14 02:41:41 "pin-controller.do_install" -> "pin-controller.do_compile" Aug 14 02:41:56 "pin-controller.do_compile" -> "pin-controller.do_configure" Aug 14 02:42:57 yep. don't paste it all here, though. don't want to spam the channel Aug 14 02:43:16 sorry, got it Aug 14 02:43:55 you can also examine the metadata for the inter-task dependencies in a recipe by looking for the addtask lines, e.g. in base.bbclass Aug 14 02:44:02 the last thing i was going to say is that the sigdata for pincontroller/do_configure contains PV, which contains SRCPV, which is "AUTOINC+4ae27f6a01" Aug 14 02:47:42 oh aha, base.bbclass is pretty much the sequence i pasted above :) Aug 14 02:48:22 yep **** ENDING LOGGING AT Fri Aug 14 02:59:58 2015