**** BEGIN LOGGING AT Mon Dec 09 04:43:06 2019 Dec 09 09:48:58 khem: FWIW the binutils upgrade looks fine on the AB Dec 09 09:51:45 hi! is there a way to remove inherit from a recipe with bbappend? Dec 09 09:51:55 New news from stackoverflow: How to exclude opencv compilation from Yocto image? Dec 09 09:54:31 sashko: no, i dont' think so. Dec 09 10:01:29 sashko: not really, no Dec 09 10:01:49 thanks! Dec 09 10:10:42 khem: binutils looks fine Dec 09 10:31:19 PY2 IS NOT LONGER A HOST REQUIREMENT THIS IS NOT A DRILL PY2 IS NO LONGER A HOST REQUIREMENT Dec 09 10:31:45 if it wasnt 10am i'd crack open a gin to celebrate Dec 09 10:32:18 rburton: so, why not? Dec 09 10:36:11 rburton: haha :) Dec 09 10:36:18 Its nice to reach this point Dec 09 10:39:10 drinking at 10am? Dec 09 10:39:12 hell yeah! Dec 09 10:59:15 is there some variable that is unique to a bitbake run? Dec 09 10:59:29 LetoThe2nd: DATETIME ? Dec 09 11:00:09 RP: will cause headaches probably, as it triggers the non-deterministic warnings Dec 09 11:00:26 LetoThe2nd: so you just vardeps exclude it? Dec 09 11:02:00 but then it will lift the recipe out of being run i only DATETIME has changed, right? Dec 09 11:06:36 yup Dec 09 11:08:24 LetoThe2nd: what do you want to do with this unique variable Dec 09 11:09:27 rburton: we're still trying to tackle a problem with inter-multiconfig dependencies that are caused by specific image types. Dec 09 11:11:12 but we're really, really close to just stick in a nostamp on the fetching task in the depending multiconfig recipe by now, so much human time has already been burnt that the additional cycles start to appear cheaper. Dec 09 11:17:21 RP: doing a build spin of next here before giving it my +1 :) Dec 09 11:20:09 rburton: fair enough Dec 09 11:22:11 New news from stackoverflow: How to get the ARM tool chain with poky? || Having Angstrom build and Poky build in one repository Dec 09 11:32:22 RP: thanks, I probably was far too optimistic about the big upgrade patchset. Certainly should be approached piece by piece. Dec 09 11:33:34 kanavin__: I'd pushed out all the problem pieces I could spot and -next is now building ok. I'll probably take -next as it stands and build M1 with that, then we can work through the problematic pieces in M2 Dec 09 11:54:06 RP: next looks good Dec 09 11:55:40 rburton: cool. I shall merge. Does this mean we're ready for M1? Dec 09 11:55:52 rburton: there are other patches around but I think we draw the line here? Dec 09 11:56:10 just rebasing mut to see what else i had hanging around Dec 09 11:56:22 oh theres a cve fix which might be super useful Dec 09 11:56:49 rburton: which one? Dec 09 11:56:58 the cve-check one Dec 09 11:57:00 rburton: master updated fwiw Dec 09 11:57:07 rburton: ah, the version one Dec 09 11:57:14 right Dec 09 11:57:21 just testing now Dec 09 11:57:40 rburton: ok, let me know. Tempted to then roll M1 Dec 09 11:59:29 upstream-status fix on the list ;) Dec 09 12:00:26 rburton: ah, will merge Dec 09 12:05:12 cve check fix appears to be fine Dec 09 12:05:21 rburton: instantly have another 10 patches in -next, including live removal Dec 09 12:05:32 rburton: M2 though I think Dec 09 12:05:35 yes Dec 09 12:05:47 i need to double check all the other bits about live removal Dec 09 12:06:24 rburton: I will trigger M1 then, thanks Dec 09 12:20:17 RP: fire in the hole! Dec 09 12:28:23 maybe a dumb question, but can't qemuarm machine config have a UBOOT_MACHINE ? Dec 09 12:30:21 Ad0: you could probably make it use one, but its uncommen. Dec 09 12:30:29 ok Dec 09 12:31:51 Ad0: for most people it like, "u-boot get out of my way as quickly as possible". and as qemu can directly boot into a kernel, theres no reason even to get *into* your way first. Dec 09 12:32:13 I see Dec 09 12:35:04 RP: I am not sure I understand the errors here, particularly the at-spi2 stuff seems to be building a previous version rather than the one I sent an update for? http://errors.yoctoproject.org/Errors/Latest/?filter=2cfc5dd223815df65d2001a6a9c352eadf936f94&type=commit&limit=150&page=1 Dec 09 12:35:47 kanavin__: It could well be I got lost in the patches with that. I dropped them simply as I was hitting failures and couldn't quite see what was wrong Dec 09 12:36:24 RP: right, or maybe you dropped at-spi2-atk, but not at-spi2-core or atk, and that caused a mismatch Dec 09 12:37:37 kanavin__: right, its possible. I had to do something to try and partition the problems so I was pretty ruthless with failures. Rsend them in the next batch and we can test in isolation with the right patchset Dec 09 12:39:06 RP: yep, generally centos 7 seems to be getting in the way of updates more and more lately :-/ Dec 09 12:39:36 kanavin__: right, we are working on centos8 but that has different problems michael is working on Dec 09 12:52:26 New news from stackoverflow: Yocto / OE : recipe with CMake install a shared library .so Dec 09 14:03:08 Are here some linux memory specialists? :) Regarding physical and logical addresses (ioremap vs phys_to_virt) Dec 09 14:10:55 ThomasD13: you have a considerably higher chance of getting an answer if you ask about your *actual* problem Dec 09 14:11:26 * zeddii sees armpit’s question / comment from last night .. I pushed the kernel-cache update this morning. Dec 09 14:16:33 Thats the way to go: I'm on a AARCH64 device. I allocate via "request_mem_region" 256 MB starting from physical address 0x4000 0000. After mapping this memory via "ioremap_nocache" into kernel virtual address space, I have noticed a difference when I use "phys_to_virt" function. Dec 09 14:17:48 I am trying to include mono in my image, so I have cloned the meta-mono layer and checkout out the branch for my Yocto version (sumo). When I try to include Yocto I get the following error: nothing provides mono-gac needed by mono-5.12.0.226-r0.aarch64 Dec 09 14:18:03 I'm little bit confused about this. I thought the purpose of phys_to_virt should be to translate physical addresses to virtual ones. Dec 09 14:18:27 But the address I got from phys_to_virt seems to be wrong in my case. Dec 09 14:18:40 But the mono-gac package SHOULD be provided by the mono-package itself. If I do bitbake mono-gac I get: mono RPROVIDES mono-gac Dec 09 14:23:16 iceaway: there's a difference between provides and rprovides. provides is used to resolve DEPENDS and is at least the name of the recipe (can be something else if there's a PROVIDES set in the recipe). rprovides is for packages so either to resolve RDEPENDS or IMAGE_INSTALL, RRECOMMENDS, etc... Dec 09 14:25:09 qschulz: ahhh did not see the little 'r' there. Dec 09 14:31:09 If I do "bitbake -e mono" and look for DEPENDS, it does not DEPEND on mono-gac but it RDEPENDS on it. Not sure if that makes me any the wiser though on how to resolve this. Dec 09 14:33:56 I don't remember how the error message is crafted, but might be that a dependency if mono is missing mono-gac Dec 09 14:34:09 if/of/ Dec 09 14:38:18 So If I only include mono in my image (which depends on mono-gac), would not bitbake automatically pick up and build/include the mono-gac dependency? Dec 09 14:39:34 it does not depend on mono-gac, it rdepends on it is what you said Dec 09 14:39:51 but yes, however it should be an issue at build time, what the error message you sent is saying Dec 09 14:48:21 iceaway: can you paste somewhere the whole error log? Dec 09 14:50:00 qschulz: sure! give me a minute. Dec 09 14:52:35 Hi, can somebody explain to me how the do_merge_delta_config task in the linux recipe (imx) is supposed to work? I get the merged defconfig in the WORKDIR but it doesnt seem to be used. Do i need a extra task to copy it somewhere? (The recipe: https://pastebin.com/rYfLSAbz) Dec 09 15:00:48 qschulz: https://pastebin.com/dMNjTPVV Dec 09 15:09:59 just found out, that the correct merged config is in './build/config.old'. But the '.config' contains the unmerged config. Any ideas? Dec 09 15:12:51 iceaway: the recipe looks correct though. PACKAGECONFIG ??= "gac" and PACKAGECONFIG[gac] = ",,mono-gac" with mono-gac being a package with files defined in FILES_${PN}-gac Dec 09 15:16:02 fl0v0: what's run after merge_delta_config? (i'm looking for preconfigure task especially) Dec 09 15:18:39 qschulz: Yeah I think it looks reasota Dec 09 15:18:43 reasonable too. Dec 09 15:19:52 qschulz: do_preconfigure is run after merge_delta_config Dec 09 15:20:20 do_merge_delta_config (30346): log.do_merge_delta_config.30346 Dec 09 15:20:21 do_copy_custom_device_tree_files (30345): log.do_copy_custom_device_tree_files.30345 Dec 09 15:20:21 do_preconfigure (30774): log.do_preconfigure.30774 Dec 09 15:20:41 this is an excerpt from log.task_order Dec 09 15:22:52 fl0v0: I meant what's inside that task. If you can point a git repo with the file with that task it'd be good help I think Dec 09 15:23:26 rburton: hashequiv build breakage on rc1. After it all worked :/ Dec 09 15:23:39 damnit Dec 09 15:25:25 qschulz: there seems not much to be happening in that task :/ thats the whole log: Dec 09 15:25:25 DEBUG: Executing shell function do_preconfigure Dec 09 15:25:25 DEBUG: Shell function do_preconfigure finished Dec 09 15:27:29 i try to find it. it must be inherited by recipes-kernel/linux/linux-imx.inc Dec 09 15:29:12 This file is here https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/recipes-kernel/linux?h=thud Dec 09 15:30:43 what on the other hand includes the poky kernel.bbclass Dec 09 15:32:32 RP: Have a link? Dec 09 15:33:05 https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/673 https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/1344 Dec 09 15:33:11 JPEW: ^^^ Dec 09 15:33:20 rburton: I think the last piece for reproducible core-image-sato and core-image-full-cmdline is your pod2man changes Dec 09 15:33:27 qschulz: found it https://git.yoctoproject.org/cgit/cgit.cgi/meta-freescale/tree/classes/fsl-kernel-localversion.bbclass?h=thud Dec 09 15:33:32 JPEW: probably https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1335 too Dec 09 15:34:16 JPEW: and https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/1335 is something different Dec 09 15:40:34 RP: Looks like the sstate object that it's looking for isn't actually in the sstate cache? Dec 09 15:40:51 a31ad8d78bc45b8575eac43b477679ce2c4c211a39a72503b71fa251db700edb Dec 09 15:41:31 JPEW: right, question is why it selected that object in the first place :/ Dec 09 15:41:59 JPEW: I was looking at the OE-Core one Dec 09 15:42:03 RP: Did you add in the code to check for the existence of sstate objects before accepting a unihash from the server? Dec 09 15:42:09 NOTE: Task /home/pokybuild/yocto-worker/qemuarm-oecore/build/meta/recipes-devtools/gdb/gdb-cross_8.3.1.bb:do_populate_sysroot unihash changed to 06d1a23427579c4e46c34048c11b1d78ac57c1da43f67810efd37450f8e9c43f Dec 09 15:42:17 That eSDK can't find that Dec 09 15:42:37 JPEW: woot woot Dec 09 15:42:41 JPEW: will finish and post Dec 09 15:43:01 JPEW: we have no choice but to accept unihashes from the server :( Dec 09 15:43:38 JPEW: question is how a unihash can exist but not be in sstate :/ Dec 09 15:43:44 RP: OK. I thought we had done some validation on them, but I think I misremember Dec 09 15:44:17 JPEW: you may be thinking of how we report equiv if sstate exists? Dec 09 15:44:29 RP: Yes, thats probably it. Dec 09 15:44:55 zeddii, thanks Dec 09 15:45:11 JPEW: I wonder if there was cleanup of the sstate cache we raced with :/ Dec 09 15:45:26 RP: Possibly. How often does that happen? Dec 09 15:45:55 JPEW: we age out things not accessed for 30 days Dec 09 15:50:41 RP: So, I suppose the hash equiv database doesn't get cleaned out at the same time? Dec 09 15:50:59 Because there really isn't anyway to do so (currently) Dec 09 15:53:35 JPEW: correct. I'm not 100% sure this what has happened here either, it would seem unlikely active sstate artefacts would be removed :/ Dec 09 15:58:00 qschulz: reordering the tasks seems to have helped. compiling now. Thank you for the pointer Dec 09 15:58:22 fl0v0: how did you re-order? Dec 09 15:58:37 addtask merge_delta_config before do_configure after do_patch do_preconfigure Dec 09 16:02:08 fl0v0: Quite confused by what they're doing here. Please test without sstate-cache as well to check that your modifications aren't benefitting from a side-effect ;) Dec 09 16:04:20 i just turned on optimization for size. if the binary is smaller after compiling, it should be working :) Dec 09 16:08:34 qschulz: yep it worked :) Dec 09 16:17:35 fl0v0: worth sending a patch to meta-freescale I think. At least to let them know it does not work as expected and that what you did fixed it. They may even come up with a better solution Dec 09 16:18:49 tlwoerner: I sent some patches for meta-rockchip, did you happen to see them? Dec 09 16:19:11 qschulz: i think its an error of variscite, not freescale. But have to check the other freescale recipes to make sure Dec 09 16:20:33 JPEW: that's awesome! thanks! no i haven't seen them yet, i'm deep in "the coding cave" ;-) Dec 09 16:22:36 JPEW: panfrost! w00t! Dec 09 16:22:51 the holidays have come early Dec 09 16:22:56 tlwoerner: Ya, it works reasonably well, and it's getting better all the time. Dec 09 16:24:29 * tlwoerner has a get-together planned with main panfrost developer for january :-) Dec 09 16:24:53 i'm glad to see it's (obviously) part of mesa now, last time i looked, it was still outside Dec 09 16:26:10 i'm hoping to get away from all that gpt stuff and move to wic sometime too... Dec 09 16:26:26 JPEW: I checked and that sstate artefact isn't there. I'm wondering if we could make hashequiv self healing Dec 09 16:26:43 tlwoerner: Ya. FWIW, you don't *have* to do GPT. Just writting the bits to the right offset is sufficent Dec 09 16:26:53 JPEW: i.e. when something is reported back, check sstate, if it exists, great. If not, send a delete request to hashequiv Dec 09 16:26:55 RP: Yes, thats what I was thinkng Dec 09 16:27:26 RP: Deleting might be more complicated... can we make the sstate artifact with the correct name? Dec 09 16:27:48 JPEW: hmm, maybe Dec 09 16:27:52 e.g. rename, or perhaps even re-run the sstate packaging task Dec 09 16:28:03 JPEW: probably not in all cases Dec 09 16:28:31 JPEW: for an initial change yes but not for one as things ripple out Dec 09 16:28:33 ... then i need better handling for kernel configs/defconfig Dec 09 16:29:23 tlwoerner: Ya, that would nice. Thankfully, the panfrost kernel driver is on by default for aarch64 and armv6 defconfigs :) Dec 09 16:29:33 s/armv6/armv7/ Dec 09 16:30:09 RP: Delete would be OK, but it might have consequences because you would have to remove all matching unihashes Dec 09 16:30:34 JPEW: could you change it to a different hash? Dec 09 16:30:54 RP: Ya, I just was thinking that. Rename them all to the taskhash of the task that just ran Dec 09 16:31:31 JPEW: armv6? Dec 09 16:31:48 tlwoerner: armv7 Dec 09 16:31:57 ah, sorry didn't see the ed line Dec 09 16:31:58 :-) Dec 09 16:33:57 JPEW: what if we don't have a task which just ran though? :/ Dec 09 16:36:27 By default TARGET_FPU is empty on AArch64, any reason for it? Dec 09 16:39:39 roussinm: isn't FPU non-optional on AArch64? Dec 09 16:40:01 (so it's probably on by default and can't changed?) Dec 09 16:42:05 tlwoerner: you mean the compiler knows which FPU to use? Dec 09 16:42:57 JPEW: wondering if I can somehow rescue the current build... Dec 09 16:43:23 JPEW: perhaps I just wipe the hashequiv DB :/ Dec 09 16:57:55 I have an image with NO_RECOMMENDATIONS ?= "1", but I would like to have the recommendations when I build the sdk ( bitbake my_image -c populate_sdk ). Dec 09 16:58:43 Right now we have added the NO_RECOMMENDATIONS to the extrawhitelists and exported in the cmdline, but it feels like a hack. Dec 09 17:15:20 RP: If we did the check at the time a unihash was reported as changed from the server that should be sufficent Dec 09 17:15:32 (because that is always in the context of a task) Dec 09 17:18:40 RP: In fact, I think if report_unihash() did a d.setVar('BB_UNIHASH', new_unihash), it might just work as expected Dec 09 17:19:09 sstate would make the object with the new unihash name, or do nothing because it already exists Dec 09 17:26:05 JPEW: I guess we could try a rebuild with that Dec 09 17:29:13 JPEW: fwiw i'm still seeing a number of buildpath warnings Dec 09 17:29:24 i've turned on buildpaths, which is a hint of something that will break reproducbile Dec 09 17:29:33 eg WARNING: libdnf-0.28.1-r0 do_package_qa: QA Issue: File /usr/lib/libdnf.so.2 in package libdnf contains reference to TMPDIR [buildpaths] Dec 09 17:31:11 JPEW: I'm just going to try it, risky but I don't have a better idea right now Dec 09 17:44:49 tlwoerner: just found a message from the mailing list saying that if it's empty, TARGET_FPU, that means default is hard for that architecture. Dec 09 17:46:23 roussinm: nice! (which is what i assumed and was trying to say above) Dec 09 17:47:03 rburton: Huh. I'll have to turn that on. I wonder why the test passes in that case... Dec 09 17:48:31 tlwoerner: just annoying that I had to search through the mailling list. Looking at the megamanual documentation, maybe it's something worth adding? Dec 09 18:36:01 roussinm: the tuning files, surprisingly, change often enough. keeping the doc in sync with the tuning files would be a lot of work, and risk a lot of confusion if ever they didn't agree. maybe a more general doc update explaining how machine configs point to tune files and how to read a tune file in general would be better? Dec 09 18:38:39 tlwoerner: it's surprising indeed. In that case, I would agree on a more general approach, yes. Dec 09 19:00:08 hm silly question, is the sdk supposed to be MACHINE-specific? Dec 09 19:01:53 would "/opt/${DISTRO}/${SDK_VERSION}" make a good alternative for SDKPATH? Dec 09 19:02:02 sorry, that's the current value in poky Dec 09 19:02:23 would ""/opt/${DISTRO}/${SDK_VERSION}-${MACHINE}" make a good alternative for SDKPATH? Dec 09 19:04:00 or perhaps even redefining SDK_VERSION as something like: Dec 09 19:04:30 SDK_VERSION = "${@d.getVar('DISTRO_VERSION').replace('snapshot-${DATE}', 'snapshot')}-${MACHINE}" Dec 09 19:10:43 is there a way to generate a package dependency graph? Dec 09 19:14:25 mischief: bitbake -g Dec 09 19:16:33 JPEW: i'm aware of the option but i don't care about the tasks. most of the edges in here are useless. i want to see what gets written into the package dependencies, not task dependencies Dec 09 19:19:31 in older versions, bitbake would generate several graphs - one of them was a graph of dependencies between recipes Dec 09 19:19:40 there was also a graph of dependencies between packages Dec 09 19:20:06 i dont know why they're gone now, these two were certainly more useful than the graph of tasks :/ Dec 09 19:20:31 huh, ya. I guess it doesn't do that anymore. Dec 09 19:20:53 i know i could probably extract a graph of recipes from the graph of tasks but it seems too difficult to figure out how to do that and then automate Dec 09 19:21:37 right.. i wasn't really looking to write a bespoke graph algorithm on monday morning. Dec 09 19:22:27 mischief: find the commit that removed the option to create a graph of recipes and revert it? Dec 09 19:22:52 i'd be interested to know why that option was removed though Dec 09 19:23:37 New news from stackoverflow: BitBake add tmux package to image Dec 09 19:24:12 https://github.com/openembedded/bitbake/commit/4c484cc01e3eee7ab2ab0359fd680b4dbd31dc30 Dec 09 19:24:31 hm okay Dec 09 19:25:06 mischief: That's not the one you are looking for Dec 09 19:25:23 mischief: You want the package-depends.dot file Dec 09 19:25:58 no such file is generated. Dec 09 19:26:38 msichief: Correct, but it used to be generated Dec 09 19:27:31 mischief: Find the commit that removed package-depends.dot, not the one that removed recipe-depends.dot Dec 09 19:30:50 https://github.com/openembedded/bitbake/commit/d3e182bc18ff2894f1efc8aad3d508dd432c996e Dec 09 19:30:59 doubt a revert would work but i guess i can try to patch it in Dec 09 19:38:58 mischief: Hmm, it does look like something was lost there when the package-depends.dot was removed. It doesn't look like the newer file outputs the runtime dependencies Dec 09 19:44:15 haha, even the file output by this is 1.6MB, making dot slow to a crawl still Dec 09 19:45:44 mischief: I've never actually bother graphing it, I just read through the text & grep for what I'm looking for Dec 09 19:54:28 same for me, i found that graphical representation is much more difficult to interpret, due to its size Dec 09 20:59:54 Why do I have to be at BUILDDIR to be able to invoke bitbake? Dec 09 21:07:00 in latest bitbake, you don't Dec 09 21:07:00 \o/ Dec 09 21:07:10 good reason to upgrade? Dec 09 21:09:03 We just upgraded to Zeus. Dec 09 21:09:11 Is it after? Dec 09 21:09:17 no Dec 09 21:09:34 sumo onwards, in fact Dec 09 21:10:04 that is with the oe-core/poky oe-buildenv-internal script, so if you've a custom distro that doesn't use that script then it needs fixing Dec 09 21:10:21 Oh man... I just saw... some senior at work hacked something, which prevents it.... Dec 09 21:10:27 oe-core 82eeb934997c9eaa6443079dfb649a89872a222c was the fix there Dec 09 21:11:07 We do have the script Dec 09 21:11:37 In a local.conf we do `require ${PWD}/../local.conf` Dec 09 21:11:57 That can't work unless you have at BUILDDIR Dec 09 21:12:01 are* Dec 09 21:13:00 thats horrible ;) Dec 09 21:13:15 use BBPATH? Dec 09 21:13:23 should be $(BUILDDIR) and is exported Dec 09 21:13:50 why a subshell? Dec 09 21:14:00 habit, ignore that Dec 09 21:14:14 BBPATH=$BUILDDIR Dec 09 21:14:14 export BBPATH Dec 09 21:14:17 says the script Dec 09 21:27:06 Hmm it fails because it tried to concatenate all the paths from the BBLAYERS paths. When using ${BBPATH} Dec 09 21:29:53 Oh I see, all the layers appends to the BBPATH variable. Dec 09 21:35:24 zeddii, I got a kernel oops on Arm for 4.18.45 on thud on the AB.. I need to triage it local and will open a bug if need be Dec 09 21:51:23 rburton: so in theory if we do `require ../company-local.conf` Dec 09 21:51:32 It should be "cleanish" ? Dec 09 21:51:43 company-local.conf sounds a lot like it should be site.conf in your own layer Dec 09 21:52:02 any file called conf/site.conf in a layer is included automatically Dec 09 21:52:13 site-wide settings that are not distro-specific Dec 09 21:52:17 everything else should be in your distro Dec 09 21:52:29 then your local.conf can be templated using your layer Dec 09 21:52:53 So you are saying that, for example, DL_DIR should be inside a layer? Dec 09 21:53:38 if its a company-wide setting then sure. sstate_mirrors is a good example if you have a central server. Dec 09 21:53:56 We use that company-local.conf for compagny wide settings. Dec 09 21:54:11 i'd look at moving that to site.conf then Dec 09 21:54:25 but that configuration file has to be the same for all machines. Dec 09 21:55:00 right, has to be generic settings Dec 09 22:00:02 Oh, but we have different directories for each machines `/builds/yocto/machine1..5`. When we source the environment we source for a specific machine. If we use site.conf it would be duplicate inside each machine? Dec 09 22:01:25 Maybe we shouldn't have a seperate directories for each machine? Dec 09 23:24:22 JPEW: still around? Dec 09 23:36:40 JPEW: Still erroring: https://autobuilder.yoctoproject.org/typhoon/#/builders/42/builds/1330 :( Dec 09 23:38:55 JPEW: I guess I'll need to check the patch actually did what we hoped/wanted it to :/ Dec 09 23:54:23 New news from stackoverflow: Add OP-TEE to Yocto Dec 10 01:23:56 RP:cool. Dec 10 01:24:34 I was hopeful that if it can build world with meta-openembedded for mips it can build anything :) **** ENDING LOGGING AT Tue Dec 10 02:59:58 2019