**** BEGIN LOGGING AT Thu Jul 20 03:00:02 2017 Jul 20 08:53:06 hello Jul 20 08:53:22 is there a meta-intel-iss yocto layer publically available? Jul 20 08:53:30 Does anyone know where to report bug or feature request for meta-qt5? Jul 20 08:54:13 qtcreator requires the python json module for GDB scripting Jul 20 08:54:31 and meta-qt5 doesn't include python-json in it's SDK Jul 20 08:55:44 robsta: Wha't the 'iss' for in meta-intel-iss? Jul 20 08:59:12 Intel System Studio Jul 20 08:59:38 it has kernel drivers for profiling tools Jul 20 09:54:04 Son_Goku: yes, I'll try to do it Jul 20 09:54:33 Son_Goku: that kind of thing tends to end up last on the priority list for most of us, unfortunately Jul 20 11:41:29 kanavin: that's not good Jul 20 11:41:41 it should be one of the *first* things you do, rather than *last* Jul 20 11:42:20 a lot of people have a poor attitude of you guys because you always say things like "Upstream Status: Pending" and whatnot and never do it Jul 20 11:45:30 Son_Goku: on one hand, there are always more pressing issues for us. On the other, sending even a trivial patch upstream is a lot of work that does not get rewarded or recognized, and may end up in an energy-sapping argument with the upstream maintainers. Between those things, it ends up low on priorities list. You cannot change this basic effort vs. reward situation, certainly not by saying that this is "not good". Jul 20 11:45:49 Son_Goku: that said, I'm creating pull requests for rpm/dnf patches right now Jul 20 11:45:59 as well as librepo? Jul 20 11:46:05 Son_Goku: yes Jul 20 11:46:10 kanavin: all I ask is that the PRs be made Jul 20 11:46:18 whether they fail is another problem altogether Jul 20 11:46:32 it doesn't look good if not even the most *basic* effort isn't taken Jul 20 11:46:48 Son_Goku: if you care about this, do help us out :) Jul 20 11:47:10 I have "stolen" a few of your patches in the past and upstreamed them :) Jul 20 11:47:26 why do you think your patchset for rpm 4.13 isn't as big as when you had rpm4 before :) Jul 20 11:49:21 thanks :) everyone would appreciate this more than you simply getting upset about our priorities :) Jul 20 11:50:33 kanavin: what I'm upset about is spending weeks trying to fix a problem in something, only to find out in my quarterly crawl of your stuff that someone fixed it quite a while back... Jul 20 11:51:40 What happens after I email patches to oe-core or or-devel? Should I see some emails back about them or anything? Do they just sit in some people's inboxes for a while until they look important enough to get examined in detail? Jul 20 11:52:27 TafThorne: they quietly get pulled into the patch queue by ross or RP, if something fail you will hear about it, if nothing fails, you will eventually see them in master Jul 20 11:52:50 TafThorne: I understand this is not great for keeping you informed, but at the moment it's like this Jul 20 11:53:27 kanavin: Thanks. I just wanted to know if I should have seen any status updates about them. If they are probably working their way through the pile/queue that is fine. Jul 20 11:54:00 TafThorne: you can watch for the patches in the master-next and poky-contrib/ross/mut branches Jul 20 11:55:04 Son_Goku: libcomps/rpm/dnf/createrepo_c/libdnf done Jul 20 11:55:20 Son_Goku: so that leaves librepo I guess, which I'll do now Jul 20 11:55:28 awesome Jul 20 11:55:49 kanavin: one of the reasons I prefer you do it is so that authorship can be preserved Jul 20 11:56:04 and it improves the general view of Yocto with the outside world Jul 20 11:56:15 you feel very much like Debian (in a bad way) right now Jul 20 11:56:37 RP: I'll try to have a look in there sometime. Jul 20 11:57:23 Son_Goku: I should probably have used my linux.intel.com address then, or otherwise made sure this is coming from Yocto Jul 20 11:57:40 Son_Goku: I tend not to pay too much attention to what email those patches have, could be gmail Jul 20 11:58:54 Debian does something similar where their dumbass DEP-8 headers for patches are supposed to indicate upstreaming, and they rarely forward changes even though Policy says they should Jul 20 11:59:08 Son_Goku: you can totally preserve authorship if you use 'git am' to apply someone else's patches Jul 20 11:59:16 I'm aware Jul 20 11:59:26 but sometimes, people just make patches with gendiff or git diff :( Jul 20 11:59:30 and it sucks Jul 20 12:00:16 Son_Goku: all of *my* patches are made with git :) you're right that Yocto does have a few of those though Jul 20 12:23:52 Son_Goku: the state of Pending patches is known to be bad, personally i'm rejecting some patches where pushing upstream is trivial and obvious, and WR have been doing good work recently of trawling through recipes and submitting patches Jul 20 12:26:33 Son_Goku: anyway we all know that every distro is equally bad at this... Jul 20 12:29:30 yeah, all distros are varying degrees of bad at this Jul 20 12:30:04 but it seems "worse" when you have "upstream status" declarations with the assumption that changes *do* go upstream Jul 20 12:31:23 rburton: http://lists.openembedded.org/pipermail/openembedded-core/2017-July/139891.html Jul 20 12:31:30 rburton: high-five? :) Jul 20 12:31:40 Son_Goku: where is the assumption that they go upstream? Jul 20 12:31:57 kanavin: \o Jul 20 12:32:03 kanavin: o/ Jul 20 12:32:33 rburton: the usage of "Upstream-Status" and similar things in the patch metadata implies that is supposed to be part of the process Jul 20 12:32:44 as opposed to being an afterthought Jul 20 12:32:49 the Pending state is explicitly "need to do something about this" Jul 20 12:33:34 which means i can produce a nice chart of how many pending patches we have as leverage Jul 20 12:33:43 ah Jul 20 12:33:48 * Son_Goku shrugs Jul 20 12:33:49 Patches in Pending state: 840 (49%) Jul 20 12:33:59 that's... not a lot of patches Jul 20 12:35:19 Patches with malformed Upstream-Status: 1 <-- goddamnit Jul 20 12:35:51 wtf Jul 20 12:36:31 I think Debian's "Not-Forwarded" state for patches is 4x that of your Pending one Jul 20 12:36:57 debian is a lot larger, so are you comparing percent or absolute numbers Jul 20 12:37:04 numbers Jul 20 12:37:26 I've seen some horrors in Fedora too Jul 20 12:37:41 like, a .spec file with over 100 patches in it Jul 20 12:37:51 was it elfutils which is basically a fedora fork? cant remember Jul 20 12:38:07 I think it may have been openssl :) Jul 20 12:38:10 or openssh? Jul 20 12:38:19 I hope elfutils isn't, because mjw would be horrified Jul 20 12:39:12 openssl *was* only forked slightly to purge encumbered algos and have a stable soname Jul 20 12:39:21 that was still done in less than a dozen patches Jul 20 12:39:40 there are packages like that though Jul 20 12:39:49 I think cdrkit is that way Jul 20 12:39:53 though upstream is dead :/ Jul 20 12:40:06 hmm, still not that many patches... Jul 20 12:40:17 do cdr tools serve any purpose anymore? Jul 20 12:40:26 the medium is basically dead Jul 20 12:40:55 i was wondering that just last week Jul 20 12:40:58 apparently, they're quite popular and useful outside of Western Europe and North America Jul 20 12:41:03 go figure Jul 20 12:41:47 I can imagine there are parts of the world where discs still beat the internet in terms of bandwidth Jul 20 12:43:00 yeah Jul 20 12:43:17 one thing I've been meaning to make time for is porting my livecd-tools from cdrkit to xorriso Jul 20 12:49:45 khem: new glibc fails in glibc-locale Jul 20 13:02:05 kanavin: cdrtools includes Blue-ray too? Jul 20 13:02:10 and DVD Jul 20 13:03:37 TafThorne : yes Jul 20 13:06:19 whats the best way to patch a target configuration file using .bbappend Jul 20 13:06:50 MarcWe : what you mean by " the best way"? Jul 20 13:07:16 most commen Jul 20 13:07:50 best way and most common are usually not the same :-P Jul 20 13:07:57 Yeah Jul 20 13:08:00 a oke Jul 20 13:08:08 because I don't really understand what you are asking really. Jul 20 13:08:27 But the way I patch Jul 20 13:08:36 is going to the git directory of the package in tmp folder Jul 20 13:08:41 do git add Jul 20 13:08:49 git commit -m "the commit message" Jul 20 13:09:10 git format-patch -1 for doing the patch Jul 20 13:09:16 then you have your .patch produced Jul 20 13:09:29 I guess devtools should have a system for patching also Jul 20 13:09:35 cant do the git thing sins the aldusted thing is only for my target Jul 20 13:09:52 so i want to keep the aldusted config in my own layer Jul 20 13:09:52 ? Jul 20 13:10:03 yeah and? Jul 20 13:10:30 I'm still getting the old file when i generate the config file Jul 20 13:10:51 in your bbappend you need to tell the patch you use Jul 20 13:11:14 i have a bbapend with a sub dir that contains the "new" config file Jul 20 13:11:22 yeah so you have a Jul 20 13:11:26 FILEEXTRA..... Jul 20 13:11:30 SRC_URI... your patch Jul 20 13:12:12 And what's the problem with it? Jul 20 13:12:33 i have a SRC_URI Jul 20 13:12:49 When you say config file, you mean something that is like in /etc or you mean a "kernel config" ? A file with a ".cfg" extension Jul 20 13:12:56 yes in etc Jul 20 13:13:10 And have you done the patch? Jul 20 13:13:52 if not do what I said. Jul 20 13:13:55 I was tring to remove the org file and replace it by installing my Jul 20 13:13:57 or use devetools Jul 20 13:14:49 devtools* Jul 20 13:15:28 go to tmp/work////git/ Jul 20 13:15:36 if its easier to replace the file entirely then thats actually simplier Jul 20 13:16:00 add the new file to SRC_URI, then do_install_append() { cp the file into ${D} to overrrite the original} Jul 20 13:16:52 yeah Jul 20 13:19:26 K that was kind of what i was doing exept i used install instead of cp Jul 20 13:21:38 i prob do some basice stuff wrong Jul 20 13:21:42 tnx btw Jul 20 15:02:18 rburton: the old/prod cluster could really use a restart of the AB at some point RSN Jul 20 15:02:30 rburton: could you let me know when your build is done? Jul 20 15:03:08 aye Jul 20 15:03:30 pohly: this looks like a valid error in refkit with ross/mut https://autobuilder.yoctoproject.org/main/builders/nightly-refkit/builds/41/steps/BuildImages/logs/stdio ? Jul 20 15:05:20 joshuagl: I'm not sure how you are hitting that. Nothing in refkit adds "hddimg" as IMAGE_FSTYPE. Jul 20 15:06:38 pohly: suspect it's this change in master: http://git.yoctoproject.org/clean/cgit.cgi/poky-contrib/commit/?h=ross/mut&id=ec251ee98fdbf83bb7f36b179ba3978d7c31b66e ? Jul 20 15:06:42 joshuagl: FYI, current refkit master was broken when updating glibc in 2.9.50. In 2 hours we should finally have an update which works again - see https://github.com/intel/intel-iot-refkit/pull/243 Jul 20 15:07:26 joshuagl: quite possible. But why is there no command for it? Jul 20 15:08:31 possibly refkit-image-minimal doesn't inherit image? Jul 20 15:08:48 It does. Jul 20 15:09:05 ok Jul 20 15:09:42 Perhaps our IMAGE_CLASSES += in refkit-image.bbclass overrides the default IMAGE_CLASSES? Jul 20 15:10:03 Anyway, it looks like once again OE-core + refkit is broken :-/ Jul 20 15:10:25 We really needs this AB testing going to detect such issues earlier. Jul 20 15:11:07 hmm, you have IMAGE_FSTYPES_remove = "live" Jul 20 15:11:29 Yes, that's because we didn't want the "live" type. Jul 20 15:11:54 So we could remove "hddimg" the same way. But that does not explain why it does not even work. Jul 20 15:12:20 AB testing should be in place now to detect these issues ahead of time Jul 20 15:12:32 It could be a class inheritance issue again, where inheriting a class depends on variables that change over time. Jul 20 15:15:21 joshuagl: let's look at this from the other end - how is "hddimg" normally implemented? Jul 20 15:19:54 pohly: image-live is conditionally inherited in image.bbclass by the build_live function Jul 20 15:20:09 hddimg logic is in image-live Jul 20 15:20:21 joshuagl: and it seems to also provide the "hddimg" type. Jul 20 15:21:07 right Jul 20 15:22:19 I bet the logic in build_live(d) ends up not including image-live.bbclass. Jul 20 15:23:08 that's the conclusion I was also drawing Jul 20 15:26:22 joshuagl: I'm just nor sure why that is. Jul 20 15:26:38 I'll update OE-core and debug. Jul 20 15:26:44 Again. Jul 20 15:32:49 pohly: do you expect something different if this had been caught before the change landed in OE-core? Jul 20 15:35:15 ok, so now that my brain is properly melting I'll ask here: I have two image recipes. Each one needs its own kernel device tree, but otherwise the same kernel, packages, hardware, etc. what's the best way to select a different kernel device tree from the image recipe? Jul 20 15:35:55 pohly: IMAGE_TYPE_live="image-live" here, so the build_live() function seems to work as expected Jul 20 15:36:21 my current thought is to add a .bbappend to the kernel with a fetch_append to overwrite the device tree given particular PACKAGECONF settings Jul 20 15:36:27 but that feels like the wrong tool for the job Jul 20 15:36:45 joshuagl: I would have expected that the problem gets flagged when it hits master-next. Jul 20 15:36:53 Not when it hits master. Jul 20 15:36:58 pohly: sure, but then what? Jul 20 15:37:14 And then we discuss whether it's refkit which needs to adapt or the patch needs to be done differently. Jul 20 15:38:38 would likely still require some cloning of oe-core master to investigate the failure? Jul 20 15:39:07 The traditional approach was "OE-core gets updated and everyone else has to adapt later when there are breakages". When making refkit a first-class citizen in Yocto, the scope has increased and breakages need to be dealt with before they enter master. Jul 20 15:39:26 joshuagl: I've update refkit with latest OE-core master. Jul 20 15:39:30 The commit is in master, right? Jul 20 15:39:55 Ah, not yet! Jul 20 15:40:16 Scratch that, it is. I had copied the Poky commit ID. Jul 20 15:43:07 joshuagl: hmm, I am not hitting it locally. Jul 20 15:45:16 But I'm also using a slightly different refkit. Jul 20 15:45:26 Can you reproduce the issue interactively? Jul 20 15:50:37 ed2: why is e2fstools-native not listed in WKS_FILE_DEPENDS_DEFAULT? Isn't that needed when building images with ext4 partitions? Jul 20 15:51:15 I suppose gparted-native is always needed and thus not expected to be listed? Jul 20 15:53:10 I meant e2fsprogs-native... Jul 20 15:54:51 Good afternoon, I am trying to use the rpio recipe. It builds OK but when I run it on the target I get a message about executable not existing when it does (I can ls it). Jul 20 15:57:34 As it is a Python script I tried running it with `python /usr/bin/rpio` and that said that 'logging' was not available. Looking around in https://layers.openembedded.org/layerindex/branch/master/recipes/?q=python+logging suggests that meta-cloud-serices/meta-openstack might the place to get the python logging module from? When I try to include that I then get a bitbake error about ERROR: ParseError atmeta-cloud-services/meta-openstack/recipes-support/c Jul 20 15:58:29 Am I getting the wrong end of several sticks? Jul 20 16:02:53 Is it perhaps time to rename core-image-minimal-initramfs.bb? It's no longer a "minimal" initramfs, but rather implements quite a bit of advanced functionality. Jul 20 16:04:35 I guess it was the basic initramfs image we provide, paralleled with core-image-minimal Jul 20 16:04:39 pohly: ^ Jul 20 16:04:45 but probably wasn't a good name in the first place Jul 20 16:05:14 I think we could safely rename it if a better name were proposed Jul 20 16:05:29 bluelightning: indeed. "core-live-install-initramfs.bb" would be more fitting. Jul 20 16:06:04 TafThorne: I think you may just be missing a standard python package - the logging module is part of the python standard library Jul 20 16:06:11 I find it surprisingly hard to build an image *without* that live install functionality :-( Jul 20 16:06:27 One has to unset quite a few variables which try to add that to an image. Jul 20 16:07:41 TafThorne: python-logging or python3-logging would be the *package* name (produced by the python or python3 recipe respectively) Jul 20 16:09:39 bbl Jul 20 16:22:27 joshuagl: I'm still not sure how you ended up getting this error in the AB. I can't reproduce it locally. But pulling in image-live.bbclass has undesired implications, like also having to build core-image-minimal-initramfs and grub, so I'll extend the IMAGE_FSTYPES_remove to cover also hddimg. Jul 20 16:23:00 hello. i'm trying to cut down the size of the yocto work directory being created by building a ti sdk image. right now, i'm seeing multiple ABIs in the work directory, one for our hardware target and another for armv7 as a whole. any suggestions on where to start looking for cutting this down? Jul 20 16:27:31 pohly: OK, thanks for investigating. Apologies, been in back-to-back meetings so failed to keep investigating. Sounds like we have bugs in the nightly-refkit AB setup still. Jul 20 16:29:24 bluelightning: the python package is already installed though? Or at least I have a python executable. Jul 20 16:30:00 TafThorne: that doesn't mean anything. tons of modules are packaged into independent packages that aren't installed by default Jul 20 16:32:37 kergoth: my point was that bluelightning's answer was to install the python recipie. Jul 20 16:32:48 no Jul 20 16:32:55 he said you need the python-logging or python3-logging package Jul 20 16:33:09 "produced by the python or python3 recipe respectively" is the bit I wanted to ask about Jul 20 16:33:11 the 'python' recipe emits tons of packages Jul 20 16:33:20 including 'python' and 'python-logigng', which are two completely different packages Jul 20 16:33:30 you're mixing up 'recipe' and 'package' Jul 20 16:33:38 probably python-logging too ;-) Jul 20 16:33:49 urg Jul 20 16:34:14 So somehow I have to get the python-logging package into my system Jul 20 16:34:15 if you want all the python modules in the standard library, you can install 'python-modules' Jul 20 16:34:24 otherwise you can install the individual module packages Jul 20 16:35:03 So is there some bitbakey way to do that already or do I write a bitbake recipie that copies a python package into my system somehow? Jul 20 16:35:25 the package that may or may not already exist somewhere in my yocot work area build system thingy? Jul 20 16:36:05 bitbake is a build tool, not a deployment tool Jul 20 16:36:47 devtool provides some commands in that area, i've never used any of them Jul 20 16:36:48 I think I do not know enough about what you mean by those words to understand. Jul 20 16:37:10 if you don't undersatndt he difference between building something and copying something to your device, you need to read up some more Jul 20 16:37:31 The way I copy something to my device is using a .bb recipie though. Jul 20 16:37:39 no Jul 20 16:37:59 recipes emit binary packages, image recipes emit a disk image you can put on your device Jul 20 16:38:06 Well... squash it into a filesystem that then ends up as an sdimage that then ends up on an sd card which ends up in my system. Jul 20 16:38:06 none of those copy anything to your device themselves Jul 20 16:38:30 if you just want to put another package into your image and rebuild the image, use IMAGE_INSTALL, and see the yocto project documentation for how you add packages to an image Jul 20 16:38:43 adding a package to your device without reflashing the image is something else netirely Jul 20 16:39:35 so it really depends on how you want to proceed Jul 20 16:40:04 So when I did `IMAGE_INSTALL_append = " python-logutils"` i was trying to add the wrong thing. I should not have looked in https://layers.openembedded.org I should have known some how that a python-logging recipie... or something like that exists somewhere else. Jul 20 16:40:35 logutils is a completely different python module that you can find on pypi, not stock Jul 20 16:40:52 i don't know if the layer index has info about binary packages or not, offhand Jul 20 16:41:06 Yer, it was just the closest match to the search term python logging Jul 20 16:41:42 the issue here is what you want was the module, and didn't know or care what recipe provided it, whereas the layer index recipe search searches for recipes Jul 20 16:42:00 i don't know if the layer index provides a way to search for packages rather than recipes, if not that's a clear lack Jul 20 16:43:17 What I want was the `prio` executable. Not caring that it was python. Hoping that it would require whatever dependencies it had. Jul 20 16:43:35 it should, if it doesn't that's a bug in its recipe Jul 20 16:44:00 Indeed Jul 20 16:44:35 Adding RDEPENDS_${PN} = "python-logging" might solve that. Jul 20 16:44:48 Though I tihnk it probably needs a threading one that is not there too based on the script code. Jul 20 16:45:27 (I do not do much python ever so I am not sure how things are meant to hang together. If it was Ruby I would know it hangs together loosley via gems) Jul 20 16:46:51 I do not know how it worked, but that RDEPENDS seems to have worked. Something, somewhere magically generated/found a python-logging recipie. I'll be back soon to say if that resulted in a logging python package Jul 20 16:47:42 bitbake knows what packages will be emitted by what recipes Jul 20 16:48:03 it saw the rdepends and looked for recipes that list that in PACKAGES, RPROVIDES_ for each pkg in PACKAGES, or PACKAGES_DYNAMIC Jul 20 16:54:44 Progress. Now I cannot import a module named threading instead. I can predict what lines I need to add for that. Jul 20 16:54:57 kergoth: thank you for your help in getting me this far. Jul 20 16:55:52 bluelightning: thank you for your suggestion. It started me down the right track. I did not know that there was a python recipe able to generate the python pacakges already in my setup, Jul 20 16:55:54 np. it's admittedly a pain to figure out the python module package list. there's a pythondeps script in oe-core that'll scan python scripts or modules and dump a list of the modules they depend on, but it doesn't handle mapping that to actual package names Jul 20 16:56:13 I can grep this script. It is only short Jul 20 16:57:41 So I guess this is a bug on the meta-raspberrypi layer that contains the recipie. I can look about in that directory to see who the maintainers are to send a patch to once I work out all the missing bits. Jul 20 16:59:19 My day is over. TTFN. Once again thank you for the help. Jul 20 18:05:47 Is there some sstate cache expunge script (for example, based on last access time) or do I have to role my own? Jul 20 18:21:52 Has anyone ever seen an autotools recipe result in a config.log with one set of variables, and then different variables in bitbake's log for configure, compile and install (i.e., like all of the variables found in config.log were ignored)? Jul 20 18:22:25 what do you mean? what varaibles would be in bitbake's log? Jul 20 18:27:13 In the recipe's S, I can see the output of running configure, the config.log. In it, the prefix variable resolved to the desired value as expected. However when we go through the whole process to install, the installed location within WORKDIR/image is not the same prefix (it's the default, /usr) Jul 20 18:27:42 Going over the various logs, like log.do_configure, etc. they're all showing usage of prefix=/usr, so I'm just stumped a bit on how to fix this. Jul 20 18:28:13 First time I've seen part of a config get disobeyed, if you will. Jul 20 18:30:53 even when I set EXTRA_OECONF += "--prefix=something_else" it doesn't get reflected in the other logs. Jul 20 18:30:57 only config.log. Jul 20 18:47:42 joshuagl: let's hope that https://github.com/intel/intel-iot-refkit/pull/253 restores building with OE-core master also in the AB. Jul 20 19:59:31 Is there a way to remove arguments from the configure command (so it's not setting --prefix, --libdir, etc.)? Jul 20 19:59:58 (I know I can use EXTRA_OECONF to add more, but setting them to new values seems to have no effect at all.) Jul 20 20:00:07 why would you want to do that? Jul 20 20:01:02 Testing a theory that having all the defaults passed to this particular recipe's configure is what's throwing off things. When I clear everything out and let it just attempt to install however it sees fit, I get some things in *my* prefix directory, but libdir and includedir are no longer tied to prefix (or eprefix) Jul 20 20:02:11 just override do_configure or oe_runconf in the recipe Jul 20 20:02:15 read autotools.bbclass Jul 20 20:06:54 alright, I'll check that out. Jul 20 20:07:00 thanks kergoth Jul 20 20:12:37 I have this package that I'm creating a recipe for. I have the target part done, but it also has a tool that needs to be run natively to create some databases... Jul 20 20:13:56 How do I install the output databases from the native part onto the target system? Jul 20 20:18:55 Normally I think I would make the target recipe depend on the native one and then use the tool from the native recipe in the do_install in the target? Jul 20 20:20:31 but the files are generated in cmake... and built in tree to boot... Jul 20 20:34:56 nathani_: you can install the tool into native sysroot Jul 20 20:35:12 and tweak the cmake Jul 20 20:35:29 to adapt to 2 step process Jul 20 20:35:41 your approach is right Jul 20 20:35:54 is there any way to get a full dependency chain starting with a particular image/bb file? Jul 20 20:37:01 ahhh, yes. tweak the target cmake to look for executable in sysroot instead of build directory. Jul 20 20:37:49 Thanks khem Jul 20 20:40:40 yep Jul 20 20:43:25 more specifically: is there any way to build a list of buildtime and runtime deps starting with a particular layer, image, or bb file? i would like to customize an image but i need a list, preferably with head deps, before i can really start Jul 20 20:53:09 b00t: btibake -g Jul 20 20:56:34 khem: hey, thanks :D **** ENDING LOGGING AT Fri Jul 21 03:00:01 2017