**** BEGIN LOGGING AT Thu Mar 26 03:04:32 2020 Mar 26 14:39:12 <_inisider> hi. i would like to ask is it some way to find correspondence between f.e. virtual/docker and recipe better than do grep -Rni "PREFERRED_PROVIDER_virtual/docker"? Mar 26 14:41:10 _inisider: Hi, to know which package are associated to this virtual/docker variable you just need to ask to bitbake "bitbake -e | grep PREFERRED_PROVIDER_virtual/docker" Mar 26 14:43:18 <_inisider> Thanks! Mar 26 15:23:27 <_inisider> I have got an error: "Multiple versions of docker-ce are due to be built" and the problem happens because I have 2 docker-ce_git.bb files in different layers. How does PREFERRED_VERSION_docker-ce actually works? Should I just rename docker_ce-git.bb to docker_ce-git-{desired_version}.bb or it will get a version that is set in the .bb file using Mar 26 15:23:28 <_inisider> variable PV = "${DOCKER_VERSION}+git${SRCREV_docker}"? Mar 26 15:25:05 <_inisider> so should i just write PREFERRED_VERSION_docker-ce="18-03...+git05...." in the conf file of a distro? Mar 26 15:26:56 * fray needs to learn not to write commit messages right after he rolls out of bed in the morning Mar 26 15:29:28 so write them in bed ? Mar 26 15:35:07 I'm guessing the grammar would be far far worse in bed.. Mar 26 18:22:31 <_inisider> can anyone explain me how bitbake resolves a situation where there are two recipes with same names from a different layers? I thought that will take a recipe from a layer with higher priority Mar 26 18:23:01 I think this should indeed be the case, i.e. based on priorities, do you experience something different? Mar 26 18:23:28 in the absence of PREFERRED_VERSION that'd be true. explicit preferences are preferred Mar 26 18:25:03 <_inisider> i have got an error like:Multiple versions of docker-ce are due to be built, so I am trying to understand what is a problem. Mar 26 18:25:34 that error means there's likely something one provides that the othre doesnt Mar 26 18:25:47 ex one provides additional binary packages and something is rdepending on them Mar 26 18:30:06 <_inisider> i did not get you Mar 26 18:31:05 <_inisider> i dont see that docker-ce from meta-virtualization provides something Mar 26 18:31:25 Again, it means one recipe provides something the other that does not, either build time (PROVIDES is different) or runtime (PACKAGES or RPROVIDES are different) Mar 26 19:07:26 <_inisider> why is so important? I grepped in these 2 recipes and there are differences in variables PROVIDES, PACKAGES, RPROVIDES. so is it some way to tell which one recipe should be used? As I understand I can use for that purpose PREFERRED_VERSION, but question is it will resolve version? I mean usually u have 2 recipes lile recipename_version1.bb and Mar 26 19:07:26 <_inisider> recipename_version2.bb and in this case u can set PREFERRED_VERSION=version2 and it will take recipename_version2. but in my case the recipe name is in format recipename.bb, so should i set PREFERRED_VERSION equal to the value $PV from recipe needed for me? Mar 26 19:41:35 it's about dependencies. there's a recipe that depends on something that one of the recipes doesn't provide Mar 26 19:41:45 so it has to build the other one in addition to the one you prefer to satisfy it Mar 26 19:54:33 <_inisider> i see. Mar 26 19:57:24 the easiest method would be to use BBMASK to prevent bitbake from parsing the one you don't want building, then it'll error when it can't find a recipe that provides what is missing Mar 26 19:57:31 so then you'll know what's missing from the recipe you want to build Mar 26 19:57:43 or just rm the one you don't want to build temporarily, same result Mar 26 19:58:27 <_inisider> thanks. ill try Mar 26 20:23:02 <_inisider> i have found what causes an issue. it is because in the RRECOMMENDS of runc-opencontainers_git.bb and containerd-opencontainers_git.bb is docker, but noone RPROVIDES it, so if just add RPROVIDES += "docker" to docker-ce_git.bb than bitbake virtual/kernel builts successfully Mar 26 23:48:01 fray: what you pasted me yesterday was basically a distro setup to cross compile baremetal stuff, right? Mar 26 23:48:58 I managed to finish my autoconf build files which now spit out the appropriate .elf for the m4 when --host=arm-none-eabi is given, and now wondering how I could hack that into my normal rootfs build Mar 26 23:49:38 I am downloading a precompiled baremetal toolchain as part of DEPENDS, but EXTRA_OECONF = " --host=arm-none-eabi" does not do the trick Mar 27 00:24:36 fray: ooh I think I misundersood your paste, so actually its an additional machine override which triggers on compatible machine in the recipe? Mar 27 01:12:32 or not :) Mar 27 01:12:42 thats what I ended up with: https://paste.ee/p/lxXWH Mar 27 01:12:52 ugly as hell, but it works **** ENDING LOGGING AT Fri Mar 27 02:59:57 2020