**** BEGIN LOGGING AT Tue Oct 20 09:24:02 2020 Oct 20 09:28:11 qschulz: I saw it and queued it, thanks Oct 20 09:28:41 qschulz: thanks for verifying. I'll do better to handle them as they come in going forward. I was confused over what I was doing vs what nico was doing Oct 20 09:30:54 RP: absolutely no worries. Also, as you said, docs can be merged later and you've already a lot to do for the upcoming release. Thanks for merging the patches! Oct 20 09:33:05 . I want to add a line "nameserver 8.8.8.8" to /etc/resolv.conf. I tried two ways. Oct 20 09:34:22 How can I modify the /etc/resolv.conf in yocto built image? Oct 20 09:41:53 Hi, again a QA problem which I dont know how to solve it: "ERROR: QA Issue: -dev package contains non-symlink .so: external-arm-toolchain-dev path ". The package is called "external-arm-toolchain". Oct 20 09:42:26 The funny thing about is, that exactly the same yocto source configuration builds on another PC without this QA Error Oct 20 09:43:09 Even if I do -c do_cleanall, and rebuild the package, the QA error appears. Oct 20 09:45:02 I suspect, that a "-c do_cleanall" does not remove "everything" of external-arm-toolchain. Could this be possible? Oct 20 09:57:40 ThomasD13: external toolchains are complex/tricky things. Its difficult to know what is going on without debugging that :/ Oct 20 10:01:17 Okay. I'm just curious, that this error appears. I'm using exact same yocto configuration and build commands. Just on a different host. However I noticed that the host (with the error) only provides 2 CPUs. The host without error has 8. Maybe thats the reason. Oct 20 10:01:57 I'll try to reduce the parallel yocto jobs and gcc threads for the 2 core machine, and rebuild everything from scratch. Oct 20 10:02:03 As last resort ;) Oct 20 10:03:25 ThomasD13: it definitely could be some kind of race from a missing dependency Oct 20 10:03:53 ThomasD13: was that the exact error message? it's badly formatted. Oct 20 10:04:59 rburton, https://pastebin.com/jbrKKLHT Oct 20 10:04:59 ThomasD13: what did you set EAT_VER_MAIN to? Oct 20 10:06:02 my top tip is don't use external-arm-toolchain :) Oct 20 10:07:06 rburton, EAT_VER_MAIN: I don't know. I just deleted everything and startet rebuilding the image from scratch. It will take some hours. I dont want to waste your time, when this was just a kind of race condition :) Oct 20 10:07:33 But I will tell you, if the error persists Oct 20 10:08:39 ThomasD13: What's your DISTRO set to for your build? Any other layers you're including? I know of a few which have known QA issues Oct 20 10:08:50 And about external-arm-toolchain: I don't have enough time to understand what exactly happens, and how to avoid it :D I just relay here on ti Oct 20 10:10:42 paulbarker, https://pastebin.com/KwX1W7NW Oct 20 10:10:51 Thats my build configuration Oct 20 10:11:38 ThomasD13: QA issues are a fact of life with Arago. I use it extensively. I just see "HEAD" as the branch name for all your layers, are you building against dunfell? Oct 20 10:12:01 Did you use the `oe-layersetup` tool or checkout all the layers yourself Oct 20 10:13:37 paulbarker, I building against dunfell. I used oe-layersetup to checkout the latest psdk_07_00_01 configuration. I separately store the state of source-git-repositories and restored them. I think this is why "HEAD" appears on the layer configuration info Oct 20 10:14:44 ThomasD13: I don't think 07.00.01 is properly released yet. I've been following the tags in meta-arago, meta-ti and ti-linux-kernel but I don't see a final tag yet Oct 20 10:16:23 paulbarker, thats interesting: I work with the TDA4VMX, and use PSDKLA release from June 2020. This has version 07_00_01. Inside of that SDK, there is a psdkla-07_00_01.txt file, which holds the arago configuration (which should be used for yocto builds) Oct 20 10:16:47 ThomasD13: Oh ok. We may be mixing up version numbers Oct 20 10:16:50 But anyway, I'm very glad to hear, that I am not the only one which uses arago :) Oct 20 10:17:18 ThomasD13: You're using ProcessorSDK, I think what I'm using is referred to as CoreSDK (or it used to be) Oct 20 10:17:58 ah okay. I dont know CoreSDK. For which SoC do you use arago? Oct 20 10:18:53 I use the kas tool but you can probably figure out the config format easily enough. See https://github.com/SanCloudLtd/meta-sancloud/blob/dunfell/kas/bbe-arago.yml and other files under the kas directory in that repo Oct 20 10:19:14 The BeagleBone Enhanced (BBE) is based on the old AM335x SoC Oct 20 10:19:43 I also worked with Keystone 2 SoCs a lot back in 2015-2017 Oct 20 10:21:31 Ahh cool! I used BBB (BeagleBone Black) to evaluate the PRU's for very first time. After that I gone up from AM4*/AM5*/AM65* and now on Jacinto Platform Oct 20 10:41:37 is there a way to know which **direct** DEPENDS pulls some files in the sysroot? E.g., A depends on B which depends on C. I know the file come from C, but I want to know which recipe is B. Oct 20 10:45:38 recipe A is qtbase and recipe C is openssl so looking at recipe-depends.dot or task-depends.dot is very inefficient right now :/ Oct 20 10:45:53 (it's not the packageconfig in qtbase BTW) **** ENDING LOGGING AT Tue Oct 20 10:59:57 2020