**** BEGIN LOGGING AT Thu Mar 25 02:59:56 2021 Mar 25 03:16:47 RP: is it checking MACHINE in the metadata or in an environment variable? Mar 25 03:18:43 nm Mar 25 03:22:53 RP: does bitbake use a variable to determine where to check for a conf/local.conf, or does it just directly check /conf/local.conf? Mar 25 03:24:51 if the build directory is out-of-tree, how does bitbake know where the main poky folder is? Mar 25 03:27:30 yates: bitbake finds all config files and classes via BBPATH, which is altered by the layer.conf in each layer listed in BBLAYERS in conf/bblayers.conf Mar 25 03:28:02 yates: bitbake parses bitbake.conf from BBPATH after the layer setup, bitbake.conf in oe-core is what has a line to include conf/local.conf Mar 25 03:39:44 are meta-openembedded-contrib and meta-openembedded the same? so do openembedded-core and openembedded-core-contrib? the layout are the same, the files I checked(a few) are identical Mar 25 03:40:22 if not what's the difference Mar 25 04:10:22 kergoth: is there supposed to be a layer.conf in /conf/? Mar 25 04:12:07 if not, then BBPATH won't have a /conf/local.conf. is this reasoning correct? Mar 25 04:12:53 the standard oe-init-build-env does not create a /conf/layer.conf file Mar 25 04:14:05 my MACHINE is being defined in /conf/local.conf. is that the wrong place? Mar 25 04:27:51 kergoth: ? Mar 25 04:30:29 in any case, there is indeed a MACHINE ??= definitionin /conf/local.conf Mar 25 04:30:41 so it appears the error message is a lie Mar 25 04:31:46 what else is necessary for the MACHINE in /conf/local.conf to be seen by bitbake?!?? Mar 25 04:32:41 is the folder supposed to be in the BBLAYERS definition? i didn't think so, so i did not put one there Mar 25 04:33:46 here is my /conf/bblayers.conf: http://paste.ubuntu.com/p/WyD7Qv3pTD/ Mar 25 06:59:57 RP: seeing http://sprunge.us/RaB61x with "util-linux-libuuid: Simplify recipe" patch in master-next Mar 25 07:07:34 send a patch to meta-oe to rename the DEPENDS Mar 25 07:10:31 s/send/sent/ Mar 25 07:50:03 good morning Mar 25 08:19:00 yo dudX Mar 25 09:19:52 @LetoThe2nd: OIDA Mar 25 09:22:01 OIDA. Mar 25 09:34:05 OIDA Mar 25 09:34:15 khem: thanks! Mar 25 09:42:45 morning guys Mar 25 09:43:23 what's the preferred way to set up a docker container with a yocto sdk? Mar 25 09:44:26 i.e., is there any way to just install the rootfs portions of the sdk but without the env setup stuff? Mar 25 09:50:21 I tried publish mode (-p) without knowing what it exactly means but it still creates the two sysroots for sdk and nativesdk Mar 25 09:51:51 what I'm trying to achieve is a vs code devcontainer using a qemux86_64 sdk Mar 25 09:53:54 my best guess on how to do it so far is to install the sdk to a temporary location, e.g.: yocto-qemux86_64-toolchain-2.4.0.sh -y -d /tmp Mar 25 09:54:58 then mv /tmp/sysroots/qemux86-yocto-linux/* / Mar 25 09:55:49 and mv /tmp/sysroots/x86_64-yoctosdk-linux/* / Mar 25 09:56:14 mbulut: iirc there are at least 2 solutions for that, one of them is called CROPS Mar 25 09:56:51 I know CROPS, but afaik that is only for building a yocto project, isnt it? Mar 25 09:57:15 I'm using that already to build the yocto image and the SDKs Mar 25 09:57:59 mbulut: to me it is not clear what you want to do. build in a docker? package the sdk in a docker? build the sdk in a docker? Mar 25 09:58:02 how can the CROPS image be used to develop against the built SDK? Mar 25 09:58:34 I want to develop and debug applications using the SDK inside a docker container Mar 25 09:59:43 mbulut: for the esdk approach there is https://github.com/crops/extsdk-container Mar 25 10:00:11 I'll look into that, thx Mar 25 10:00:11 mbulut: for a classic sdk, i am not aware of anything out in the public. Mar 25 10:00:25 ok Mar 25 10:00:47 mbulut: for vscode, i would rather suggest to look at the stuff rob_w presented at last years vYPDD Mar 25 10:01:59 I heard about the extensible SDK before, but we haven't yet adopted that in our workflow so I was looking for the classic SDK path first but if the ext SDK path is easy to adopt I'll give it a try Mar 25 10:02:05 not me ... Mar 25 10:02:48 LetoThe2nd: do you have any pointers where to find that presentation? Mar 25 10:02:59 * LetoThe2nd points at google. Mar 25 10:03:23 :) :-* Mar 25 10:06:17 mbulut: for the sdk I have something, not published yet but still Mar 25 10:07:02 oh really? Mar 25 10:07:49 https://pastebin.com/qwiL8gCc Mar 25 10:08:55 we're using the resulting images to test cross-builds of our software in CI Mar 25 10:09:22 yann: do you mind me featuring this on ze tweets? Mar 25 10:09:46 LetoThe2nd: be my guest :) Mar 25 10:11:15 maybe it would be worth to have the "launch docker with this config" part too, but I fear it would require some tuning to be generally usable Mar 25 10:12:04 yann: do you have a @ handle i should include for your praise and glory? Mar 25 10:12:05 I should probably make this available as part of https://github.com/BladeGroup/gitlab-oe Mar 25 10:12:15 yann: if I interpret that Dockerfile correctly, this would still require running the environment-setup script before building anything right? Mar 25 10:12:39 LetoThe2nd: sorry I'm not on tweeter myself - maybe the company handle Mar 25 10:13:22 that would be @Shadow_Official Mar 25 10:14:28 mbulut: right Mar 25 10:14:29 I was looking for creating a docker image where the SDK was installed directly into the container's root folder, so I wouldnt have to hassle with environments and facilitate integration with vs code dev containers... Mar 25 10:15:07 mbulut: you can probably source the environment file from /etc/profile or similar Mar 25 10:15:15 yann: https://twitter.com/TheYoctoJester/status/1375028415443697668 Mar 25 10:17:01 * mbulut still scraping through https://www.youtube.com/user/TheYoctoProject/videos to find that darn vs code video^^ Mar 25 10:17:33 https://www.youtube.com/watch?v=PY4godidHx4 Mar 25 10:17:52 LetoThe2nd: is this what you were talking about? Mar 25 10:18:21 mbulut: should be, yes. Mar 25 10:18:31 thx Mar 25 11:41:05 why is ccache disabled for cmake recipes in cmake.bbclass? The introducing commit isn't that much helpful: https://cgit.openembedded.org/openembedded-core/commit/meta/classes/cmake.bbclass?id=5bb55610f3eb6bba0c04d57733ffa056705c5336 Mar 25 11:41:10 just being curious Mar 25 11:44:44 qschulz: given the patch date i would guess that it refers to problems with really old cmake versions, and it being stuck might be just bad luck. Mar 25 11:45:56 qschulz: that is a very old commit, names I've not seen in a while. We could try removing it and see what breaks Mar 25 11:46:59 RP: missing the red build in the autobuilder :D? Mar 25 11:47:28 qschulz: we get plenty already :/ Mar 25 11:53:32 am now trying to understand if something additional is needed to enable ccache? It seems CCACHE is set from ccache.bbclass but that class is never inherited. Mar 25 11:54:23 I guess CCACHE should just be set to ccache from the host since it's in hosttools? so probably CCACHE="ccache " would just work? Mar 25 11:54:27 (with the additional space) Mar 25 11:55:01 anyway, thinking out loud, not something I'll actively pursue for now since we're using icecc anyway and it disables ccache globally Mar 25 11:57:04 qschulz: there are tests for ccache if I remember rightly. To enable you INHERIT += "ccache" Mar 25 11:57:16 qschulz: seen that? https://crascit.com/2016/04/09/using-ccache-with-cmake/ Mar 25 11:58:31 LetoThe2nd: manual compilation already supports ccache in our project so I hopefully don't have to dig into this. But thanks for the pointer. Mar 25 11:58:48 qschulz: have fun Mar 25 11:59:26 hi, python problems. Lately everything using pypi and setuptools-scm started failing due to some changes in pypi. I'm wondering why meta/classes/setuptools.bbclass in poky does not DEPEND on "python-setuptools-scm-native", and instead pypi is used for everything which is now broken for a lot of of older python recipes.. Mar 25 11:59:27 LetoThe2nd: I think in the end bitbake just prepends CCACHE to CXX or CC so it should just be transparent for most? Mar 25 12:00:00 LetoThe2nd: https://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/bitbake.conf#n517 Mar 25 12:00:36 qschulz: sounds about right to me. Mar 25 12:01:08 RP: indeed, just don't like blindly doing a INHERIT in local.conf :p Mar 25 12:02:42 Should have read the ccache.bbclass before asking stuff around. Thx all Mar 25 12:04:10 @qschulz: OIDA :P Mar 25 12:52:37 @qschulz: I saw issues with ccache and toolchain versions ;) If the ccached stuff is in some directoy and you use a different version of the toolchain with old ccached stuff the party starts. Mar 25 13:02:29 RP: kergoth: not sure who's the best one to comment, but we've narrowed down our problems on the new superduper powered box to the usage of multiprocessing.cpu_count() in bitbake. this returns the number of physical cpus, which in our case substantially differs from the allocated cores. we can somewhat ad-hoc-ishly fix this by passing BB_NUMBER_THREADS and PARALLEL_MAKE for all builds, but actually we thing the better Mar 25 13:02:29 approach would be to use len(os.sched_getaffinity(0)). thoughts? Mar 25 13:05:43 *sigh* "we think". not "we thing". we are talking about a thing, but at least so far we're not objectifying ourselves. Mar 25 13:06:36 mroe background: https://bugs.python.org/issue36054 Mar 25 13:25:43 LetoThe2nd: congrats for your involvement in the book MELP.. (y) Mar 25 13:26:35 PaowZ: :) Mar 25 13:33:26 LetoThe2nd: people assume that BB_NUMBER_THREADS is not meant to be changed. Its a guess, you should set it to what makes sense in your environment Mar 25 13:33:46 LetoThe2nd: we set it to our own values on the autobuilder Mar 25 13:34:54 RP: yeah I also remember it being set verbose before the auto detection was introduced. but i think the "guessing process" might be improved, because this leads to really unexpected results. or at least it should be documented. Mar 25 13:35:45 qschulz: where's the new fancy docs man? Mar 25 13:35:55 LetoThe2nd: I don't think there is a any way to have a perfect answer and people should override it as needed Mar 25 13:37:21 LetoThe2nd: I know people complain about the memory implications on systems which are memory poor, core rich for example. Should we account for that? Also, if you're building webkit, you may need different values. And so on Mar 25 13:38:50 RP: perfect is probably impossible. but let me explain a bit: we're using a 256-core box now as a builder. but the devs "only" get allocated 32ish cores or such for personal use. so once we kick of personal builds, everything explodes at various staes of the build process, with no clear indication what caused it. until we realized that the guesses went to "256" Mar 25 13:40:48 so what i'm thinking about is either a more convervative guess - or a kind of warning if the guess is probably completely off. (which is not really complicated to detect. like, 256 threads but only 32GB RAM? probably don't fly) Mar 25 13:40:58 even if you change it to correctly detect 32 available cores, then 32 BB_NUMBER_THREADS and 32 PARALLEL_MAKE probably won't be optimal as RP mentioned Mar 25 13:41:39 LetoThe2nd: You can send a patch and you are probably correct that it is a more informed guess but I can just tell that everyone will use the opportunity to mention what they think the right value is Mar 25 13:42:12 RP: I guess that your educated guess about people guessing is.... right :) Mar 25 13:42:13 LetoThe2nd: there's no way for it to know if the machine is shared or not would seem to be the problem Mar 25 13:42:29 with 2GB ram per core I can still easily trigger OOMK Mar 25 13:42:43 on 64core threadripper with 128GB ram Mar 25 13:43:12 smurray: no,i'm really not talking about shared vs. not shared. just a kind of really trivial check if the ratio is really completely off. Mar 25 13:43:36 and if you ask me also a guess based on scheduled cpus, but that is debatable of course. Mar 25 13:44:38 LetoThe2nd: how are you allocating CPUs, putting the devs in a different cgroup? Mar 25 13:45:05 smurray: lxc Mar 25 13:46:02 LetoThe2nd: heh, so yes, a cgroup ;) Mar 25 13:46:28 smurray: technically yes. Mar 25 13:48:12 LetoThe2nd: it might be possible to detect that somehow. I know LXCFS does some stuff to overlay proc, but that's not used by all LXC users Mar 25 13:48:50 smurray: the python bug suggests an alternative Mar 25 13:51:04 LetoThe2nd: patches welcome, perhaps? If the result doesn't change for !container users it'd seem reasonable IMO Mar 25 13:51:42 smurray: my thinking too, but i wanted to get some feedback. it happens that i'm completely off too, as you all know. Mar 25 13:52:39 LetoThe2nd: docs.yoctoproject.org Mar 25 13:54:42 does the note concerning 20 still make sense here? http://docs.yoctoproject.org/ref-manual/variables.html#term-BB_NUMBER_THREADS Mar 25 13:59:01 LetoThe2nd: are you on a multi-CPU architecture? Mar 25 14:03:19 qschulz: 2 sockets, 64 cores each, and of those each HT Mar 25 14:03:41 -> 256 HT cores all in all. Mar 25 14:05:27 LetoThe2nd: from very vague recollection, I think rburton might have something to say on that matter? But honestly no clue otherwise. I don't know much about multi-CPU motherboards and the implication of such a setup :/ Mar 25 14:05:50 LetoThe2nd: I have no idea why that says "20", doesn't make sense Mar 25 14:06:32 RP: maybe because somebody wanted to avoid drinking age in some legislations? Mar 25 14:08:08 LetoThe2nd: I suspect 20 was crazy large when it was written Mar 25 14:08:50 LetoThe2nd: i find over 30-odd doesn't really give you any wins with build speed and stops I/O swarms from 256 jobs running unpack at once Mar 25 14:09:25 (lscpu says my build machine has 256 CPUs) Mar 25 14:09:41 rburton: so its actually a best effort guess from "some time on some box"? Mar 25 14:10:03 agreed, the results in https://github.com/shr-project/test-oe-build-time also don't show any significant increase over 16 Mar 25 14:10:09 yeah i thought 256 was stupid so cut it down a lot Mar 25 14:10:32 rburton: because we actually attached quite a bit of very fast pcie nvme storage to cope with the io Mar 25 14:10:48 rburton: 256 will give better parse times though Mar 25 14:10:51 LetoThe2nd: you're welcome to test bb-matrix on your own hardware Mar 25 14:11:14 RP: maybe the parse should just scale to number of CPUs automatically as its not long-lasting Mar 25 14:11:17 rburton: you can set BB_NUMBER_PARSE_THREADS (or something similar, I didn't check the name) Mar 25 14:11:24 i shall report back on that :) Mar 25 14:11:30 rburton: Y U no magic solution for me? Y I always worky times myself?!?!? Mar 25 14:11:35 BB_NUMBER_PARSE_THREADS yes Mar 25 14:11:50 max_process = int(self.cfgData.getVar("BB_NUMBER_PARSE_THREADS") or os.cpu_count() or 1) Mar 25 14:12:44 rburton: we effectively run every core at 100% during parse, we're pretty good at that bit Mar 25 14:13:41 ok, i slowly get where we need to tune our builds. Mar 25 14:19:12 RP: are build time metrics on autobuilder always executed on the same HW? is there some chart for longer period of time (like since zeus?) I'm seeing some significant increases every release and would like to confirm if the same is visible also on autobuilder Mar 25 14:20:48 e.g. chromium 79 with zeus took half hour, chromium 89 with recent hardknott takes an hour Mar 25 14:21:38 JaMa: they are, yes. The data is there for, longer periods, you'd just have to extract it Mar 25 14:55:06 halstead: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14318 What there a change going on, on the git server when this happened? CC RP Mar 25 14:57:24 vmeson: I have been working on the git server but I haven't interrupted services. Mar 25 14:58:32 I can define a machine which compiles only the bootloader, correct? Do I need to specify "dummy" as the virtual/kernel? Mar 25 14:59:41 vdl: as long as no part of the build then depends on the kernel, you can probably do that. Mar 25 14:59:56 halstead: ok, we'll close these bugs than. Also https://bugzilla.yoctoproject.org/show_bug.cgi?id=14320 -- fyi. Mar 25 15:01:15 LetoThe2nd: context is I'm defining a "machine" for dev to boot from tftp, I only need a configured bootloader on an SD card. Mar 25 15:01:38 halstead: closed that last one, can you close the first please? Mar 25 15:02:15 (I'm being the bug board jockey right now... ye haw! :) ) Mar 25 15:02:50 vmeson: okay. I'm checking into the server logs a bit more. Then I'll close it Mar 25 15:03:14 vdl: why not just compile the bootloader then? Mar 25 15:03:55 halstead: thanks. Mar 25 15:04:17 qschulz: and format an sd card myself, and document all that for the other devs, while I can have a yocto config for this? :) Mar 25 15:04:18 vdl: its just that sometimes bootloader do build libraries which might or might not have dependencies. thats all i'm saying. Mar 25 15:05:06 LetoThe2nd: you were very clear ;) Mar 25 15:14:28 vdl: create an image recipe with no packages in it and have it prepare your image to be flashed on sd card Mar 25 15:15:07 vdl: or you know... just make them change the environment or use a different command to boot and have the normal and tftp "commands" always in u-boot env Mar 25 15:15:14 and you switch depending on what you want to do Mar 25 15:16:27 qschulz: i actually think the approach is not bad, having an automated build from zero to dev sd card right from the beginning. Mar 25 15:16:51 vdl: essentially it would be just that, yes. an image with nothing in it other than the bootloader. Mar 25 15:17:50 LetoThe2nd: my point being, the same bootloader can be a production build or a dev build and you just run the correct command at boot from the bootloader to boot either from storage medium or tftp Mar 25 15:23:48 qschulz: you don't always want a bootloader to be configured for allowing tftpboot. You might have stronger requirement for prod. Mar 25 15:24:31 Such "machine" would allow to trigger a copy of the rootfs/dts/kernel images on the tftp server for example. Mar 25 15:25:34 Like bitbake mc:tftpboot:core-image-minimal would compile core-image-minimal.squashfs and copy to /srv/tftp for instance. Mar 25 15:27:01 vdl: for me, the copy to /srv/tftp shouldn't be handled by bitbake. It's a build system, not a CI/CD tool. But my 2¢ :) Mar 25 15:28:28 qschulz: you are correct though, an extended empty image recipe including only the bootloader and defining the wic format is actually better. The specific "machine" configuration would only simplify the dev process (as I suggested, a specific multiconfig would define the correct IMAGE_FSTYPES expected to tftpboot and so on) Mar 25 15:29:02 Come back qschulz :-( Mar 25 15:32:15 RP: so ionice doesn't apply to async IO while cgroups v2 io does Mar 25 15:32:40 LetoThe2nd: qschulz is right, a recipe for the SD card with only the bootloader in it would be better. The machine configuration might be optional, but handy to define the WKS_FILE, the default FSTYPE for the rootfs and kernel images, as well as preparing the image and kernel LINK_NAME expected by the bootloader. Mar 25 15:32:51 RP: this actually matters because I don't think anything during the build is using O_DIRECT or O_SYNC Mar 25 15:33:05 abelloni: hmm, interesting. Do you need permissions to use cgroups v2 io controls? Mar 25 15:33:39 I'll have to check :) Mar 25 15:35:49 qschulz: huh, did we disagree somewhere? Mar 25 15:36:33 * zeddii is watching the best presentation ever Mar 25 15:36:42 _best_ presentation Mar 25 15:37:38 seriously. I'm crying it is so good. Mar 25 15:37:48 and now the preentation goes to crap Mar 25 15:38:26 yah. now they are anger tears Mar 25 15:38:34 LetoThe2nd: if you're referring to my conversation, no you did not disagree, qschulz mentioned but an image recipe would be just enough and I agreed with this (I might've been not clear, sorry) Mar 25 15:38:36 * zeddii is annoying all channels he can now. Mar 25 15:38:49 abelloni: I think the answer is you do need root to setup the group :/ Mar 25 15:39:47 Hi, Bitbake is not supported on OSX as this article states: https://zatoichi-engineer.github.io/2017/10/02/yocto-on-osx.html. Still, the same article shows that it can be run in a docker container. I'm considering to get one of apples new M1 chips powered computers. Would you assume that the dockerized solution still works out or can anyone already now see reasons that this will technically not work? Mar 25 15:41:41 LetoThe2nd: 2 CPUs 64 cores HT.. that's one hell of a rig.. what cpu is that ? Mar 25 15:42:59 emrius: while the experience is far from optimal (I run a VM to build bitbake things rn on x64), it looks like VM support for M1 exists. As long as you can run some form of linux VM, there should be a path forward Mar 25 15:44:12 Spooster: Okay, thanks for the info. I'll probably give it a shot fairly soon. I might drop a comment somewhere regarding same benchmarks. The M1 performance looks pretty neat. Looking forward to try Mar 25 15:44:56 I cant wait till linux runs on M1. Looking forward to that even more :) Mar 25 15:45:24 PaowZ: 2x EPYC 7742 Mar 25 15:45:28 it might be worth taking a deep look in HOW linux is being emulated on M1 right now before you pull that trigger Mar 25 15:46:09 if it's emulating x64 on M1... I wouldn't expect "efficiency" Mar 25 15:46:25 emrius: the question is, do you really want to use it as a daily dev rig or just like a "ad hoc on the road thingy" Mar 25 15:46:28 Sure thing! I'd give it another year before getting one. But my return key starts to behave weirdly... Mar 25 15:46:58 LetoThe2nd: rather the latter for development. For production we have a larger rig Mar 25 15:47:36 emrius: i personally have just received a thinkpad x1 nano and am super happy. Mar 25 15:48:03 Spooster: linux on m1 is just virtualised, its arm64 binaries Mar 25 15:48:10 (assuming in a vm) Mar 25 15:48:16 native linux on m1 is obviously arm64 Mar 25 15:48:21 fwiw, the m1 *flies* Mar 25 15:50:28 LetoThe2nd: Thanks. Looks tempting too! Mar 25 15:51:30 LetoThe2nd: how fast can it do a core-image-sato with populated dldir but no sstate Mar 25 15:51:53 i need to run that on my m1 mpb with a big enough disk in the VM so it actually finishes Mar 25 15:52:06 rburton: no idea. i'm just using it as a desktop frontend :) Mar 25 15:52:14 rburton: how long does it take on you mbp? Mar 25 15:52:22 I have git repo for libfoo, which includes some example code. I want packages for libfoo and the libfoo-examples … Is it better practice to create: a) two separate recipes and an include file or b) one recipe using PACKAGES and a bunch of underscored vars? In case of b), is it possible to define separate do_install functions for both packages? Mar 25 15:53:04 emrius: the mba took about 80 minutes in parallels with passive cooling (very curious if it throttled the cpu) Mar 25 15:53:11 haven't tested on the mbp yet Mar 25 15:53:23 mba on m1? Mar 25 15:53:34 yes Mar 25 15:53:37 nice! Mar 25 15:54:01 I'll drop the order today Mar 25 15:54:16 jmiehe: b) is way to go, usually. why would one need seperate do_installs? Mar 25 15:54:39 i'm very torn between the mba vs mbp. the lack of touchbar on the air could be considered a feature, but the pro has a fan Mar 25 15:54:51 cause the example bins are not installed by cmake and need some extra love Mar 25 15:54:55 LetoThe2nd: Mar 25 15:55:07 rburton: The lack of the touchbar clearly is a feature! At least for me :) Mar 25 15:56:03 jmiehe: include the extra love anyways, it doesn't matter in the end as they are not picked up if FILES is set correctly. Mar 25 15:56:17 emrius: at least they both have a proper escape key Mar 25 15:57:10 LetoThe2nd: as always, that makes perfect sense now that I think about it :) Mar 25 16:00:34 +1 to the physical escape key Mar 25 16:00:45 I'm still not over it Mar 25 16:02:39 i've been on a mbp for a couple of years. not again if i can avoid it. if i want a makeup mirror, i'll buy one. if i want a laptop, i'll buiy one. not vice versa, and especially not mixing it up! Mar 25 16:03:22 LetoThe2nd: those chips are valuated up to $5000 each.. god.. I just run a simple i7-7790K.. :-| Mar 25 16:05:29 for those stuck with python2, this will likely hit you: https://github.com/pypa/setuptools_scm/issues/541 e.g. via python-dateutil Mar 25 16:06:17 Probably an easy one: Nothing PROVIDES 'libfoo-examples'. Close matches: libfoo RPROVIDES libfoo-examples Mar 25 16:07:16 jmiehe: in DEPENDS, you only have recipe names, in RDEPENDS only package names Mar 25 16:07:29 PaowZ: well it enables 4 devs + production here. think tools. Mar 25 16:08:04 qschulz: so bitbake libfoo-examples will not work if it's "just" a package? Mar 25 16:08:59 jmiehe: you bitbake recipes, not packages Mar 25 16:09:18 the outcome of bitbaking recipes is packages Mar 25 16:09:40 and one recipe may provide *several* packages.. Mar 25 16:10:05 PaowZ: actually does so in the immense majority of cases Mar 25 16:10:39 jmiehe: the catch is that by default, each recipe produces a package with the same name, which makes it rather confusing Mar 25 16:10:51 yes indeed, I might have written "it happens that sometimes, one recipe actually give just one package " xD Mar 25 16:38:46 Can an image recipe define WKS_FILE or is it only allowed from a machine configuration? Mar 25 16:44:18 it could, but it'd violate our distro/machine/image orthogonal axes of the build. we want any image to work with any distro and any machine, with few exceptions Mar 25 16:45:50 kergoth: I might be in one of these few exceptions scenarios. I'm creating a image recipe for an SD card containing only a configured bootloader (for tftpboot) Mar 25 16:46:56 that does sound like an unusual case, so not unreasonable for that to be an exception Mar 25 16:48:12 kergoth: in this scenario, you might only want the sdcard to contain a single vfat partition, nothing else required. This is why I thought defined WKS_FILE in the recipe would be appropriate here. Mar 25 16:56:48 but no big deal, I can rely on the WKS_FILE defined by the MACHINE being used. Mar 25 16:59:02 hey guys (kergoth), found my problem: BBPATH = "${TOPDIR)" Mar 25 16:59:20 damnit! Mar 25 16:59:24 { vs ) ? Mar 25 16:59:27 i hate it when i do that! Mar 25 17:00:19 vdl: opposite: ) versus } Mar 25 17:01:28 obviously Mar 25 17:03:55 beware excessive self-referentiality... Mar 25 17:30:48 yay another openssl cve Mar 25 17:31:24 https://www.openssl.org/news/secadv/20210325.txt **** BEGIN LOGGING AT Thu Mar 25 17:42:35 2021 Mar 25 17:59:55 vmeson: there is clearly a hole in our use of ionice since it does not cover async IO. I'm wondering if we could bypass the problems by forcing the qemu's into ramdisks? Mar 25 18:09:35 Hi @RP, ndec. Where's the reference specification about supported releases? I know https://docs.yoctoproject.org/releases.html, but I've just found https://wiki.yoctoproject.org/wiki/Releases looks much more informative Mar 25 18:10:57 the page on the docs website points to all versions of the documentation. the wiki page shows all the YP releases (not just docs) Mar 25 18:11:37 So the wiki page is the official reference right? Mar 25 18:12:26 Note that this wasn't straighforward to find, I had to look for "LTS" in the html docs to find the right link in the reference manual. Mar 25 18:14:24 Would it be a good idea to improve the "Downloads" page so that it's clear what the latest releases are, and which one is LTS? Mar 25 18:15:57 By the way, why does the "Downloads" page advertise 3.2.1 instead of 3.2.2? Mar 25 18:16:47 ndec ^ Mar 25 18:21:24 michaelo: argh... because the website was not updated ;) Mar 25 18:22:23 we really need to define a new method with all the release information, and make sure it's used by the website, and the docs website.. it was 'slightly' better before the sphinx migration.. Mar 25 18:29:01 ndec: yes, definitely. Let me create the bug that you were suggesting about all this, and then let's look for a solution. Mar 25 18:29:06 ndec: thanks Mar 25 18:47:40 Hello, all. I am trying to include the "find" unix command on a image, but I am having a hard time searching for it on a search engine, as all hits I've seen usually points to how to find a package. So, any thoughts on the package name for the "find" command? :) Mar 25 18:53:02 @SherrinPaul https://layers.openembedded.org/layerindex/branch/master/recipes/?q=find Mar 25 18:53:14 looks like `findutils` might be what you're after Mar 25 18:54:20 Ah! Sure looks like it! Many thanks, @Spooster! Mar 25 19:01:08 does someone already have openssl 1.1.1k patch prepared? I've compile tested on dunfell, building on master. don't have B/W for gatesgarth currently.. Mar 25 19:26:31 what's the syntax about `require ${@bb.utils.contains()}`, i.e. the ${@myfunc()}, this calls myfunc() right? I know some python oop, that uses `import` and `class Child(Parent)` to do inheritance, what is `require, inherit` in yocto? can someone give me a pointer Mar 25 19:28:24 * rr123_ just realizes bitbake uses bb prefixes just as busybox which also uses bb Mar 25 19:35:17 rr123_: see the bitbake user manual for info on the file format Mar 25 19:35:35 rr123_: see also the yocto chapter of the architecture of open source book. google it, you can read the chapter online Mar 25 19:38:42 thanks, reading, devtools etc are totally new since 2017 Mar 25 19:39:28 Is it bad practice if i use a local directory (part of the android - repo integration)? Mar 25 19:40:06 * rr123_ wonders if there is a yocto-best-practice doc/book Mar 25 19:43:01 bitbake -e : ERROR: Layer openembedded-layer is not compatible with the core layer which only supports these series: gatesgarth (layer is compatible with hardknott) -- saw this on a fresh 3.2.2 checkout from gatesgarth Mar 25 19:43:49 please ignore, i switched to master branch Mar 25 20:25:15 there is nothing sacred about the poky/meta/class/machine, is there? that is, if I add machine definitions and tunings in my own layer, poky/meta-yates/class/machine, bitbake/yocto should include them in the search for machine name XYZ in a MACHINE ??= "XYZ" in a local.conf, right? Mar 25 20:25:49 ..if that layer is included in bblayers.conf Mar 25 20:25:58 yates: almost. Mar 25 20:26:01 class ? Mar 25 20:26:25 1) your layer shall not go into poky 2) the path is meta-yates/conf/machine/yourmachine.conf Mar 25 20:27:28 then it will be reconized as yourmachine for MACHINE, unless its content sets the name otherwise. (also see the YT on distros. same comcept applies) Mar 25 20:27:43 khem: no, i meant poky/meta-yates/conf/machine Mar 25 20:30:42 LetoThe2nd: ok, but what's "almost" about it then? Mar 25 20:31:27 not putting the layer in poky is a policy - it should still work as long as the bblayers is set right, should it not? Mar 25 20:31:41 (and I will change that, good point) Mar 25 20:31:58 and you wrote class, not conf. hence, almost. Mar 25 20:32:24 oh, ok, right. Mar 25 20:32:47 well i'm getting this when trying to build: http://paste.ubuntu.com/p/9VtDwww9B4/ Mar 25 20:34:13 "has no defined features" - what are "defined features"? Mar 25 20:34:50 without digging myslef, I only can say: dig into other machines and investigate how the named variables are being set there. Mar 25 20:35:12 it certainly is not related to the resolution of the macchine name file, but its content. Mar 25 20:35:19 ok. Mar 25 20:35:45 i modeled things after the riscv machine, but i guess i've got something hosed Mar 25 20:38:05 s/hosed/not completely right/ Mar 25 20:38:21 the error message indices that you need to define some override. Mar 25 20:39:01 k Mar 25 20:43:41 Can we share host build (tools) between builds? Mar 25 20:44:12 I'm sharing SSATE_DIR and DL_DIR but I expect host tools to be shared as well Mar 25 20:45:51 Guest88867: which would that be and what is the use case? Mar 25 20:47:53 LetoThe2nd: the use case is speeding builds up, especially in a CI. "gperf", "patch", "elfutils", and so on have to be compiled only once, right? Mar 25 20:48:46 Guest88867: if you share sstate (and the configurations are compatible) they should be compiled only once. Mar 25 20:49:08 ok Mar 25 20:50:10 LetoThe2nd: it's just that I'm compiling this image with only the bootloader on it, (dummy linux and empty IMAGE_INSTALL). There are still 1029 steps and it takes a while, seems strange. Mar 25 20:51:04 barebox and wic (and its dependencies) are the only two components involved. Mar 25 20:53:13 without seeing the dependencies and tasks involved there's no way to comment. but mind, that getting stuff from sstate also makes for a number of tasks per recipe - albeit very short ones from the second run on. unless you somehow broke the signature checks. Mar 25 20:54:03 but ~1000 tasks for a build from scratch that essentially includes the toolchain plus wic and tools, sounds legit. Mar 25 20:54:14 ok Mar 25 20:56:55 LetoThe2nd: for my bootloader-only SD card configured for tftpboot I finally went with a dedicated machine configuration to specify linux-dummy, configuring the bootloader and IMAGE_BOOT_FILES, alongside nodistro and (shamelessly stolen) test-empty-image. Mar 25 21:00:35 sounds like a good approach to me. Mar 25 21:02:19 btw can we define something like a "noimage", similar to nodistro? Mar 25 21:03:35 In this scenario I need to bootloader to be compiled for the given machine, but using virtual/bootloader as the target isn't enough because I need do_image_wic to prepare the SD card, which is obviously bound to an image recipe. Mar 25 21:04:23 Another use case is WKS files lacking --source rootfs partitions. These are good candidates for such "noimage". Mar 25 21:04:55 technically you could inject the image bbclass into the booloader recipe. but that makes the recipe unusable for all other cases. so the trivial forwarder image is totally fine. Mar 25 21:05:44 if you think you found a noteworthy usecase you can always send patches/rfc. another option would be to create a custom imagefs type. Mar 25 21:05:59 but at the moment, i'm not aware of such a thing. Mar 25 21:07:46 LetoThe2nd: injecting the image bbclass into the bootloader recipe (or a copy) would import any non empty IMAGE_INSTALL component, wouldn't it? Mar 25 21:09:22 but I guess just setting IMAGE_INSTALL = "" in this bootloader forked recipe would do the trick. Mar 25 21:11:13 i don't exactly see why you want to avoid an image and favor two bootloader recipes. but i'm off anyways for today, have fun. Mar 25 21:11:33 o/ Mar 25 21:12:14 (to answer, because I want something simple: a bootloader embedded in an SD card partition, nothing more.) Mar 25 21:33:50 khem: the bleach code is running on errors.yoctoproject.org. Can you test it? Mar 25 21:35:04 halstead ok, I will throw away my local patch and do a build Mar 25 21:35:20 Thanks! Mar 25 21:40:08 halstead: seems to work see https://errors.yoctoproject.org/Errors/Build/118740/ Mar 25 21:41:04 finally time to drop a patch that I have lugged around for 3 years !! thanks halstead Mar 25 21:42:44 khem: yay! Mar 25 22:15:10 i am getting this error: ERROR: /mnt/hdd/poky/meta/recipes-support/gnutls/libtasn1_4.16.0.bb: Please add your architecture to siteinfo.bbclass Mar 25 22:15:49 do i have to add it to poky/meta/classes/siteinfo.bbclass, or can i accrete it in my own layer's siteinfo.bbclass? Mar 25 22:20:06 nm Mar 25 22:21:36 i need to add archinfo, osinfo, and targetinfo to SITEINFO_EXTRA_DATAFUNCS Mar 25 23:20:33 RP: https://lists.openembedded.org/g/openembedded-core/message/149847?p=,,,20,0,0,0::Created,,khem,20,2,0,81562524 is waiting for to be pulled int master-next Mar 26 01:10:49 Hello guys, I have been setting up a new build machine and I keep getting the same do_unpack error for multiple tasks. In the log file it says "Cannot open: No such file or directory" but I go to that directory and  I see the file there with a .lock extension at the end. Anyone has any clues to what is going on? Mar 26 01:15:08 Mustafa: you could "rm -fR /tmp" and try again, at the risk of losing some time in re-fetching Mar 26 01:16:35 okay. let me try. thx! Mar 26 01:18:38 sure, hope it works. i wonder why that state arose in the first place, though. Mar 26 01:20:14 what is the @ symbol in recipes? @ is decorator in python, i found nothing explained in bitbake for @ Mar 26 01:20:41 other than FOO = "${@foo()}" Mar 26 01:21:14 i know it means calling foo() but would like to find where it is documented Mar 26 01:21:16 yates, I did have an error in my DL_DIR and SSTATE_DIR. I had a ~ sign there. I did fix it by using absolute path but will see. Mar 26 01:22:54 started a new build and it looks like that solved. Not sure yet but we will see. Thanks for the tip Mar 26 01:23:51 i was always running bitbake -c clean. I thought that clean up the tmp dir but maybe I am missing something. **** ENDING LOGGING AT Fri Mar 26 02:59:56 2021