**** BEGIN LOGGING AT Fri Jun 03 02:59:58 2016 Jun 03 08:09:59 hello, i wanted to check if any package can put a device based on inactivity Jun 03 12:45:45 hmm,I have a recipe which is always recompiled even if no changes have occured; I assume that I am using some variable somewhere in some nested way where evaluation prevents bitbake from caching it, how would I figure out which one it is? Jun 03 13:04:55 Jin^eLD: bitbake -S printdiff Jun 03 13:06:12 thank you! let me see whatit does Jun 03 13:36:52 rburton: I figured it shows me the package and the task where the hash has changed, but can I narrow it down any further? Jun 03 13:37:30 can I somehow detect which variable influences the has change? Jun 03 15:24:41 "FATAL: The knotty ui could not load the required curses python module." Jun 03 15:24:47 ...and that module would be... ? Jun 03 15:26:04 D'OH! python3-curses Jun 03 15:26:34 welcome to flag day :-D Jun 03 15:37:14 anyone seeing lots of "ResourceWarning: unclosed file " while parsing the recipes? Jun 03 15:37:50 JaMa: python 3 thing. code doing open(foo) and never closing it Jun 03 15:37:55 change it to use with Jun 03 15:38:03 or whatever is appropriate Jun 03 15:41:28 kergoth: I'm more wondering from where it came, if it's some our bbclass or something still missing in public layers Jun 03 15:42:21 yeah, seems most layers are still playing catchup. not sure how to isolate that to where that file was opened Jun 03 15:43:15 JaMa: i'm doing a very basic core-image-minimal build of poky and not seeing any of those warnings Jun 03 15:45:00 Jin|away: printdiff shows down to the variable level. Jun 03 18:25:10 kergoth: hmm, does not look like it here.. Jun 03 18:25:40 that generally indicates either it's comparing against sstate rather than stamps and the intermediate artifacts are missing, or something else odd is going on Jun 03 18:26:17 i'd suggest pointing SSTATE_DIR to an empty dir, emptying SSTATE_MIRRORS to be safe, doing a bitbake -S none yourtarget, then doign a bitbake -S printdiff yourtarget Jun 03 18:26:29 then we know for sure it's comparing against the sigdata in the stamps dir from the first -S Jun 03 18:26:46 ERROR: Bitbake's cached basehash does not match the one we just generated (/home/jin/dss-oe/yocto/dS/meta-digitalstrom-devel/recipes-kernel/linux/linux-astralix_4.1.19.bb.do_deploy)! Jun 03 18:26:51 -S tells you why sstate isn't being used, usually, but it can also be used to see what's changed since your previous build Jun 03 18:26:55 ERROR: The mismatched hashes were ec1cac042439724ace1f7db7c6693489 and 61da68dcd9d540252426884d7ac2c489 Jun 03 18:27:06 thats what it told me now (did not clean anything yet) Jun 03 18:27:15 a base hash mismatch *usually* means someone used a var that's changing on every parse, i.e. DATE/TIME Jun 03 18:27:22 the right answer in that case is usually to exclude it from the vardeps Jun 03 18:27:38 bitbake should really dump more useful info about basehash mismatches at some point.. Jun 03 18:28:15 kergoth: well.. I am trying to find that var :) that was my original question - what means are there to find it... Jun 03 18:28:53 I am actually pretty sure its a var somewhere which is used in another var and then somehow it changes the hash Jun 03 18:29:44 printdiff is usually useful to diagnose things like this, but i'm not sure it can help with a basehash mismatch. RP would be able to say for sure Jun 03 18:29:51 i'd suggest directly examining the sstate files in question Jun 03 18:30:15 you can still try a printdiff the way i suggested, but if taht doesnt' work, try dumping it directly Jun 03 18:30:26 bitbake-dumpsig on the linux-astralix do_deploy sigdata/siginfo in tmp/stamps/ Jun 03 18:30:28 hmm ok, thank you Jun 03 18:30:44 so you can see exactly what vars were included in its signature data Jun 03 18:35:46 Hmm. ^C a bitbake, then ^Z it during the shutdown, resume, and it gets really unhappy that the server completed its shutdown while it was suspended :) Jun 03 18:36:56 while porting opkg-utils to python3, I used python-future for completeness, as it defines an object module that has next(), (http://stackoverflow.com/questions/36517648/in-python-why-import-object-from-builtins-module) Jun 03 18:37:26 however, my change failed the ATS since OE/bitbake doesn't use the python-future module (it is not installed) Jun 03 18:37:45 any reason for that? should I just stop relying on python-future? Jun 03 18:38:07 from looking at the other code migrated, I think the answer is yes.....but wanted to confirm Jun 03 18:38:23 i don't understand the problem. if you want to use it, just make the opkg-utils-native recipe depend on the module it needs, as with every other module it needs Jun 03 18:38:32 otherwise yes, avoid its use, it's entirely your call Jun 03 18:38:51 opkg-utils is run out of the sysroot, so its dependencies can be trivially built by bitbake, no? Jun 03 18:39:28 kergoth: so, yes, you are correct, I am missing the RDEPENDS, but I think the larger question was...should I bother using pyhon-future or maybe is overkill? Jun 03 18:40:39 that depends entirely on your goals with the project. if you want to keep python 2 compatibility, you'll have to adapt to such differences, either manually, with future, or six or equivalent to maintain a single codebase that works with both, or rely on setuptools to do 2to3/3to2. not familiar enough with that particular issue (object next) to say beyond that. maybe someone else in here is Jun 03 18:40:49 or you could just go ask in #python or something Jun 03 18:41:04 bitbake is python3 only, so unless you're going that route too, it has entirely different requirements Jun 03 18:42:32 ok, cool, yeah.....I am thinking I will probably keep compatibility for a while, then do python3 only in a future release Jun 03 18:42:33 thanks Jun 03 18:42:39 np Jun 03 18:52:45 grr, python-futures is on meta-oe, not on oe-core Jun 03 18:54:51 i'm sure you could make an argument to change that Jun 03 18:55:52 yeah, as we move to python3, I doubt I am going to be the only one using futures Jun 03 18:59:09 to move recipes, is it common practice to directly post the patches to both lists or to post the suggested change on an email to both ml's first? Jun 03 19:00:31 I'll probably start the discussion by replying to Purdie's email with the ATS failure Jun 03 19:05:23 acutually nv, I was looking at python-futures (concurrent futures libs), which is different than python-future **** ENDING LOGGING AT Sat Jun 04 02:59:58 2016