**** BEGIN LOGGING AT Mon Apr 29 02:59:56 2019
Apr 29 06:05:03 <yocti> New news from stackoverflow: How to execute a script in swupdate image recipe in Yocto? <https://stackoverflow.com/questions/55897498/how-to-execute-a-script-in-swupdate-image-recipe-in-yocto>
Apr 29 06:35:07 <yocti> New news from stackoverflow: Where can I find Yocto "sub"-packages not listed in OpenEmbedded layer index like "kbd-keymaps"? <https://stackoverflow.com/questions/55668617/where-can-i-find-yocto-sub-packages-not-listed-in-openembedded-layer-index-lik>
Apr 29 08:28:23 <raem> I'm trying to install p11tool to my system. I was hoping that it is provided in the gnutls package (tried to include gnutls as well as gnutls-bin in my image)
Apr 29 08:28:43 <raem> am i missing something?
Apr 29 08:29:24 <LetoThe2nd> raem: maybe this? http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/p11-kit/p11-kit_0.23.15.bb?h=master
Apr 29 08:30:57 <raem> that's p11-kit not p11tool (which is also requried and i already have it in my image)
Apr 29 08:32:13 <LetoThe2nd> raem: was just an idea :)=
Apr 29 08:44:59 <bluelightning> raem: try oe-pkgdata-util find-path '*/p11tool'
Apr 29 08:55:23 <miwa> I'm getting a QA error building nativesdk-gnu-config, Files/Directories were installed but not shipped in any package, is this dependent on my host distribution and that's why the error is occuring? But shouldn't do_install work the same on all hosts regardless of distribution?
Apr 29 08:57:34 <raem> bluelightning: thanks for the tip, that's a really nice util tool i didn't know. However doesn't find anything. I now tried to included it via a .bbappend with `FILES_${PN}-bin += "${bindir}/p11tool"`
Apr 29 08:58:25 <varjag> long shot, but does anyone has a layer that makes sumo build on ubuntu bionic
Apr 29 08:58:27 <varjag> ?
Apr 29 08:58:37 <bluelightning> raem: I don't think that's going to help on its own, if the file isn't in another package within that recipe already
Apr 29 08:59:26 <varjag> right now a bunch of native recipes fail to build (glibc version conflicts and such) so i have to shadow them manually
Apr 29 09:00:13 <raem> bluelightning: yeah didn't work :). it's just weird that the binary is provided in the gnutls package but somehow not everything packed in the recipe
Apr 29 09:01:20 <raem> is there a way to see what's going on during the build process of the gnutls recipe. to figure out if files are missing etc?
Apr 29 09:01:28 <varjag> related, what's the easiest way to drop qemu?
Apr 29 09:02:37 <bluelightning> raem: you could have a look at the logs for gnutls - find the workdir using: bitbake -e gnutls | grep ^WORKDIR=
Apr 29 09:02:44 <bluelightning> raem: then look under temp/ under that directory
Apr 29 09:03:24 <raem> bluelightning: thanks, will try this out
Apr 29 09:03:52 <bluelightning> varjag: not sure you can easily... a good start would be to build for a non-qemu MACHINE, but that's only part of the dependency
Apr 29 09:05:54 <varjag> i do build for non-qemu machine yes
Apr 29 09:06:17 <varjag> everything was fine while the build box was 16.04 ununtu
Apr 29 09:06:30 <varjag> now it's retired and i have to move my toys to my workstation
Apr 29 09:06:33 <varjag> which is 18.04
Apr 29 09:06:50 <varjag> qemu then gets fussy about glibc
Apr 29 09:07:35 <varjag> now one solution would be to build it in a vm like it's common with legacy toolchains
Apr 29 09:07:57 <varjag> but i haven't even released the product yet, this would be humiliating :)
Apr 29 09:09:19 <varjag> so what i did now, made a transition layers with recipes-devtools
Apr 29 09:09:35 <varjag> and populate it with newer versions of conflicting packages
Apr 29 09:09:58 <paulbarker> varjag: I'd recommend spinning up an Ubuntu 16.04 container. The glibc update from 16.04 -> 18.04 is a bit of a jump
Apr 29 09:10:43 <varjag> i see
Apr 29 09:10:56 <varjag> warrior, is it expected to work on bionic?
Apr 29 09:11:29 <paulbarker> I bailed out after 3 full days of work trying to get an older branch (around Yocto Project 2.0) working on Ubuntu 18.04. Would have taken at least an extra week or two of full time effort which just wasn't worth it
Apr 29 09:11:38 <paulbarker> thud should work under Ubuntu 18.04
Apr 29 09:12:33 <varjag> hm.. tried moving qemu from thud into my recipes-devtools, but there's hard dependency to quemu 2.10.1 someplace
Apr 29 09:13:04 <varjag> maybe i should just move my project to thud..
Apr 29 09:13:30 <paulbarker> Yea, you're going to have a long string of dependencies. By the time you've got it compatible you'll have changed a lot of core recipes and have a Frankenstein's monster that no-one else has tested
Apr 29 09:13:44 <varjag> point
Apr 29 09:14:43 <paulbarker> I use LXD containers for a pretty lightweight way to run older Ubuntu versions within an Ubuntu 18.04 base image. You can also use Docker if that's your thing
Apr 29 09:15:21 <paulbarker> Builds are slower in VMs, I think due to increased I/O latency, but builds in containers seem to be just as fast as outside
Apr 29 09:15:41 <varjag> i didn't use docker for anything yet
Apr 29 09:15:49 <varjag> did have build environments in plain chroots tho
Apr 29 09:59:13 <bluelightning> raem: looks like we configure gnutls with --without-p11-kit by default so that's probably why it's not there
Apr 29 10:01:07 <bluelightning> raem: there's a PACKAGECONFIG for it though so you'd only need to add PACKAGECONFIG_append_pn-gnutls = " p11-kit" to your configuration
Apr 29 10:27:10 <erbo> I use the crops/poky docker containers for building. It's so nice to not have to worry about which build host environment I'm using. I can really recommend that, and I cannot notice any performance penalty.
Apr 29 10:44:47 <raem> bluelightning: thanks for the tip, just found out also that p11kit is missing. Now I also know how PACKAGECONFIG is working :)
Apr 29 11:43:34 <rburton_> kanavin: please send a patch changing perl owner to you. i'll give you actual money.
Apr 29 11:45:58 <LetoThe2nd> rburton_: in a valid currency? ;-)
Apr 29 11:46:03 <rburton_> sure
Apr 29 11:46:53 * LetoThe2nd had expected Italian Lira or such.
Apr 29 11:52:02 <RP> rburton_: haha :)
Apr 29 12:06:08 <yocti> New news from stackoverflow: How can I auto load kernel module on boot in Yocto? (like "insmod /xxx/oo.ko") <https://stackoverflow.com/questions/55902608/how-can-i-auto-load-kernel-module-on-boot-in-yocto-like-insmod-xxx-oo-ko>
Apr 29 12:33:10 <paulbarker> Finally tracked down some recent build issues. The golang compiler sets 0500 permissions on directories for cached dependencies
Apr 29 12:33:17 <paulbarker> That's professionally helpful
Apr 29 12:42:02 <paulbarker> https://github.com/golang/go/issues/27161#issuecomment-433102849 *facepalm*
Apr 29 12:43:45 <zeddii> whee
Apr 29 12:46:00 <rburton_> fun
Apr 29 12:48:22 <paulbarker> I'm just going to have to add a recursive chmod to the end of do_compile for the affected package (netns)
Apr 29 12:48:56 <zeddii> yup. sometimes the best thing to do is just work around it.
Apr 29 12:48:58 <paulbarker> It doesn't seem to be an issue for most go recipes and only affects netns after updating to >= v0.5.0
Apr 29 12:49:31 <paulbarker> Not sure it's something we can fix universally as the module cache ends up in different places for different recipes
Apr 29 12:50:01 <paulbarker> I think it's just one more Feature (TM) of the go compiler
Apr 29 12:50:08 <zeddii> heh. I was about to say that.
Apr 29 12:50:20 <zeddii> a never ending source of fun.
Apr 29 12:50:34 <paulbarker> Like using a tmpdir for intermediate object files and unconditionally removing them when the `go` tool exits so you can't debug any linker errors
Apr 29 12:51:24 <zeddii> what is this debug you speak of ? "full stack" go developers never have such issues.
Apr 29 12:52:30 <paulbarker> Things do seem to work if you don't use cgo
Apr 29 12:52:39 <paulbarker> All the interesting software needs cgo to do some magic though
Apr 29 12:53:54 <zeddii> yah, when I've had to patch multiple makefiles to even allow CGO to be enabled, you know you are off the beaten path :D
Apr 29 12:54:42 * zeddii wonders why on his brand new build server that icu-native just went boom.
Apr 29 12:54:47 <paulbarker> I think I'm permanently scarred after trying to debug the C code burried in runc
Apr 29 12:54:55 <zeddii> heh. no doubt.
Apr 29 12:57:31 <paulbarker> My new advice when looking at an issue is, if `git grep longjmp` shows anything just run away immediately and pretend you never saw the issue
Apr 29 13:03:08 <LetoThe2nd> paulbarker: and 'git grep shortjmp' ;-)
Apr 29 13:03:33 <LetoThe2nd> paulbarker: i'm just preparing sstate and stuff for the show tomorrow ;-)
Apr 29 13:03:58 <paulbarker> LetoThe2nd: Excellent, will be around for that
Apr 29 13:05:50 <LetoThe2nd> paulbarker: \m/
Apr 29 13:07:22 * zeddii reverts an april 24th icu version bump to see if that helps
Apr 29 13:11:01 <RP> zeddii: new servers are such fun
Apr 29 13:12:43 <LetoThe2nd> RP: heh, we literally ordered new gear for ~15k 5 minutes ago
Apr 29 13:14:41 <zeddii> indeed. I'm seeing an icu-native build failure that clearly no one else is, and one that I'm not seeing on my "broken in" servers. Reverting the april version bumps has me building again. I'll take a closer look shortly.
Apr 29 13:33:17 <leitao> how do I know which package is adding a usergroup in my final image?
Apr 29 13:36:09 <RP> leitao: grep?
Apr 29 13:37:57 <leitao> RP: well, I tried that, grepping for ADDGROUP, but no clue.  It seems someone is creating a 'video' usergroup. I am interested who.  I am wondering if it is being created using a different way
Apr 29 13:39:13 <JPEW> leitao: base-passwd maybe?
Apr 29 13:39:47 <RP> leitao: start be looking at base-passwd which has the basics
Apr 29 13:39:57 <leitao> ok, let me take a look there. Thanks
Apr 29 14:51:10 <yates> if there are multiple patch files for a recipe, with an associated .bbappend, do the patches get applied in the order in whcih they are listed in the SRC_URI?
Apr 29 14:52:24 <rburton_> yes
Apr 29 14:52:42 <rburton_> the order that the src_uri is evaluated to
Apr 29 14:52:53 <rburton_> its literally for patch in src_uri
Apr 29 14:53:21 <yates> ok
Apr 29 14:53:56 <yates> so this becomes important if the same file is patched in more than one .patch file?
Apr 29 14:56:17 <yates> (probably not a good situation)
Apr 29 14:56:41 <erakis> Hi, I'm running bitbake on fido branch and I try adding the `vim` package to my image. But, I'm getting the error `No checksum specified for... ../downloads/vim_vim.googlecode.com_.hg._v7-4-│meta-intelia
Apr 29 14:56:41 <erakis> 481.tar.gz, please add at least one to the recipe:`. I can't upgrade from fido. Does anyone have a solution?
Apr 29 15:00:18 <LetoThe2nd> erakis: um, do what the error message tell you to do?
Apr 29 15:00:26 <LetoThe2nd> erakis: -> add a checksum for the download
Apr 29 15:01:57 <erakis> @LetoThe2nd: Is this means that I need to modify the vim recipe itself ? Or I can add a patch somewhere else in my meta branch ?
Apr 29 15:02:31 <LetoThe2nd> erakis: you can either copy it over into your own layer and modify it there, or use a bbappend.
Apr 29 15:15:02 <erakis> @LetoThe2nd: So I can add the file `vim_7.4.481.bbappend` into `meta-mymeta/recipes-core/image-myimage/files/vim_7.4.481.bbappend` and add the `FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"`, `SRC_URI[md5sum]=... SRC_URI[sha256sum]=...` into ? But what do I have to put into my recipe so that the bbappend be applied ?
Apr 29 15:29:57 <erakis> @LetoThe2nd: Ok I got it, I have to put it in `meta-mymeta/recipes-support/vim/vim_7.4%.bbappend`.
Apr 29 15:36:46 <yocti> New news from stackoverflow: Yocto, Fixing Computing transaction error in do_rootfs? <https://stackoverflow.com/questions/55906525/yocto-fixing-computing-transaction-error-in-do-rootfs> || What is the new IMAGE_DEPENDS_wic_append_suffix notation? <https://stackoverflow.com/questions/55906202/what-is-the-new-image-depends-wic-append-suffix-notation>
Apr 29 15:57:57 <JPEW> Has anyone given thought to making qemux86 be i686 instead of i586?
Apr 29 16:06:51 <yocti> New news from stackoverflow: meta-marvell update do_image_ [depends] with MACHINE override <https://stackoverflow.com/questions/55358358/meta-marvell-update-do-image-typedepends-with-machine-override>
Apr 29 17:37:04 <yocti> New news from stackoverflow: Config parsing error on xl create for Xen Guest DomU <https://stackoverflow.com/questions/55907917/config-parsing-error-on-xl-create-for-xen-guest-domu>
Apr 29 18:04:27 <erakis> Hi, I would like to add alias for all users. Ex: alias ls='ll='ll -la'. What is the proper way ? Adding them from IMAGE_POSTPROCESS_COMMAND is a good choice ? Or overriding base-files with a bbappend ?
Apr 29 19:02:56 <JPEW> erakis: We have a bbappend for base-files that adds them to .profile
Apr 29 19:03:29 <JPEW> or .bashrc
Apr 29 19:06:18 <erakis> @JPEW: I find this https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/base-files/base-files/share/dot.bashrc. But I'm on sh. So If I well understand, I should override https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/base-files/base-files/share/dot.profile with a bbappend file ?
Apr 29 19:07:49 <bl4ckb0ne> hi, im looking for a recipe for the intel compiler, is there one available ?
Apr 29 19:08:26 <JPEW> erakis: Ya, thats sounds like the right track
Apr 29 19:10:22 <erakis> @JPEW: Thank you
Apr 29 19:11:57 <erakis> @JPEW: But, what will looks like the .bbappend ? meta-mylayer/recipes-core/base-files/base-files/share/dot.profile.bbappend ?
Apr 29 19:12:41 <JPEW> erakis: Just one line: FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
Apr 29 19:13:03 <JPEW> oh, sorry
Apr 29 19:13:06 <erakis> @JPEW: I put "FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" as first line and on the second line "alias l='ls -CF'" in this file and this will work ?
Apr 29 19:13:55 <JPEW> You need 2 files: meta-mylayer/recipes-core/base-files/base-files.bbappend which has the line I gave you
Apr 29 19:14:37 <JPEW> and meta-mylayer/recipes-core/base-files/base-files/dot.profile which has the complete .profile you want (it will completely overwrite the core dot.profile)
Apr 29 19:15:15 <JPEW> .bbappend file only append to .bb files
Apr 29 19:16:25 <JPEW> So, you write a .bbappend that prepends to the path that bitbake uses when it looks for "fiel://dot.profile" so it finds yours before the core dot.profile file
Apr 29 19:16:51 <erakis> Thank you so much, that make sense. I need to go, but I will try it later in the evening.
Apr 29 19:19:34 <rburton_> bl4ckb0ne: ISS comes with a meta-iss layer
Apr 29 19:20:20 <bl4ckb0ne> i found a lot of things about compiling a project with an icc toolchain, but nothing about packaging it
Apr 29 19:20:36 <rburton_> there's totally a layer installed as part of the installer because i was poking at it last month
Apr 29 19:21:41 <rburton_> https://software.intel.com/en-us/articles/using-intel-system-studio-with-the-yocto-project
Apr 29 19:23:38 <bl4ckb0ne> neat, i think thats exactly what I need
Apr 29 19:23:41 <bl4ckb0ne> thanks!
Apr 29 19:27:36 <bl4ckb0ne> I also experience trouble with a clone from a git lfs repo, does the recipe uses it own git binary ?
Apr 29 19:45:18 <bl4ckb0ne> that iss seems to be only for runtime compiler
Apr 29 20:35:42 <radsquirrel> hi everyone I'm Brad from OpenBMC
Apr 29 20:36:03 <radsquirrel> hey we are exploring ways to improve developer workflow.
Apr 29 20:36:45 <radsquirrel> one idea that came up was some kind of way to include the source code for our applications right in the metadata layer
Apr 29 20:36:51 <radsquirrel> not sure how that would look, still exploring.
Apr 29 20:37:23 <radsquirrel> I vaguely remember reading somewhere that source-code-in-meta isn't recommended but I can't find that anymore.
Apr 29 20:37:35 <yocti> New news from stackoverflow: unable to execute Yocto Extensible sdk (eSDK) script <https://stackoverflow.com/questions/55910465/unable-to-execute-yocto-extensible-sdk-esdk-script>
Apr 29 20:37:36 <radsquirrel> Does the yocto community have any opinions to help guide us on this?
Apr 29 20:37:42 <radsquirrel> thanks!
Apr 29 20:39:32 <JPEW> radsquirrel: Are you looking for a "temporary" solution, as in the developers want to point a recipe to their local code, do some development with it, then swicth it back to the "offical" recipe when finished?
Apr 29 20:39:57 <radsquirrel> well I think there is devtool for that right?
Apr 29 20:40:24 <JPEW> radsquirrel: Yes, that and externalsrc :)
Apr 29 20:41:10 <RP> armpit: any idea what I missed in the ltp config of https://autobuilder.yocto.io/pub/non-release/20190429-6/testresults/testresult-report.txt ?
Apr 29 20:41:24 <nasamuffin> Hiya, I'm working on OBMC too - I think the root here is that right now we have ~1 layer per Git repo, and one possible solution is to instead shoot for multiple layers in one git repo
Apr 29 20:41:37 * armpit looks
Apr 29 20:41:53 <RP> armpit: all the first ltp tests show 0 tests
Apr 29 20:41:58 <nasamuffin> I'm kind of hoping for something more like 1 layer per git submodule (although, as brad said, still under investigation)
Apr 29 20:42:18 <radsquirrel> JPEW: One issue we have is that as we implement features and review them, the wip patches are distributed across 3-4 different repositories.
Apr 29 20:42:43 <radsquirrel> JPEW: maybe a couple application repositories, and couple bitbake meta-layers.
Apr 29 20:42:43 <nasamuffin> I'm not sure that necessarily means sticking the source right into the distro layer. The manual seems to indicate that it's not necessary to put source into additional SCMs at all
Apr 29 20:43:05 <radsquirrel> JPEW: with all those repos it can be hard to try out a feature before things have been merged.
Apr 29 20:43:41 <bl4ckb0ne> but /b 4
Apr 29 20:43:46 <armpit> RP, that is odd because I ran resulttool on the AB and it looked fine
Apr 29 20:43:47 <bl4ckb0ne> fail, sorry
Apr 29 20:43:54 <JPEW> radsquirrel: I share your pain :) We have the same problem, changes have to trickle through a lot of layers to into a final build
Apr 29 20:44:31 <radsquirrel> JPEW: well if nothing else it helps to know it is a real pain point.
Apr 29 20:44:40 <kergoth> it should certainly be possible to put a recipe inside a project source directory, and have that source idr as a submodule of a layer with bbfiles set to match those recipes
Apr 29 20:44:41 <radsquirrel> and not just something we are doing wrong.
Apr 29 20:44:50 <JPEW> radsquirrel: Is it necessary to have the new features immediately? We more or less mitigated the problem with some daily build shenangians
Apr 29 20:44:55 <kergoth> or something along similar lines, but there are downsides to it not being out of band
Apr 29 20:45:22 <paulbarker> We're using git submodules, for our own meta layers I've considered scripting an automatic submodule update commit in the top level repository when there's a merge to master in the layer repository
Apr 29 20:45:53 <nasamuffin> paulbarker: do you think you could link your repo? i'd like to see how you've done it
Apr 29 20:45:56 <kergoth> can look at alternatives to submodules (i.e. repo), or assisting tools to submodules (i.e. git-meta) too
Apr 29 20:46:23 <kergoth> git-meta is interesting since it lets you do a 'git meta commit' which commits to every modified submodule and commits to the master updating the submodules accordingly with one command
Apr 29 20:46:27 <paulbarker> nasamuffin: I've considered it, not implemented it yet, our churn isn't fast enough to push me to do it yet
Apr 29 20:46:28 * kergoth needs to try that one
Apr 29 20:46:39 <JPEW> paulbarker, radsquirrel: We do effectively the same thing with a nightly build job; it loops through the recipes we care about, checks out the head of their branch, does a few spot builds, then pushes up a change for review (we use gerrit)
Apr 29 20:46:52 <paulbarker> But it should be fairly straightforward with a git hook on each layer repository
Apr 29 20:47:03 <nasamuffin> i mean specifically the git-sm setup, not necessarily the script
Apr 29 20:47:05 <radsquirrel> JPEW: that is an interesting though.  some kind of tag in the pull request perhaps gets it into a build.
Apr 29 20:47:16 <radsquirrel> s/though/thought
Apr 29 20:47:25 <paulbarker> nasamuffin: https://gitlab.com/oryx/oryx
Apr 29 20:47:29 <nasamuffin> ty!
Apr 29 20:48:01 <paulbarker> We used to use repo tool but it had too many failure modes
Apr 29 20:48:24 <nasamuffin> actually if i can put on my git contributor hat quickly i'll state that we're hoping people will stop using repo and start using submodules soon :)
Apr 29 20:48:26 <JPEW> radsquirrel: Well.... thats where the shenangins come in :) We have a *separate* job that builds those same recipes with ${AUTOREV}.... so if you pull a "daily" build you get those
Apr 29 20:48:51 <JPEW> And the auto-upgrade jobs ensures that the recipe is more-or-less up to date with the daily build
Apr 29 20:49:07 <paulbarker> nasamuffin: You may find our nightly trigger script interesting. Does a tentative update of all layers and tags the result for a nightly build
Apr 29 20:49:21 <nasamuffin> paulbarker: tyvm, i'll be sure to take a look.
Apr 29 20:49:21 <paulbarker> https://gitlab.com/oryx/nightly-trigger/blob/master/nightly-trigger.sh
Apr 29 20:49:27 <paulbarker> Straightforward but fairly effective
Apr 29 20:50:21 <radsquirrel> JPEW: I follow.
Apr 29 20:51:08 <radsquirrel> I see an option for us to pursue in that, so thanks.
Apr 29 20:51:19 <paulbarker> The only thing I struggle with in git submodules is mirroring
Apr 29 20:52:17 <nasamuffin> can you elaborate?
Apr 29 20:52:55 <paulbarker> We point directly at third party layers in our .gitmodules file. If they move or disappear our old commits of the top-level repository no longer build
Apr 29 20:53:14 <radsquirrel> kergoth what were the downsides to not being out-of-band?
Apr 29 20:53:34 <radsquirrel> thats what I thought I had read at one point but could not find again.
Apr 29 20:54:10 <kergoth> mainly overhead, changes which aren't bound to the branch end up having to be cherry picked to every affected source branch. of course the alternatives have their own overhead to deal with, and that could be alleviated with tooling. i don't know of anyone doing much work with metadata within source trees at the moment
Apr 29 20:54:56 <radsquirrel> kergoth: actually I was still parsing your first...
Apr 29 20:55:13 <radsquirrel> meta-data within source?
Apr 29 20:55:30 <radsquirrel> I think we were looking at it from the other way - source in metadata?
Apr 29 20:58:36 <radsquirrel> kergoth: will keep trying to wrap my head around that :-)
Apr 29 20:58:55 <radsquirrel> kergoth paulbarker nasamuffin JPEW thanks for the ideas!
Apr 29 21:37:27 <RP> armpit: https://autobuilder.yoctoproject.org/typhoon/#/builders/95/builds/1/steps/7/logs/step1c - ltp_groups took 30s?!
Apr 29 21:38:01 <RP> armpit: compared to 8000s in https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/161/steps/7/logs/step1c
Apr 29 21:38:33 <RP> armpit: has to be a missing dependency...
Apr 29 22:07:53 <yocti> New news from stackoverflow: How to tell bitbake to variable's calculate basehash value after specific task? <https://stackoverflow.com/questions/55911423/how-to-tell-bitbake-to-variables-calculate-basehash-value-after-specific-task>
**** ENDING LOGGING AT Tue Apr 30 02:59:57 2019