**** BEGIN LOGGING AT Thu Feb 09 03:00:03 2017 Feb 09 08:52:32 hi Feb 09 08:52:41 genivi git repo is down, right? Feb 09 09:16:08 is this the right place to ask about genivi git repo? Feb 09 09:28:23 ERROR: glibc-2.25-r0 do_package: QA Issue: glibc: Files/directories were installed but not shipped in any package: Feb 09 09:28:45 I was thinking that this is somehow my local issue,, but it's all over autobuilder Feb 09 09:29:35 * RP was pleased to see -next went green at least Feb 09 09:29:42 rburton: mut isn't looking so happy :( Feb 09 10:21:02 RP: rburton: I need to smoketest some changes on the new cluster. Any branches you want tested? Feb 09 10:21:07 rburton: morning. can you merge Kristian's patchset, please? http://lists.openembedded.org/pipermail/openembedded-core/2017-February/132280.html Feb 09 10:24:21 joshuagl: I just have my pending things done. rburton probaby needs more of a hand with mut right now but looks like some things need to be pruned Feb 09 10:24:36 shouldn't I be able to get rid of the dependency of perf to perl and python by controlling PERF_FEATURES_ENABLE in the image recipe? Feb 09 10:25:00 mdnneo: you'd have to set that in your local.conf, not the image recipe Feb 09 10:28:33 RP: hmm ... still the deps get on ... so just set is like PERF_FEATURES_ENABLE = "" in conf/local.conf ... I'm using krogoth since I think there has been some changes in the meantime Feb 09 10:29:12 "8 Feb 09 10:39:19 using krogoth I have an unexpected behavior I didn't had with jethro: bitbake core-image-minimal -c rootfs -f doesn't regenerate the final fs .bz2 but only a .manifest Feb 09 10:39:32 any clue? Feb 09 10:47:53 mdnneo: that should disable them, its possible some of the scripts that are getting installed still have a perl/python interpreter dependency I guess Feb 09 10:48:26 mckoan: I suspect you want -C rootfs which will then rerun the image processing too Feb 09 10:48:50 mckoan: the do_image through to do_image_complete tasks need to run after do_rootfs Feb 09 10:56:49 joshuagl: still need a test branch? Feb 09 10:56:58 RP: yep Feb 09 10:57:14 joshuagl: looking at the mut failures, let me rebase it on master Feb 09 10:57:25 sounds good, thanks RP Feb 09 10:59:40 RP: I think I need to provide some own recipe ... even if i remove the additional packages by adapting the original recipe I cannot get rid of it Feb 09 11:00:10 mdnneo_: have you looked at the logs and checked how its getting configured, see if it is an options issue? Feb 09 11:01:03 joshuagl: rpurdie/mut-rp Feb 09 11:01:14 RP: thanks, I've always used -c rootfs (lowercase) is this a new requirement in krogoth? Feb 09 11:01:16 joshuagl: that should at least avoid the glibc package issue Feb 09 11:02:11 mckoan: around then we split do_rootfs into several different tasks so things did change. You could bitbake -c rootfs -f; bitbake or run the shortcut for that which is bitbake -C rootfs Feb 09 11:02:14 RP: this works: bitbake core-image-minimal -C rootfs Feb 09 11:02:41 RP: thank you Feb 09 11:13:58 RP: thanks, it's away! Feb 09 11:15:48 yeah mut is a bit doomed isn't it Feb 09 11:16:41 rburton: yes, from the glibc thing, sorry. Patch for that is in master now Feb 09 11:18:39 shall rebase and prune now Feb 09 11:19:11 RP: should I expect a different behavior between bitbake -c and bitbake -C (uppercase), is there any documentation about that? Feb 09 11:19:41 Yes it is different behaviour Feb 09 11:20:13 mckoan: does —help not explain the difference? Feb 09 11:20:24 RP: i'll stop mut :) Feb 09 11:22:10 rburton: probably for the best Feb 09 11:22:33 I don't understand, sorry Feb 09 11:24:38 mckoan: have you tried reading "bitbake --help" Feb 09 11:25:28 RP: I was doing that just now. -C INVALIDATE_STAMP Feb 09 11:25:58 RP: the explanation is a pit cryptic but it's fine thatnks Feb 09 11:26:09 s/pit/bit Feb 09 11:36:45 ed2: done Feb 09 11:38:29 rburton: I have a wic testcase failure, is it known? Feb 09 11:38:52 probably not Feb 09 11:38:56 what is it? Feb 09 11:39:27 test_iso_image fails due to python index error Feb 09 11:39:47 ed2: ^ Feb 09 11:41:02 I get the same failure on master, so I conclude it's probably not because of dnf :) Feb 09 11:46:33 kanavin_home: can you give more details on your setup? I usually run oe-selftest -r wic and make sure all tests are passed before submitting patches. Feb 09 11:47:42 ed2: let me first copy paste the failure I am getting Feb 09 11:48:32 kanavin_home: yep, that would help Feb 09 11:50:02 ed2: http://pastebin.com/j31vfHae Feb 09 11:51:41 kanavin_home: which machine do you use? Feb 09 11:53:11 ed2: qemux86 Feb 09 11:53:17 ed2: poky distro Feb 09 11:53:56 kanavin_home: thank you. I'll try to reproduce&fix this. Feb 09 11:55:23 RP: puh ... haven't expected perf to be such a beast ... so at least it looks like the compilation is done correct since there NO_GTK2=1 NO_NEWT=1 NO_DWARF=1 NO_LIBUNWIND=1 NO_LIBDW_DWARF_UNWIND=1 NO_LIBPERL=1 NO_LIBPYTHON=1 NO_LIBNUMA=1 is set but somehow it still get in Feb 09 12:09:56 mdnneo_: right, I wondered as much. I suspect some scripts may use the interpretor even if it doesn't link against perl/python :( Feb 09 12:33:39 rburton: I am going to mention the UEFI/ovmf work in my ELC/OpenIoT Summit presentation. Do you see a chance to get that merged into master by then? I'm not aware of anything holding it back at the moment. Feb 09 12:34:06 i can add it when current mut is stable, sure Feb 09 12:36:14 thanks Feb 09 12:36:34 is there a neat way to store stderr to a shell variable (but let stdout go through as usual)? Feb 09 12:41:05 jku: in shell var="$(command 2>&1 >&2)". This swaps stdout and stderr. The order of the redirect is of importance Feb 09 13:04:59 pohly: the symlink issue fix went in btw Feb 09 13:05:27 RP: okay. It wasn't actually breaking anything for me, I just noticed the warning. Feb 09 13:11:00 pohly: ok, for some reason I thought you have a dependency on it... Feb 09 13:29:07 rburton, joshuagl: any thoughts on https://bugzilla.yoctoproject.org/show_bug.cgi?id=8879 ? Feb 09 13:29:08 Bug 8879: major, Medium+, 2.3 M3, richard.purdie, IN PROGRESS DESIGN , opkg-utils is built when build lib32-image Feb 09 13:46:43 sveinse: thanks that seems it might work. Unfortunately I realised cve-check-tool prints everything to stderr :( Feb 09 14:03:07 any reason why mgu using syslinux and not gummiboot and can someone maybe give me a quick link to the recipe? Feb 09 14:03:28 sry wrong window :D Feb 09 14:04:24 mdnneo: I was going to say, not sure you should be asking that here… Feb 09 14:19:22 RP: hmm, I think I'm in favour of longer build time & simpler maintenance Feb 09 14:24:20 joshuagl: I'm torn, I took that bug mainly to figure out the real problem, now we know what it is, I'm not sure if we want to do anything about it Feb 09 14:26:17 RP: right, I think the confusion & maintenance overhead of a separate update-alternatives probably isn't worth it Feb 09 14:44:14 joshuagl: I've assigned it to rburton since its really a userspace issue now Feb 09 14:44:53 * joshuagl nods Feb 09 14:46:37 There are advantages between using of override mechanism to populate a variable compared to VAR += "blah ${@base_contains('MACHINE', 'nemachine', 'software', '', d)"? Feb 09 14:47:20 neatness Feb 09 14:48:50 rburton: no others advantages? like some more calls to a function or something like that? Feb 09 14:49:25 expanded differently but i doubt you'll ever notice, even if you profile Feb 09 14:49:41 silviof: the native overrides mechanism probably does perform marginally better Feb 09 14:50:23 RP okay thanks. Its not worth to think about? Feb 09 14:50:30 thanks to rburton too :-) Feb 09 14:51:17 silviof: For a one off in a single recipe, very little difference. In bitbake.conf being expanded thousands of times, different story Feb 09 14:52:05 silviof: ${@xxxx} is comparatively slow Feb 09 14:55:01 RP ah okay - good to know. You have helped me. Feb 09 15:07:18 hmm, https://bugzilla.yoctoproject.org/show_bug.cgi?id=11032 is swupdate not swupd Feb 09 15:07:19 Bug 11032: normal, Undecided, ---, joshua.g.lock, NEW , bitbake exits with error related to libubootenv Feb 09 15:23:17 joshuagl: ah, yes, sorry :/ Feb 09 15:23:55 RP: np, I've assigned to sbabic in the interim, probably we'll close it during triage but at least they should receive mail Feb 09 15:51:18 configure: error: getopt is required for building programs Feb 09 15:51:19 whaaaa Feb 09 16:40:46 RP: dnf is delayed to 2.4? Feb 09 16:41:55 kanavin_home: i had to AR to ping you, but the bug call just finished. Feb 09 16:42:33 kanavin_home: we're close to M3 which is the deadline for features, so unless you're incredibly close to pushing a series for review it won't make it. can't land features in M4. Feb 09 16:42:49 rburton: I have two oe-selftest failures left, so it's a close call Feb 09 16:43:15 rburton: when those are resolved, i will at the same time publish the work, and ask you to run it through on the AB Feb 09 16:43:28 sure Feb 09 16:43:40 if it just sneaked into m3 then that's great Feb 09 16:43:46 if it doesn't make 2.3, it really needs to make 2.4 right away.. Feb 09 16:43:48 if the AB explodes in a galactical manner, then it's off to 2.4 I guess Feb 09 16:43:57 I'm slightly worried about 2.3 and not having enough time to stabilize it.. Feb 09 16:44:14 (It would be nice to get it checked in, even as a branch to 2.3) so it can be worked on in parallel.. Feb 09 16:44:35 MIPS issues and other non x86 things are my biggest worry from the reviews I've done Feb 09 16:45:21 exactly - its a big change Feb 09 16:45:23 kanavin, if needed we may be able to put it into our autobuilder (for the Fall release) Feb 09 16:45:43 fray: that would be great. i've heard big things about your cluster Feb 09 16:45:50 fray: not yet, but when the patches show up in oe-core list, please do Feb 09 16:46:27 rburton, we're not currently running a lot of Fall 2017 builds yet.. but should begin doing more then a small number in the near future.. Feb 09 16:46:39 we ramp down the previous year and up for the next year usually.. Feb 09 16:46:40 one of the outstanding issues is that multilib is broken :) so I don't want people to bug me about it :) Feb 09 16:46:54 ya, multilib is a big deal for us.. Feb 09 16:46:57 ha Feb 09 16:46:59 (our next release will be Fall 2017) Feb 09 16:47:07 its always WR moaning about multilib ;) Feb 09 16:47:20 thats because no-multilib and our customers will -scream- Feb 09 16:47:47 ARM64 multilib has become a big issues recently.. and we're still finding problems with the currently implementation.. (usually on-target or SDK toolchains recently..) hopefully patches soon for thats tuff.. Feb 09 16:47:59 otherwise it's mostly x86 with a bit of PPC thrown in.. Feb 09 16:48:09 fray: there is some amount of testing for multilib in oe-selftest, and it fails Feb 09 16:48:11 (mips multilib is still being tested by us, but it's definitely fallen away) Feb 09 16:48:54 kanavin_home: We were very worried seeing it targeting M4. If we can make M3 with it, I'm prepared to give that a go Feb 09 16:49:23 RP: it was just me forgetting that such major things cannot go in M4 time - I set it that way to give myself breathing space more than anything Feb 09 16:50:19 kanavin_home: we can set it to M3 and then push to 2.4 if we don't make it? Feb 09 16:50:32 RP: sure, yes Feb 09 16:54:43 fray: just a couple further points about things we argued over: a) rpm4 does not fail when a postinst scriptlet fails and it does continue with other packages, so scriptlet failures can be processed after the fact. I've tested these scenarios and they work; b) the chroot thing is now conditional, so on target it will happen as expected Feb 09 16:54:56 fray: all that is available from the usual branch if you want to take a look Feb 09 17:01:06 rburton: I think the locale failures are not probably due to my patch Feb 09 17:01:35 rburton: I could see that locale packages are empty on another machine which was running ubuntu 16.04 Feb 09 17:01:40 using master Feb 09 17:01:55 khem: i think the bad failures where a bad patch from RP, fixed in master now. Feb 09 17:02:11 ah ok Feb 09 17:02:12 khem: just fired a mut to check Feb 09 17:03:54 ok Feb 09 17:04:04 khem: yes, the sstate glibc-locale patch wasn't quite right Feb 09 17:04:23 no worries Feb 09 17:13:59 kanavin_home (back now) re the scriptlet.. did you check the RPM return code? and the DNF return codes.. often the install will "complete" with a non-zero return code, and it will end up skipping things Feb 09 17:14:17 but even so how do you know which post install scriptlets to stage for later? Feb 09 17:15:48 fray: dnf fails if preinst scriptlets fail, but doesn't fail if postinst scriptlets fail Feb 09 17:16:10 fray: rpm clearly prints which of the scriptlets failed, and the name of the package, so that's easy to parse from the output Feb 09 17:16:13 we have a few but not many preinst.. but the wrapper does work with them as well Feb 09 17:16:36 we do not want to parse RPM output, trust me.. it's going to fail over and over if we do.. it has to be automatic and we ignore the output for any longer term sanity Feb 09 17:16:53 fray: in any case, that is deprecated behavior. if you want to defer to first boot, put stuff in postinst_ontarget() Feb 09 17:16:58 (originally we parsed the rpm commands output, it kept breaking.. we'd fix one corner case and the next would break) Feb 09 17:17:09 fray: yeah, but in this case it is easy Feb 09 17:17:35 fray: it's not even rpm printing this, it's dnf, so I can patch it to output exactly what we want to parse Feb 09 17:17:37 what is postinst_ontarget do? Remember this stuff has to work for on-target upgrades as well, not just initial rootfs gen Feb 09 17:17:48 I still wouldn't trust it.. Feb 09 17:18:09 I've just seen that type of processing break too many times (for more then just simple log parsing) Feb 09 17:18:34 (log processing as in, look for warnings and errors and display them to the user.. but not process what they mean) Feb 09 17:18:54 fray: in a phone meeting now, back in a bit Feb 09 17:19:30 ok Feb 09 17:20:38 fray: http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/dnf-rpm4&id=e3de61cdd66889ef9e2a3025185cf8dea2ab21bb Feb 09 17:20:58 ok.. I'll try to find some time to play with it.. (likely next week at this rate) Feb 09 17:31:20 RP: finally we fixed the NFS stale handle issue Feb 09 17:31:27 RP: I sent the patch to bb ml Feb 09 17:31:50 for past 1 months no more NFS stale issues are observed so I am confident of the fix Feb 09 17:32:11 khem: I was going to ask about that, can you explain a bit more about what is actually happening? Feb 09 17:32:24 khem: why would we hit that error? Feb 09 17:34:40 STALE handle error was being passed by kernel but not handled Feb 09 17:35:08 we have sstate cache on a nfs server which maps back into build nodes Feb 09 17:35:29 but then we do run cache management scripts which delete old ununsed sstate Feb 09 17:35:36 on server Feb 09 17:35:57 so NFS was still holding the stale file handles Feb 09 17:36:15 in our 3000 odd daily builds Feb 09 17:36:52 ya, when I hit the locking problem, I noticed a bunch of places that we probably should be trying to catch specific IOErrors in bitbake... but never had the time to figure out if it was completely necessary or not.. Feb 09 17:37:09 (there were places where exceptions just triggered a retry -- unlimited) Feb 09 17:37:26 might be something to further look at improving in 2.4 Feb 09 17:38:30 there were 10 odd failures seen with python backtrace due to stale NFS handle Feb 09 17:38:50 we just need to catch the exception and ignore it Feb 09 17:38:59 so system can go ahead and rebuild the package Feb 09 17:40:17 khem: oh hey Feb 09 17:40:41 is there a way to build multilib aarch64/armv7 toolchain ? Feb 09 17:41:21 my attempts thus far ended up with a toolchain which has two environment setup scripts, but both make the compiler (32bit or 64bit respectively) point to aarch64 sysroot, which makes the 32bit compilation fail Feb 09 17:41:36 Marex, as far as we can tell it won't work.. Feb 09 17:41:42 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#combining-multiple-versions-library-files-into-one-image I saw this about zilion times ... Feb 09 17:42:02 fray: ok, so what's the way to do things ? I can try bitbake lib32-meta-toolchain maybe ? Feb 09 17:42:03 the compiler doesn't have the support for it (that is probably prety easy to fix), but the SDK/target side there are confliccts in the glibc headers.. Feb 09 17:42:21 we can build a multilib system using it, but currently we need two different SDKs, one 32-bit and one 64-bit Feb 09 17:42:32 fray: well I don't mind two different SDKs :) Feb 09 17:42:45 fray: how do I get the 32bit one out of it though ? Feb 09 17:42:46 (we've spent the past month working through the problems for YP 2.2, hopefully soon we'll have something we can send back and forward port to 2.3 Feb 09 17:43:00 temporarily change the DEFAULTTUNE when buildin the SDK Feb 09 17:43:34 so no way to get both SDKs from single build ? Feb 09 17:43:51 I don't know of an easy way -today-... but it's coming.. Feb 09 17:44:00 (I hope) Feb 09 17:44:03 so what about lib32-meta-toolchain ? Feb 09 17:44:07 what is that for ? Feb 09 17:44:37 the real problem with all of this is that the toolchain (and glibc) treat arm and aarch64 as two completely different architectures.. it's not like x86 or PPC or even MIPS, where it's one architecture with different word size and ABI Feb 09 17:44:52 ah Feb 09 17:45:12 so on the gcc side it's just an issue of getting the right multilib config file.. but glibc there are two completely incompatible header groups.. (we used to have that problem on x86, but I helped fix it there) Feb 09 17:45:19 we're working on the same fixes for the combo right now.. Feb 09 17:45:30 (I have an internal code review in progress now) Feb 09 17:45:56 one we port to YP 2.2, then we'll forward port to 2.3 (master).... doesn't fix the gcc side, but does fix the glibc mess Feb 09 17:46:07 great :) Feb 09 17:57:24 fray: so uh, can I work around this header issue by building the lib32-meta-toolchain or am I doing it wrong ? Feb 09 18:11:51 fray: I guess your work is not available anywhere so I could try , right ? Feb 09 18:12:42 unfortunately not.. the work I have right now is based back on Jethro 2.0, and even that isn't completed.. Feb 09 18:12:57 (we had a customer find the issue on 2.0 based YP system, so that is where we started working on it..) Feb 09 18:19:03 fray: ah right, corporate open-source :) Feb 09 18:19:30 * Marex goes implement his own custom solution then Feb 09 18:29:37 we're not 'hiding anything', fix just isn't working yet Feb 09 18:29:59 one it is then, we'll post it to the OE list, then it gets released to the customer.. Feb 09 18:42:50 Marex: aarch64 gcc backend is not set for multilib Feb 09 18:43:04 Marex: so we need effectively two compilers Feb 09 18:47:31 khem: that's fine, that's what I get when I enable multilib on aarch64 Feb 09 18:48:04 khem: but it seems the env setup script for the armv7a compiler is still pointing to the aarch64 sysroot (and armv7a sysroot is not installed in the toolchain) Feb 09 18:48:33 I mean, SDKTARGETSYSROOT is pointing to the aarch64 sysroot in both 32bit and 64bit case Feb 09 18:55:47 hmm yeah that wont work without some surgery Feb 09 18:56:01 especially with some conflicting headers Feb 09 18:56:09 most of them will work though Feb 09 18:56:13 khem: well, with two sysroots, it should, right ? Feb 09 18:56:29 with two separate sysroots yes no problem Feb 09 18:56:55 although I am not sure if we have SDKs set for that Feb 09 18:57:36 okay, python distuyils package Feb 09 18:57:46 *distutils even Feb 09 18:58:37 currently has a sed hack in compile pre-end to replace hard-coded lib paths wth STAGING_blah paths Feb 09 18:59:40 and bbclassextend=native but it fails in non-native trying to link against the wrong sysroot libs Feb 09 19:00:51 i guess i'm looking for the "proper" fix approach... Feb 09 19:01:01 as if there is one... Feb 09 19:14:18 khem: let's see :) Feb 09 19:27:19 nerdboy: if you find a way to do a 'proper' fix you're welcome Feb 09 19:27:35 nerdboy: no one in YP likes that hack, but no one has any better ideas either Feb 09 19:27:59 silly upstream and their platform detection/blah blah... Feb 09 19:28:49 sed hacks aren't evil per se, as long as it actually works Feb 09 19:29:19 although they do tend to break on trivial upstream changes Feb 09 19:29:26 nerdboy: I'd rather avoid using sed, because it can be hard to decipher the change it's making, and *why* Feb 09 19:29:48 that all depends on the hack Feb 09 19:29:52 far better to take the trouble of proper patching Feb 09 19:30:11 some are clear/clean-ish, others are not so clear... Feb 09 19:31:01 it's often basically write only code Feb 09 19:31:52 in this case it's pretty obvious what it's doing, it just doesn't work on morty Feb 09 20:00:14 anyone building for armv5? Feb 09 20:03:06 denix: we're not, but ooi, what Cortex version does that correspond to? Feb 09 20:03:50 sveinse: none, cortex starts with armv7 Feb 09 20:03:59 right Feb 09 20:06:40 denix: or no, armv6 is also cortex iirc. But not armv5. Google tells me XScale is armv5[te]. Feb 09 20:08:51 sveinse: cortex-m0/1? that's mcu, not a real processor... Feb 09 20:10:12 denix: uhm, with all due respect I strongly disagree that m0/1 is not a "real processor", but yeah, an mcu.. :P Feb 09 21:28:54 denix: armv6 is not cortex Feb 09 21:29:12 its one generation behind that Feb 09 21:30:14 well IMO they are all processors, denix seems to be implying processor = cpu + mmu Feb 09 21:31:36 xscale is armv5tej to be precise Feb 09 21:33:05 cortex-m0/m1 did use armv6 let me take that one back Feb 09 22:18:22 Dear all, Feb 09 22:18:32 Can somebody point me to what is going out with: Feb 09 22:18:40 Computing transaction...error: Can't install kernel-devsrc-1.0-r0@XXX: no package provides /bin/awk Feb 09 22:18:52 lukma: theres a patch for that Feb 09 22:19:15 aehs29_ where can I find it? Feb 09 22:19:39 lukma: its basically looking for /bin/awk when it should be looking for /usr/bin/awk or something Feb 09 22:20:00 yes, exactly Feb 09 22:20:20 but I'm not so "expert" in OE recipies to find it at hand Feb 09 22:20:39 sau! sent a patch in the last week or two to change the path. Feb 09 22:20:48 lukma: it depends on your KMACHINE but here it is http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-4.9/commit/?h=standard/base&id=087b65ddac049813eef2513c4440cb1d02971357 Feb 09 22:21:23 lukma: you may just need to update your SRCREVs so you get the latest kernel Feb 09 22:23:33 The problem is that I'm using my own meta layer (with linux-yocto-custom) Feb 09 22:23:57 So this is with the kernel recipie Feb 09 22:26:15 and now the penny drops .... Feb 09 22:26:35 I do need to prepare patch to my kernel recipe to add it at yocto build :) Feb 09 22:26:44 I would never thought about that without you :) Feb 09 22:26:48 thanks guys Feb 09 22:27:17 khem: thanks for the info, I think I've worked out why I was a little confused Feb 09 22:37:16 lukma: no prob Feb 09 22:47:50 RP: hi there. I have indeed an issue with klcc-cross when it is rebuilt from sstate. I.e. build qemuarm , wipe tmpdir, build for say spitz. Feb 09 22:47:59 then the infamous error configure: error: C compiler cannot create executables Feb 09 22:48:16 http://pastebin.com/zhmCtUK0 Feb 09 22:51:20 cclean it and rebuild it then the recipe does configure/compile fine Feb 10 00:16:25 RP: no problem, this issue has been discussed several times on ml Feb 10 00:54:59 Hi, I was wondering if anyone can tell me if there is a way to get a listing of the dependency tree for a recipe, including versions, from within the recipe itself, similar to what you get when you run "bitbake -g recipe-name"? Feb 10 00:58:42 Basically, I want to create an image release manifest that documents exactly what went into it Feb 10 01:02:05 Or should I just use bitbake -g and process the dot files? Feb 10 01:05:00 As far as I can tell, to do the latter, I'd need to actually parse the task-depends.dot for the version numbers. The other files don't contain the info Feb 10 01:37:24 pwebster: image manifest is already generated for you **** ENDING LOGGING AT Fri Feb 10 03:00:01 2017