**** BEGIN LOGGING AT Tue Jul 02 02:59:56 2019 Jul 02 04:12:41 New news from stackoverflow: Yocto build for a static library fails with error "No Match Found" Jul 02 06:21:59 Hi, im getting a: error: this statement may fall through [-Werror=implicit-fallthrough=] Jul 02 06:22:00 when creating the sdk. if i look in the file where te error is happening it is markt as /* FALLTHROUGH */ Jul 02 07:12:50 RP: OK, at least I know it's correct, I'm still confused though why it's in this directory but I'm surely missing a lot of info on how everything works for native packages Jul 02 07:13:08 RP: now, is there anyway to add a symlink in a native package without having a warning? Jul 02 07:13:39 'I'm confused on how I am supposed to add a symlink in a do_install for a native recipe: `ln -s ${bindir} ${D}${bindir}/foo` does not work because ${bindir} resolves to an absolute path and ln -s ${D}${bindir} ${D}${bindir}/foo also does not work because it's also an absolute path and yocto does not want those anymore for native recipes' Jul 02 07:19:32 qschulz: can't you create a relative symlink by moving into e.g. the destination directory and use ln -s . foo ? Jul 02 07:21:20 I guess you don't even have to move there, just "ln -s " Jul 02 07:21:51 and the "relative path" is relative to the link name Jul 02 07:22:30 hey. Is there an easy way to fail a recipe when a variable in the environment is not set? Can I just do something like if [[ -z $MYVAr ]]; then return false? Jul 02 07:22:32 so "ln -s ../ ${D}${bindir}/foo" in your case, I think that would work Jul 02 07:23:17 (I am talking about do_install_append()) Jul 02 07:27:16 sven^: bb.error? Jul 02 07:27:41 that's a thing? Nice! Jul 02 07:28:22 and checking for empty variables in a bash style way is correct? The error output looks like yocto uses the variable name when it is empty Jul 02 07:29:25 sven^: could you give a bit more context on what you're trying to achieve? You might be going the wrong way, so better ensure we find a good solution instead of giving you the hackish way :) Jul 02 07:30:17 erbo: well... yes? :) I was a bit weirded out using those kind of symlinks. Jul 02 07:30:35 now I'm still wondering why such a tree in the image directory of the recipe. Jul 02 07:30:48 qschulz: -r option to ln ? Jul 02 07:32:35 I have a package taking gitlabs pipeline id from the environment and dumping it in the final image. So I am doing something like export VERSION_BUILD_ID = "${CI_PIPELINE_ID}". When that variable is not set I get strange errors like "No such directory: .../../image-version/1.0-${CI_PIPELINE_ID}/.../... So it seems yocto uses the variable name when the value is empty. I want to check for that case and just fail the build (as a side effect bitbakes Jul 02 07:32:35 creates a ton of directories with names like "!=" , "if", "os.path.normpath(d.getVar(......" which is quite ugly Jul 02 07:35:17 so I want to abort the moment that variable is not set in the environment (which only happens if you manually build an image and forget to set it or if the runner breaks) Jul 02 07:36:40 qschulz: I'm assuming the paths are set up somewhat special so that bitbake can then assemble a per-recipe sysroot more easily Jul 02 07:37:44 qschulz: it won't install into "/path/to/recipe/workdir/sysroot-native" dir, since that's the sysroot-native dir used for building your recipe. Jul 02 07:38:31 er, no that would be recipe-sysroot-native. My bad. Jul 02 08:57:41 sven^: can't you have this script to retrieve the pipeline id from a class that you inherit in the recipes you need to use it? Jul 02 08:57:57 instead of using environment variables? Jul 02 08:58:31 Hi, i managed to solve the issue by editing the sorce files whats best practes to create a patch for the source code Jul 02 08:59:23 qschulz: uhm.. it's a seperate recipe that does nothing but to dump the env variable to disc. I simply did a if not d.getVar("...", False): bb.abort(...) now in do_fetch_prepend() Jul 02 08:59:33 seems to be enough for now Jul 02 09:06:00 MarcWe: You can use devtool for example. Or you can use git or quilt manually on top of the actual sources. You create the patch and then you add it in a subdirectory on the same level of the recipe (named after the recipe, or "files", ...) and add this one to SRC_URI with "file://" in front Jul 02 09:07:06 MarcWe: if you don't "own" the recipe (i.e. coming from an upstream layer), you can use bbappend (and then you need the FILESEXTRAPATHS_prepend := "${THISDIR}/" in thie bbappend Jul 02 09:07:25 sven^: you could also use a python anonymous function Jul 02 09:07:44 when do those get executed? Jul 02 09:08:06 maybe I am a bit blind but I have a hard time finding documentation on how stuff like this works Jul 02 09:08:14 sven^: and I don't remember if Yocto is tracking all environment variables or not, but you might want to add them to the list of tracked environment variables so that if it changes, the recipe gets rebuilt Jul 02 09:08:20 sven^: at parsing time Jul 02 09:08:24 like how do I use d? When do I use bb.getVar? etc. pp Jul 02 09:09:42 qschulz: tnx ( its not my layer so it going to be the second option ) Jul 02 09:16:12 qschulz: ok, __anonymous is much better, thanks Jul 02 09:16:23 MarcWe: also, might be a good idea to send the patch you created to the maintainer of the project (first to the project, second to the layer) Jul 02 09:16:31 they'll thank you :) Jul 02 09:18:16 sven^: we use the two BB_ENV_* variables in my company : https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#var-BB_ENV_WHITELIST Jul 02 09:18:30 sven^: it might help you, who knows :) Jul 02 09:18:55 yeah, we are using BB_EXTRA_WHITE Jul 02 09:19:06 uh, BB_ENV_EXTRAWHITE Jul 02 09:19:19 hello! Jul 02 09:20:41 what would be best practice for versioning final image ? image is built using multiple repositories each having its revision... + MACHINE ... Jul 02 09:21:40 ok. MACHINE doesn't play role. but how to embedded version and revision of used repositories ? make same branch on all of them ? tag all of them ? Jul 02 09:22:14 complicated topic and if you find a good solution, tell me Jul 02 09:23:04 we are dumping versions in each package using a class that is inherited in each custom project's recipe. In addition to that we dump each layer's git sha to a file Jul 02 09:24:00 ak77: use some form of automation that defines all layer revisions together with the variables to be set. we use kas for that. Jul 02 09:24:06 + a repo manifest with fixed commits on each included layer in a main repository responsible for builds with tags for RCs and releases Jul 02 09:24:32 ak77: so we have one kas configuration file under version control, which essentially folds out into the would tree of the build. Jul 02 09:25:09 sven^: repo is another possibility, of course. i don't know about its capabilities to automate local.conf generation, though. Jul 02 09:25:18 sven^: tagging and brancing manifest repo crossed our mind, yes. Jul 02 09:26:19 sven^: I wouldn't generate local.conf, it could be committed per specific builder Jul 02 09:26:22 LetoThe2nd: in the main repo there are manifests for repo for development, test builds and releases and a set of local.conf templates that will get copied at the start of a build Jul 02 09:27:14 sven^: ok ok. different manifests in same repo? Jul 02 09:27:24 LetoThe2nd: will check "kas" Jul 02 09:27:49 ak77: yeah. you just run repo init? with the url to the manifest you are trying to build Jul 02 09:27:51 LetoThe2nd: hmm. any link Jul 02 09:28:06 ak77: https://pypi.org/project/kas/ Jul 02 09:28:30 so something like repo init -u ssh://git@gitserver/main-build-repo -u develop.xml Jul 02 09:28:35 sven^: sure, what ever works for your usecase/workflow. i don't think there a one size fits all solution at the moment. Jul 02 09:29:17 LetoThe2nd: indeed. I have done a bit of research on the topic and in the end we wrote like 1k of python to just script what we want to do Jul 02 09:30:02 sven^: :) Jul 02 09:30:20 I am still very unhappy with it :) Jul 02 09:31:00 sven^: thats why i usually recommend kas, because it cut down our scripting to almost zero. its just mildly complicated if you use their provided docker container and need to pass in additional environmental things, but nothing unherad of too Jul 02 09:32:21 but of course, YMMV. Jul 02 09:34:16 I'll have a look at that Jul 02 09:34:21 thanks Jul 02 09:35:27 have fun! Jul 02 09:46:50 kas looks ok, repo approach too. in both cases there is a committed file with revisions Jul 02 09:49:57 ak77: exactly, thats what its about. Jul 02 10:38:46 yeah and make sure not to use AUTOREV anywhere Jul 02 10:51:09 sven^: ++ Jul 02 10:51:25 rburton: i am surprised that INTEL is testing INTEL!!!one!!11!eleven! :) Jul 02 10:52:12 intel tests IA, WR test the rest Jul 02 10:52:29 rburton: :-) Jul 02 11:06:00 by the way, any ideas what i could talk about next tues on twitch? Jul 02 11:19:20 you are talking on twitch? Jul 02 11:20:29 sven^: yep Jul 02 11:20:40 about what? Jul 02 11:21:09 sven^: i do the monthly live coding session, every second tuesday a month at 17:00 europe/berlin time Jul 02 11:21:37 coding yocto? Jul 02 11:21:59 LetoThe2nd: testing? how easy it is to add tests? using devtool? Jul 02 11:22:06 sven^: https://www.twitch.tv/yocto_project Jul 02 11:22:26 RP: phew. maybe i should stick to topics i actually know something about :) Jul 02 11:22:34 LetoThe2nd: nice. I'll check it out next tuesday Jul 02 11:23:03 LetoThe2nd: no sense of adventure? :) Jul 02 11:23:17 yeah, what tools does openembedded/yocto provide for QA Jul 02 11:23:20 :O Jul 02 11:23:59 RP: i am highly adventurous! sometime i even drink stout. and when i'm in a really crazy mood, even an IPA. happens only every couple of years, though. Jul 02 11:24:30 LetoThe2nd: :D Jul 02 11:24:41 LetoThe2nd: I like stouts, not keen on IPA though Jul 02 11:24:54 RP: same here. but, i'm being adventurous. Jul 02 11:25:05 hard to find decent ones here Jul 02 11:25:16 LetoThe2nd: the link to the youtube channel is broken Jul 02 11:25:37 i mean, of course i can rebrand it from live coding to live drinking with the yocto project... hmmmm Jul 02 11:26:32 sven^: let me check Jul 02 11:26:50 sven^: works for me Jul 02 11:27:36 it leads to https://www.twitch.tv/www.youtube.com/user/TheYoctoProject which is not found Jul 02 11:27:57 "This content is only available if you have a time machine, Jul 02 11:27:59 " Jul 02 11:28:40 sven^: for me it likes to https://www.youtube.com/user/TheYoctoProject directly Jul 02 11:28:47 sven^: LetoThe2nd clearly has a time machine Jul 02 11:28:50 can anybody else have a look, please? Jul 02 11:29:32 RP: in fact i have. https://en.wikipedia.org/wiki/Time_Machine_(Joe_Satriani_album) Jul 02 11:30:22 LetoThe2nd: there are two links. The "Past stream recordings are on the YouTube channel." one is broken Jul 02 11:30:45 LetoThe2nd: Schedule section Jul 02 11:30:50 aaah ok that explains it. lemme fix it. Jul 02 11:31:48 LetoThe2nd: the link for Yocto Project Lerning Resources is broken, too Jul 02 11:32:34 but don't expect too much, we're just uploading the old streams to youtube as we speak... hopefully. Jul 02 11:32:56 well, I am a newbie and have a lot to learn :) Jul 02 11:35:45 ok, both fixed Jul 02 11:36:42 uh, kas is made by siemens? Oo Jul 02 11:37:25 yep Jul 02 11:38:33 that kind of makes me not want to use it... Jul 02 11:41:21 sven^: well is that based upon any real evidence, especially of daniel being a bad coder/maintainer? or jsut generic yuge company bashing? Jul 02 11:43:23 our platform is compatible to several of their products and it has been a pita to work around their horrendous documentation and implementation quirks Jul 02 11:43:57 makes me guess you come from plc land Jul 02 11:44:39 it's probably stupid to assume their yocto contributions are as bad as other things they do (that had 30-40 years to feature creep), but it's just a connection I make subconciously Jul 02 11:44:58 sven^: nothing more to say :) Jul 02 11:45:13 actually I am working on products that should get rid of plcs on the long run, but as for now we have to be compatible :) Jul 02 11:49:54 Before I go crazy in Yocto recipes/internals, I'm asking here. I'm having a build error in the do_rootfs task of two images for two different images. The error message is the following: Jul 02 11:51:09 Exception: FileExistsError: [Errno 17] File exists: 'tmp/sysroots-components/aarch64/glibc-initial/usr/include/complex.h' -> 'tmp/work/foo-machine-poky-linux/foo-image/1.0-r0/recipe-sysroot/usr/include/complex.h' Jul 02 11:51:49 qschulz: glibc-initial shouldn't be being installed there Jul 02 11:52:07 qschulz: also tells me you're using something pre-warrior as we got rid of glibc-initial Jul 02 11:52:35 RP: yes, thud 2.6.2 Jul 02 11:52:57 qschulz: our test builds don't show that so what you've done to trigger it, I don't know Jul 02 11:53:23 GMBRKBNBRGJVERGVJEUG, let the whack-a-mole begin then :( Jul 02 11:54:21 RP: Sometimes it fails on `tmp/sysroots-components/aarch64/libgcc-initial/usr/lib64/aarch64-poky-linux/8.2.0/crtendS.o` Jul 02 11:54:24 the same reason Jul 02 11:54:50 qschulz: if its the do_rootfs task, have a look at the do_rootfs log file and see why its installing *-initial Jul 02 11:55:08 There is code specifically not to install -initial Jul 02 12:02:09 RP: Direct dependencies are ... glibc-initial:do_populate_sysroot, gcc-cross-initial:do_populate_sysroot, libgcc-initial:do_populate_sysroot Jul 02 12:03:40 qschulz: ok, direct dependencies sounds ominous as I don't think it would be Jul 02 12:26:07 RP: mmmm, most likely the DEPENDS = "u-boot" in the image recipe was not the best idea :) anyway, changed that to EXTRA_IMAGEDEPENDS Jul 02 12:26:49 qschulz: interesting. I wouldn't have expected that to break it but it certainly could Jul 02 12:27:30 RP: now I've got the same issue but with libxcrypt and glibc-initial and the crypto.h file Jul 02 12:32:21 qschulz: another direct dependency? Jul 02 12:34:15 I guess so :/ Jul 02 13:13:21 RP: Sorry, I should have made it more clear that those two patches were related Jul 02 13:14:08 New news from stackoverflow: Compiling issue with Boost asio Jul 02 14:29:21 JPEW: I was thinking it was a test for the existing option, things make sense now! Jul 02 14:29:31 JPEW: hadn't gotten to looking at the bitbake list yet Jul 02 14:29:57 RP: np Jul 02 14:39:59 RP: making progress.. I discovered that we have a task in the image that depends on another image Jul 02 14:40:37 basically we have an image which builds a fitimage which requires another image (think of an image having a rescue image in it) Jul 02 14:41:22 `do_generate_swupdate[depends] += "swupdate-image:do_build"` Jul 02 14:41:45 is that the correct way to do it? (one image depending on another one?) Jul 02 14:43:53 qschulz: it should be ok, I could also imagine its possible to cause problems Jul 02 14:46:32 RP: weirdly enough, replacing it by do_generate_swupdate[depends] += "swupdate-image:do_image_complete" (do_build by do_image_complete) make the build ok Jul 02 14:47:01 qschulz: that actually makes sense to me... Jul 02 14:48:00 is there some magic done when you depends on a do_build? (like... installing something in a sysroot :) ?) Jul 02 14:48:26 hello, is there any example/doc about the syntax of LAYERDEPENDS ? For example if Y have a meta-custom that needs meta-java. Jul 02 14:50:24 https://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#var-bb-LAYERDEPENDS doesn't help much Jul 02 14:51:07 is there a recipe anywhere for busctl, the dbus command line utility? Jul 02 14:51:08 LATERDEPENDS_custom = "meta-java" or = "java-layer" or what else? Jul 02 14:51:19 qschulz: do_build has a recrdepends on other tasks which means you injected a lot of tasks into that point in the build Jul 02 14:51:52 s/LATERDEPENDS/LAYERDEPENDS Jul 02 14:52:33 mckoan: meta-openembedded has some examples: e.g. `LAYERDEPENDS_perl-layer = "core openembedded-layer"` Jul 02 14:52:56 I beleive the name has to match the name the layer gives itself in it's conf file Jul 02 14:53:56 YPTM: Armin is on Jul 02 14:58:06 armpit: early! :) Jul 02 14:59:25 on the yocto ml: But I had almost Jul 02 14:59:29 a billion of errors and I am so bored Jul 02 14:59:38 Jul 02 15:00:01 * LetoThe2nd is bored too. Jul 02 15:00:02 YPTM: Michael joined Zoom Meeting: https://zoom.us/j/990892712 Jul 02 15:01:32 * armpit oh, someone flashed me Jul 02 15:02:02 armpit: heh, I accidentally clicked the video button Jul 02 15:02:17 YPTM: scott is on Jul 02 15:03:24 YPTM: Joshua Watt here Jul 02 15:03:49 YPTM: tlwoerner here Jul 02 15:04:26 JPEW_: top marks for your reproducibility stuff btw Jul 02 15:04:31 (can't join the call to say that in person) Jul 02 15:04:49 rburton: Thanks! Jul 02 15:09:19 RP: I'm confused, I don't really understand what's happening behind the scenes to make it work with do_image_complete and not do_build Jul 02 15:10:08 Why is it trying to install files in the sysroot of my imagea recipe when I depend on imageb.do_build but not when I depend on imagea.do_image_complete /o\ Jul 02 15:13:48 qschulz: depending on do_image_complete probably is the right thing anyway Jul 02 15:14:13 rburton: but now I need to scratch this itch :D Jul 02 15:15:37 (and also, I don't like committing things that I don't understand/can't argue, and it's absolutely impossible to me to do a empty commit log since I'm fighting for people to write meaningful ones :) ) Jul 02 15:22:19 YPTM is concluded. Jul 02 15:22:20 YPTM: is over Jul 02 15:22:57 qschulz: do a "bitbake imageb -c do_image_complete -g" and look at task-depends.dot, then do the same but with -c build Jul 02 15:23:24 qschulz: you'll see a lot more dependencies. Its those extra dependencies muddying the water for the sysroot generation code Jul 02 15:24:02 Hi, compiling older meta-freescale etc nxp layers with poky master. looks like devicetree files no longer get symlinks with KERNEL_IMAGETYPE in the names, but kernel still does. Is this intended? need to adapt sdcard image types of meta-freescale to not expect that Jul 02 15:24:48 mcfrisk: not sure, I'd check the commits to see what caused it and whether it was intentional Jul 02 15:27:04 huh SRC_URI=http://git.yoctoproject.org/cgit/cgit.cgi/${BPN}/snapshot/${BPN}-${PV}.tar.gz looks *very* wrong Jul 02 15:27:19 rburton: where is that? Jul 02 15:27:51 oh sorry :) Jul 02 15:27:53 opkg-utils Jul 02 15:30:08 the checksum matches now but if we upgrade the server then that can potentially change Jul 02 15:30:26 rburton: indeed Jul 02 15:30:42 rburton: we should ask adelcast about that Jul 02 15:30:49 RP: I see some major changes in meta/classes/kernel-devicetree.bbclass but I can't see how kernel recipes should be adapted.. only this one symlink is missing with path "${DEPLOY_DIR_IMAGE}/${KERNEL_IMAGETYPE}-${DTS_BASE_NAME}.dtb", dropping KERNEL_IMAGETYPE seems to be the fix Jul 02 15:31:43 mcfrisk: I've asked for more tests in this area, I don't use dtbs often enough to know what makes sense :( Jul 02 15:33:00 RP: no problem, I found a fix/workaround then. Jul 02 15:40:41 hello. i am curious about people's opinions or recommendations for system update mechanisms that can perform delta updates, to be cost-efficient over cellular networks. Jul 02 15:40:54 https://rauc.readthedocs.io/en/latest/advanced.html#creating-casync-bundles looks very interesting, has anyone used it? Jul 02 15:46:36 RP: wow, scary. i was 100% certain i had sent an email regarding the pigz issue to the list, turns out i hadn't. i wrote notes about it in my notebook, and i mentioned it on IRC. i'll create an email with all the details. Jul 02 15:47:25 RP: in the meeting i said i was using version 1.0.6. oops.. wrong utility. that's pixz 1.0.6, my machine has pigz 2.3.3 Jul 02 15:49:54 tlwoerner: that makes much more sense :) Jul 02 16:04:08 JPEW: does this mean that a layer 'meta-openembedded' have to become "openembedded-layer" in LAYERDEPENDS? Jul 02 16:04:43 JPEW: I wonder why is not called 'meta-openembedded', that's confusing Jul 02 16:05:19 too late to do much about it now due to LAYERDEPENDS from other layers Jul 02 16:08:24 kergoth: JPEW: however could we say that the syntax is to replace the prefix 'meta-' wit a postfix '-layer' in the LAYERDEPENDS? Jul 02 16:09:09 no, plenty of layers do not use a -layer suffix Jul 02 16:09:15 mckoan: It is annoying, but you have to just look in the layer.conf for each layer to determine it's name Jul 02 16:09:15 there's a lack of consistency there Jul 02 16:11:52 * armpit or a strong support of inconsistency Jul 02 16:12:25 JPEW: sounds clearer now, do you men to refer to BBFILE_COLLECTIONS like in meta-oe is BBFILE_COLLECTIONS += "openembedded-layer" Jul 02 16:12:38 mckoan: Correct Jul 02 16:13:48 we could probably add a provides mechanism and then fix the names Jul 02 16:14:04 JPEW: do you mean to refer to the value of BBFILE_COLLECTIONS in the layer I want to depend onto? like in meta-oe is BBFILE_COLLECTIONS += "openembedded-layer" Jul 02 16:14:19 oops, sorry the double post Jul 02 16:14:42 New news from stackoverflow: How to Make a FULL Yocto eSDK Sysroot to Do CMake Cross-Compilation? || devtool clones the wrong repository for recipe development Jul 02 16:14:42 JPEW: thank you very much for this clarification Jul 02 16:14:49 np Jul 02 16:15:08 RP: may I suggest to describe this in the manual? Jul 02 16:16:00 mckoan: I would love someone to explain it to Scott who would update the manual it someone did that Jul 02 16:16:20 JPEW: btw, the bzip upgrade in -next will break mingw Jul 02 16:16:49 OK Jul 02 16:16:58 RP: LOL Jul 02 16:26:38 mckoan: file a bug and explain it, or send scott an email, seriously Jul 02 16:39:26 RP: ok, as soon as I have some spare time Jul 02 19:30:55 does the bitbake inline conditional support logical 'and'? it's a bit un-googlable unfortunately: "${@['foo', 'bar'][condition]}" Jul 02 19:43:17 bluca: It's inline python.... not sure what you mean by "logical and" Jul 02 19:43:41 ah what's in the [ ] is python? interesting Jul 02 19:44:08 bluca: Everything between "${@" and "}" is python Jul 02 19:44:25 right now condition is ['foo' != 'bar'] - I'd like ['foo' != 'bar' && 'foobar' != 'baz'] Jul 02 19:44:52 thanks, I'll try with python's keyword Jul 02 20:22:23 RP: master-next of meta-mingw has the bzip2 fix Jul 02 20:58:35 JPEW: great, that change has been tested so I can merge, I'd best try and do that when we're both around! Jul 02 21:00:12 Sounds good. I'll be around tomorrow, but then gone till monday Jul 02 21:00:28 JPEW: tell you what, if you're here now... :) Jul 02 21:01:20 Ya, for another hour Jul 02 21:01:28 JPEW: its in :) Jul 02 21:03:27 JPEW: I guess I could have just merged the branch too now I think about it... :) Jul 02 21:04:00 lol, ya probably. Jul 02 21:04:18 Blame it on the end of the day Jul 02 21:04:35 JPEW: just been cycling, still to get food :/ Jul 02 21:05:56 Alright pushed. I upstreamed the patch, so hopefully next update we can just delete the whole thing from meta-mingw Jul 02 21:11:30 JPEW: great, particularly now we have a new working upstream! :) Jul 02 21:11:42 thanks Jul 02 21:53:33 bluca: the [foo,bar][condition] thing is horrible and please don't use it if you can help it Jul 02 21:53:57 "foo if condition else bar" is more readable and as you can see, understandable as python :) Jul 02 21:54:26 [foo,bar][cond] works because its making a list of [foo, bar] and then indexing it by coercing cond to an integer 0 or 1 Jul 02 21:54:28 ICK :) Jul 02 22:03:51 rburton: it's an existing recipe, so not up to me :-) Jul 02 22:04:04 but yes it is not very readable Jul 02 22:45:40 New news from stackoverflow: Up-to-date recommendations for yocto build host version **** ENDING LOGGING AT Wed Jul 03 03:00:28 2019