**** BEGIN LOGGING AT Thu Sep 12 02:59:59 2013 Sep 12 06:33:40 What's that command which prints all tasks? Sep 12 06:47:34 ps aux ? Sep 12 06:59:52 no, not Linux.. bitbake/oe Sep 12 07:17:38 bitbake -clisttasks target Sep 12 07:17:55 or 'bitbake -n target' - depends what you want to achieve Sep 12 07:32:56 hrw, neither.. it was bitbake -e. Sep 12 07:37:10 good morning Sep 12 07:41:34 kbart: bitbake -e is "print environment" Sep 12 07:46:37 hrw, yes I have read manpage of bitbake few times, somehow failed to realize that "print environment" is what I'm looking for. Sep 12 07:54:41 hi. is it possible to find the sstate checksum for a specific task/recipe? i tried bitbake-diffsigs -t qtbase fetch, but it tells me "No sigdata files found matching qtbase fetch" Sep 12 07:55:42 bitbake -S isn't it? Sep 12 07:57:23 rburton: oh boy... we learn every day ;-) Sep 12 08:01:00 rburton: hmm. that doesn't display anything at all. Sep 12 08:01:31 is it going into a log file? Sep 12 08:04:10 ndec: re the bitbake-diffsigs command, I think you want do_fetch not fetch there Sep 12 08:04:40 ndec: it writes the sigdata files Sep 12 08:04:53 in sstate folder? Sep 12 08:05:22 my initial problem was to locate the right sigdata in sstate folder for a given recipe/task. i should have started by that. Sep 12 08:05:31 morning all, hi bluelightning , hi mckoan Sep 12 08:05:44 as i wanted to understand why things got rebuilt, why i wasn't expecting that. Sep 12 08:06:01 ndec: i always forget, diffsigs is incredibly useful but the learning curve to remembering how it works is tough Sep 12 08:06:32 well, if it's tough for you, imagine for me;-) Sep 12 08:08:16 bluelightning: thanks. i had tried do_fetch, but now i understand, it's because there was no do_fetch task in my case. but do_package gave me nice results. Sep 12 10:10:00 Crofton: ping Sep 12 11:30:28 pong Sep 12 14:26:40 afternoon all Sep 12 14:27:20 I'm a little bit confused as to why I have libgcc in my toolchain created with -c populate_sdk, but I don't have it in my actual image sysroot Sep 12 14:27:54 s/sysroot/target rootfs Sep 12 14:29:52 I imagine it's because nothing on the target uses it, so it was never linked into the image, however is it valid that this does not also apply for the toolchain...? Sep 12 17:52:27 by default, does the new OE keep logs of what it did? in classic, under work, there is a detail log of the compiles, etc. that doesn't seem to be there anymore Sep 12 17:56:02 ds2: absolutely; AFAIK it should be in more or less the same place as well (TMPDIR/work////temp/) Sep 12 17:56:56 let me look in temp Sep 12 17:57:27 thanks. found it. **** ENDING LOGGING AT Fri Sep 13 02:59:58 2013