**** BEGIN LOGGING AT Fri Jun 10 02:59:59 2016 Jun 10 09:38:07 hi Jun 10 09:42:19 <_taw_> perl_5.22 from yocto/2.0.2 fails in packaging, arm-objcopy tries to extract sections from ptest/generate_uudmap which is ELF 64-bit LSB Jun 10 09:42:30 <_taw_> http://pastebin.com/XKcHTXNv Jun 10 12:51:30 i'm having _superweird_ behavior with my buildtree. I build my kernel (linux-xlnx): bitbake linux-xlnx. I modify the source-code and force rebuild: bitbake -f -c compile linux-xlnx .. it takes forever, does not seem to be an incremental build but my changes to source remains. I then proceed to deploy it: bitbake linux-xlnx (yes, i know I can just do -c deploy) and it recompiles AGAIN (runs do_compile). Why does Jun 10 12:51:32 not the sstate cache kick in here? I've successfully done this kind of iterative kernel hacking before, it's even in the OE kernel manual. What am I doing wrong here? Jun 10 13:20:53 mago__: using externalsrc or just a normal build? Jun 10 13:34:11 bluelightning: normal build Jun 10 13:38:47 hmm, when I havea recipe with a non anonymous python function that does something at some point, is it possible to run this function only for certain configurations? similar to do_install_append_armv5() ? Jun 10 13:39:16 Jin^eLD: no, but you can have the function check the value of variables and conditionally do things Jun 10 13:39:44 I found armv5 onlyas part of TUNE_FEATURES andI wasnot sureif I should rely on that variable Jun 10 13:40:08 I have two arm5 platforms that would match and I didnotwant to listthem specifically by checking $MACHINE Jun 10 13:40:12 Jin^eLD: you should be able to Jun 10 13:40:16 mago__: I'm not sure, I wouldn't expect it to behave like that either Jun 10 13:40:31 thanks Jun 10 13:40:58 bluelightning: is it possible to print the bitbake status of the sstate cache for a certain recipe? Jun 10 13:43:03 mago__: not really, but you can do bitbake -s printdiff linux-xlnx to have it tell you why it thinks it should re-run the tasks it's rerunning Jun 10 13:44:33 bluelightning:btw I havea similar problem with oneof my packages and printdiff did not work out for me that well, it told me there is a hash mismatch; I could narrow it down to my do_deploy task but so far I as not able to find which variable exactly caused the rebuilds Jun 10 13:45:11 sorry for the typos, broken space and slow connection ;) Jun 10 13:45:49 Jin^eLD: DATETIME included in DISTRO_VERSION or anything else? Jun 10 13:46:22 I was looking for that but did not seem like it, its actually a kernel recipe that gets rebuilt every time for me Jun 10 13:46:30 and it happens only with that one ackage Jun 10 13:47:07 there must be something special about it :D Jun 10 13:47:10 I do assume its some variable nesting where onethats not vardepsexcluded sneaks in,but I am not sure how to find it.. Jun 10 13:47:22 can you pastebin / otherwise show me the recipe? Jun 10 13:47:43 actually, if you could email it that would be ideal, I really need to get some sleep Jun 10 13:48:09 g'night Jun 10 13:48:15 what's your addy? Jun 10 13:48:18 sure, thank you! Jun 10 13:48:19 gnight! Jun 10 21:17:20 <_taw_> what is ptest, why is needed? Jun 10 21:17:59 <_taw_> had to turn it off to fix this problem http://pastebin.com/XKcHTXNv Jun 10 21:20:10 https://wiki.yoctoproject.org/wiki/Ptest Jun 10 21:21:09 damn, this is odd, cmpi-bindings-native is picking up my host python 3 rather than the python 2.7 in the sysroot, even when i export PYTHON_EXECUTABLE to the correct value. I've examine the .cmake files involved, and they all obey PYTHON_EXECUTABLE, so wher ethe hell is 3 coming from? Jun 10 21:25:21 any folks around that know cmake? Jun 10 21:30:27 ...and willing to admit to it? ;-) Jun 10 21:33:28 that'd help, yes :) Jun 10 21:33:57 think i got it, though. cmpi-bindings didn't follow the recommendations of the cmake docs, which indicate you should find PythonInterp before PythonLibs to ensure consistent version handling Jun 10 21:34:06 without that, it didn't obey our PYTHON_EXECUTABLE Jun 10 21:54:31 * paulg hopes he'll be able to look into why meta-overc gets 64 bit py3 in /usr/lib instead of /usr/lib64 this weekend... Jun 10 21:54:42 probably multilib fallout. Jun 10 22:36:24 khem, around? **** ENDING LOGGING AT Sat Jun 11 02:59:58 2016