**** BEGIN LOGGING AT Sat Jan 23 02:59:57 2021 Jan 23 07:03:50 goodmorning sunshines Jan 23 07:04:17 is there a meta layer available for the lichee pi nano? I couldn't find it when googling, I only found https://github.com/voloviq/meta-licheepizero Jan 23 07:05:39 is it possible to tweak that one for the lichee pi nano? Jan 23 07:25:46 if I get no answer then the answer = yes Jan 23 08:26:35 Hi, I've got an Autobuilder question. Jan 23 08:26:49 Is there a way to manually over SSH on a yocto-worker as pokybuild3 quickly set up a build environment and add all the layers necessary to try debugging a recipe? Jan 23 08:28:30 mccc: for you on your own autobuilder? or in general? Jan 23 08:28:43 On my own autobuilder. Jan 23 08:29:35 Using yocto-autobuilder2 and yocto-autobuilder-helper Jan 23 08:29:58 mccc: I don't see why not. Failed build directories are usually left behind s easiest is just to go into a failed build directory Jan 23 08:30:17 mccc: you can just replay the commands from a build Jan 23 08:30:57 When I do, the layers have already been removed by the build. Is there a single script I can run to re-add all of the layers? Jan 23 08:31:05 And get the same environment? Jan 23 08:31:31 I tried setting the environment and running: Jan 23 08:31:45 mccc: you'd need to replay the commands the build ran Jan 23 08:32:33 Okay, thanks for the info. Jan 23 08:33:24 I'm still developing the workflow I'm using to debug build errors in my local autobuilder. Jan 23 08:33:29 mccc: there should be a run-config command its running which would take care of most things Jan 23 08:33:54 Well that's what I tried to paste above but didn't go in, Jan 23 08:34:14 I did copy and paste the run-config with --stepname add-layers from the add-layers step, Jan 23 08:34:37 but it didn't work, I'm guessing I either didn't have a prerequisite setup from running the previous commands, or something wasn't right in my environment. Jan 23 08:35:41 mccc: how recent is your yocto-autobuilder2? I ask as the code did change recently Jan 23 08:37:27 mccc: I think since you mention --stepname you're on the later version Jan 23 08:37:51 About a month and a half ago, but I can deploy one from 3 days ago, I'm building the yocto-autobuilder2 controller and worker images using.. the autobuilder :) Jan 23 08:38:25 mccc: the way the later version works, it queries the number of steps and then calls individually so each step is run with its own log output which displays better than one big log Jan 23 08:39:01 I think I have that change, it does have the "Check run-config steps to use" step. Jan 23 08:39:57 When I ran the "add-layers" step copied from the build, I got the output: Jan 23 08:40:00 Target task build-rhdev-build-image has 0 steps (1611391178.0: 0.0) Jan 23 08:40:21 mccc: right, you'll see a json output for that step which then lists the different run-config calls it will make Jan 23 08:41:23 mccc: I don't think I added a script which runs each of the commands as a single command as we've not needed that :/ Jan 23 08:44:22 Would there be any side effects if I suppressed the 'Remove layers' step? Would something like SSH in to the build machine, su pokybuild3, ./oe-init-build-env build-renamed, work then? Jan 23 08:44:52 mccc: first tip is to move build-renamed back to "build" Jan 23 08:45:40 it renames it so that other builds can't "see" things in their built paths. You could also disable that step for debuggning Jan 23 08:46:06 mccc: for debugging, disabling the step remove layers should be ok Jan 23 08:47:54 Okay I'll give that a shot. Rename to build, suppress remove layers, SSH in, set ABHELPER_JSON, run ./oe-init-build-env, and run bitbake... anything else pop to mind? Jan 23 08:51:05 Either way thanks again for the help, sincerely appreciate it. Jan 23 08:51:48 mccc: just remember the autobuilder writes to auto.conf, it doesn't change local.conf at all Jan 23 08:56:38 How does the autobuilder's execution of bitbake use auto.conf rather than local.conf? Jan 23 09:36:56 mccc: nothing autobuilder related, see bitbake.conf in oe-core Jan 23 09:57:52 Got it, thank you. Another thing I saw is the reason I wasn't able to run the add-layers step earlier is that oe-init-build-env will by default create a bblayers.conf that includes oe-core before add-layers runs as part of a normal build, but then remove-layers will remove the oe-core layer. When I later try and run the add-layers script, it won't be able to find bitbake.conf since that comes in via oe-core's layer. Jan 23 09:58:42 That's it for me tonight, thanks again. Jan 23 10:12:44 mccc: if you mv build-renamed to build, you should have the correct bblayers.conf Jan 23 17:26:48 hmm building my kernel `bitbake virtual/kernel` fails with this `Assembler messages: Error: .err encountered` error. One thing I realized when building is that it seems like it builds libc-5.4, though my kernel sources are 3.18. Could that be related? What is the part of my BSP that should tell it to build libc-3.18? Jan 23 17:29:06 Like I am setting `PREFERRED_VERSION_linux-skycontroller3 ?= "3.18%"` (my layer is called meta-skycontroller3), but I am not sure if this has any effect at all Jan 23 17:36:46 My bad, not libc-5.4 but libc-headers-5.8. Not sure if the kernel depends on libc, though 🤔 Jan 23 17:39:44 the libc headers need a configured kernel header, the kernel obviously doesn't need the libc Jan 23 17:44:44 I guess you will have to share the full kernel buld log if you want us to be able to help Jan 23 17:45:07 and my main guess is that your kernel doesn't support the compiler you are trying to use Jan 23 17:47:15 It took me too long to realize that a distro layer rarely provide image recipes, since they're orthogonal. Jan 23 17:49:04 Sorry, I'm new to kernel building 😅. Let me share the build output. My BSP (that I'm trying to write from scratch) is available here, if you are curious: https://github.com/JonasVautherin/meta-skycontroller3 Jan 23 17:52:02 abelloni: this is my log output: https://pastebin.com/gEia6KwS Jan 23 17:53:07 I have been running both `bitbake linux-skycontroller3` and `bitbake virtual/kernel` (I don't exactly get the difference yet), and I have been playing with my machine definition, but without success Jan 23 17:55:17 I still need to understand what a "distro" is. What does a distro layer typically provide, then? Just curious, I haven't read much documentation about that yet. Jan 23 17:59:12 jonesv[m]: the notion of distro in yocto can be tricky. I'm more like a compilation of preferred kernel, the libc to use (glibc, musl, etc.), the package manager of choice, a few core package pre-selected, etc. Jan 23 17:59:30 s/I'm/It's/ Jan 23 18:33:06 It's crazy because I have downstream kernel sources published by the manufacturer, and my BSP is super small, but still I can't even start to understand what that error means. Trying to read about machine definition and the compiler being used, as abelloni suggested... Jan 23 18:58:25 downstream development is fun for sure Jan 23 19:06:30 Well ideally I'd like to run an upstream kernel there, but I figured my best chance at running anything at all on this device is to start with their downstream one, right? Jan 23 19:06:46 Also that's a learning opportunity, of course Jan 23 19:17:06 yep, start with the official support, then try a mainline kernel Jan 23 20:02:45 right, that's what I'm trying, but failing 😅 Jan 23 22:41:27 I'm trying to figure out what layers I need to build an image for Marvell Armada 8040. I'm new to Yocto so if anyone can give me any tips on which layers I need and which config changes I need to make then I'd be very happy. Jan 23 22:45:38 I've seen some use meta-linaro layers. Is this the way forward for building aarch64 images? Jan 23 23:06:04 Gaffel, one resource to check it the layer index. http://layers.openembedded.org/layerindex/branch/master/layers/ Jan 23 23:06:40 if you have the BSP layer, the README should call out what layers it needs. if not ping the maintainer of that layer Jan 23 23:07:18 I don't know which BSP layer that I should go with. Jan 23 23:07:36 maybe Marvell has an unregistered layer Jan 23 23:08:56 I'm looking here: https://github.com/MarvellEmbeddedProcessors Jan 23 23:09:06 meta-marvell has no readme. Jan 23 23:09:27 And I don't understand the purpose of this repo: https://github.com/MarvellEmbeddedProcessors/marvell-embedded-linux-platform Jan 23 23:14:37 did you see https://github.com/MarvellEmbeddedProcessors/meta-marvell.git Jan 23 23:14:57 other than that, you are on your own or talk to Marvell Jan 23 23:15:06 Yup, okay. Thank you. :) Jan 23 23:23:16 aargh. Just getting crazy with that error. I don't get how I could be using the "wrong compiler" ☚ī¸ Jan 23 23:24:06 sounds like the build-time equivalent of a segmentation fault: "Something, somewhere, goes wrong. Good luck." 😀 Jan 23 23:32:35 Is there something that prevents Yocto gatesgarth from building a kernel v3.x at all? Like is it expecting 5.x? Jan 24 02:34:16 Aha! Somebody with the same error in postmarketOS suggested compiling with an older version of GCC. Could it be that kernel 3.18 needs an older version of GCC? I will try to make yocto do that, if feasible Jan 24 02:40:26 jonesv[m]: too recent gcc version is a common build error indeed Jan 24 02:40:54 Aha, I did not know that Jan 24 02:42:03 I see on StackOverflow somebody suggesting "PREFERRED_VERSION_gcc-cross-${TARGET_ARCH} ?= "5.2%"" to use GCC 5.2 Jan 24 02:42:28 I need to figure out which version to use for kernel 3.18.31 Jan 24 02:42:52 Also I am not sure where GCC will come from... Will yocto build it for me then? **** ENDING LOGGING AT Sun Jan 24 02:59:57 2021