**** BEGIN LOGGING AT Mon Nov 04 02:59:58 2019 Nov 04 08:00:47 good morning Nov 04 08:02:06 mckoan: morning Nov 04 08:23:19 good morning Nov 04 08:23:45 hello hello Nov 04 11:13:30 hello folks Nov 04 11:13:44 what is the meaning of ?= together with override statements? Nov 04 11:13:53 like FOO_myoverride ?= baz Nov 04 11:14:09 will it be like "if Foo is not assigned yet, then if 'myoverride' is active, assign baz" ? Nov 04 11:14:39 litb: yes, allows recipe, appends and classes to override variables Nov 04 11:15:04 https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#setting-a-default-value Nov 04 11:25:41 mcfrisk, thanks! Nov 04 11:26:06 what's the equivalent of a packagegroup for buildtime dependency grouping? Nov 04 11:27:40 i have a "packagegroup-graphics.bb" that groups required libraries for the GUI. now I need to group build time dependencies. I would think packagegroup should be usable aswell, but I'm not sure Nov 04 11:30:09 New news from stackoverflow: In poky-tiny, why adding openssh also adds bash? Nov 04 11:34:03 litb: ?= with overrides is meaningless Nov 04 11:34:31 rburton, oh Nov 04 11:35:25 at least, thats my understanding of how overrides are parsed. Nov 04 11:35:27 RP: ^ Nov 04 11:35:47 rburton, I found instances in the manual that combine them both Nov 04 11:36:08 lets get RPs statement then we can either fix the docs or i've learnt something new already Nov 04 11:36:34 SRCREV_pn-matchbox-panel-2 ?= "${AUTOREV}" Nov 04 11:37:24 * rburton tests Nov 04 11:37:48 ah at least that thing with SRCREV makes intuitive sense! Nov 04 11:38:10 right so i did PV_pn-m4 ?= "1.2.3" Nov 04 11:38:16 where bitbake.conf has PV= Nov 04 11:38:39 and the override took Nov 04 11:39:16 which you'd expect, no value already to it i assigned Nov 04 11:39:16 at first I was confused because it could also check whether there was already an override-assignment with that exact override flags, rather than only checking for the "base" variable Nov 04 11:39:37 ok looks like it does what you'd expect, but that behaviour isn't really useful? Nov 04 11:40:33 makes sense to me now Nov 04 11:40:37 in that you can't have conditional overrides. the override *will* happen Nov 04 11:40:58 if you have multiple overrides set with ?= then they do chain in that the second ?= doesn't happen Nov 04 11:41:08 i guess that could be useful if you're layering pieces together Nov 04 11:42:08 oh I see now. it checks for a previous assignment of the base-variable combined with the exact combination of overrides? Nov 04 11:42:22 no Nov 04 11:42:38 bitbake.conf does PV={take version from filename} Nov 04 11:42:55 if you do PV_override ?= "2" then if the override is triggered, that happens. Nov 04 11:43:07 another PV_override ?= "3" doesn't override 2 to 3 Nov 04 11:43:36 with potentially a different override even Nov 04 11:44:32 not sure whether I expect PV=... PV_override ?= ,,, to override the value set with "=". I guess I wouldn't Nov 04 11:44:52 the entire point of an override is that it overrides the value Nov 04 11:45:34 hm, I see Nov 04 11:54:24 After all the BSP bashing in Lyon, nice to be back at $work and start bashing BSP layer crap. BBMASK += "meta-*bsp*" Nov 04 11:55:00 mcfrisk: :) Nov 04 11:55:30 rburton: its not exactly useful Nov 04 12:13:21 mcfrisk: but, there certainly was no bashing. just very polite, gentle reminders. with a sledge hammer. Nov 04 12:51:38 my package has a config "debug=0|1", "context=release|develop" and a GUI can be included or not (which will add "gui" at compile time and "install-gui" at install time). Nov 04 12:53:23 is it a bad idea to "abuse" PACKAGECONFIG for this? the individual groups will then be empty like "PACKAGECONFIG[debug] = ",,". individual variables will query PACKAGECONFIG, like GUI_INSTALLFLAG = "${@oe.utils.contains('PACKAGECONFIG', 'gui', 'install-gui', '')}" Nov 04 12:54:17 and they will be passed in do_compile and do_install such as "./buildscript ${GUI_INSTALLFLAG} dest=${D}" in do_install Nov 04 13:01:46 litb: its certainly a way of getting it done. one would probably not do this in a public upstream layer but if it suits your usecase, why not Nov 04 13:03:15 litb: i'd add that it depends a bit on if you have more packages behaving like that, and if you need to be able to tune them independently. otherwise it might be simpler to add a distro flag like "mycompany-debugtweaks" Nov 04 13:03:33 hm, I see. Nov 04 13:03:51 so, "it depends" (TM) Nov 04 13:08:00 * mcfrisk rants: why would a BSP layer set GCCVERSION?! Nov 04 13:09:10 * mcfrisk rants: it only results in a huge list of: NOTE: preferred version 8.2% of gcc-runtime not available (for item gcc-runtime) Nov 04 13:09:27 mcfrisk: because $VENDORKERNEL or $VERNDORBOOTLOADER need $OLDGCC to even build Nov 04 13:09:43 a true classic Nov 04 13:10:19 except that they dont :) Nov 04 13:10:51 there's always the possibility that its just a crappy bsp Nov 04 13:11:45 and I need to explain why mixing clang and gcc for kernel and external kernel modules is "a bad idea (TM)" Nov 04 13:12:04 (TM) Nov 04 13:13:15 Hi any meta-java maintainer here or news about Richard Leitner? or maybe openjre is not embedded jre choice now? ;) Nov 04 13:14:02 mcfrisk: can I ask how this clang+gcc mixing is handled in your Yocto? I'm interested in having IRL examples on how people implemented this to find the best way to do it Nov 04 13:14:28 nayfe: did you reach out for him by mail? thats usually his favorite way of interaction, IIRC Nov 04 13:16:09 qschulz: inherit clang in recipes, meta-clang as layers. switch from default toolchain gcc to clang using that inherit. Nov 04 13:18:01 oh, TOOLCHAIN = "clang" is needed too in the recipes. Nov 04 13:19:20 letothe2nd> mails on openembedded-devel with meta-java prefix and maintainers in CC do not get answers, it's been a while layer had no activity Nov 04 13:21:48 nayfe: hm i'm quite sure i readhim in the last couple of weeks Nov 04 13:22:30 bu tno time to go searching right now, sorry. Nov 04 13:24:34 mcfrisk: ok thanks Nov 04 13:28:47 having the paragraph-character available helps quite a lot when searching in the manual Nov 04 13:29:09 often I have to copy the paragraph character out of the manual and paste it into the firefox search field. Nov 04 13:29:21 I guess I should install some "enter unicode character" plugin for this Nov 04 13:33:08 litb: most environments have a character picker hidden away Nov 04 13:44:41 is it a good idea to use weak default assignments "??=" in classes, and normal default assignments "?=" in .bb files? That way, bb files can override choices of classes, but distribs/local.confs can override choices of recipes Nov 04 13:52:43 litb: sounds good to me **** BEGIN LOGGING AT Mon Nov 04 14:33:13 2019 Nov 04 14:34:09 rburton: two included fragments can collide and disable one another, while defconfig guarantees it works well with Kconfig. Nov 04 14:36:07 why not ship a known good configuration using fragments and then say if you fiddle the config then obviously its your problem Nov 04 14:36:18 i doubt they'll support someone fiddling the defconfig randomly either Nov 04 14:36:36 anyway, because they wanted to use a defconfig is the answer. Nov 04 14:36:58 alessioigor: what kernel in meta-intel uses defconfig? Nov 04 14:39:04 rburton: Seems none Nov 04 14:42:56 rburton: linux-ti-staging (meta-ti) uses defconfig whereas linux-intel (meta-intel) my cfg snippet collides with ERNEL_EXTRA_FEATURES ?= "features/netfilter/netfilter.scc features/security/security.scc" Nov 04 14:43:27 Infact I'm trying to turn off netfilter. Nov 04 14:45:51 alessioigor: unset extra-features? Nov 04 14:46:42 rburton: Yes but I don't know how do the same for linux-ti-staging... Do you have any hint? Nov 04 14:47:05 alessioigor: for meta-ti, write your own defconfig Nov 04 14:48:35 ouch Nov 04 14:49:33 alessioigor: it's fine. run a build without your changes. then run bitbake -c menuconfig linux-ti-staging Nov 04 14:50:04 disable what you need, bitbake -c savedefconfig linux-ti-staging, go to the workdir, get the defconfig in the root of ${S} (usually) Nov 04 14:50:27 qschulz: Ok thanks Nov 04 14:50:53 put this defconfig where the recipe expects it (or in a bbappend which adds the required logic of loading a defconfig) Nov 04 14:53:00 Hello, I'm trying to upgrade the version of u-boot Yocto is building by using a recipe in my own custom layer. I have verified the recipe builds v2019.04 when placed in the meta-atmel layer. When I put the recipe in my own layer, the meta-atmel layer version of v2018.07 is built. I think the problem is the "require" statement. How do I proper Nov 04 14:53:00 require/include a file from meta-atmel in my own layer? Nov 04 14:53:55 d_thomas: require and put the full path in. if it doesn't give you an error, it was successful Nov 04 14:54:10 d_thomas: include is the same, but will fail silently Nov 04 14:54:18 (which is usually not what you want) Nov 04 14:54:21 d_thomas: shouldn't this be part of a bbappend? Nov 04 14:55:15 I'm seeing "Could not include required file meta-atmel/recipes-bsp/u-boot/u-boot-atmel.inc". If I remove the meta-atmel part it silently uses the old version. Nov 04 14:56:04 I went with a bb file since it is a new version, based on a different git commit. Seemed cleaner that way. Otherwise the bbappend name wouldn't match the actual version Nov 04 14:57:03 yup, understood. That's what you should do indeed Nov 04 14:57:43 you cannot put the name of a layer in the path, Yocto looks from the root of every layer, not elsewhere Nov 04 14:57:47 yeah, and the version without the meta-atmel is correct. but, this means you have the file twice, under the exact same path? Nov 04 14:57:54 require recipes-bsp/u-boot/u-boot-atmel.inc is ok Nov 04 14:57:59 inside the layers, that is? Nov 04 14:58:39 My intention is that u-boot-at91_2019.04.bb will only be in my layer (2018.07 is currently in the meta-atmel layer) Nov 04 14:59:00 letothe2nd: I suspect a PREFERRED_VERSION somewhere? Nov 04 14:59:19 I put u-boot-at91_2019.04.bb in the meta-atmel layer only temporarily to verify that the recipe was correct and that nothing was forcing a preferred version Nov 04 14:59:23 qschulz: i did the same, but $ASKER claims there is none Nov 04 15:00:02 Correct, so far I can't find anything forcing a version Nov 04 15:01:16 like i said last time, i'm sure it is something rather stupid/weird, but i can't put my finger on it at the moment Nov 04 15:01:37 why do you need meta-atmel then anyways? Nov 04 15:02:01 Same here :). As soon as I switch to "require recipes-bsp/u-boot/u-boot-atmel.inc", the build proceeds without complaint but ignores v2019.07 Nov 04 15:02:13 I need meta-atmel for the development kit I'm building the image for Nov 04 15:02:45 d_thomas: that is normal, all recipes are parsed even if they are not to be compiled or used in any way. Nov 04 15:03:37 d_thomas: debug with bitbake u-boot-at91 -DDDDDDDDDDDDDDDDDDDDDDDDDDDDD and maybe that'll help find out something? Nov 04 15:04:02 (I never remember how many D's are needed, so I just put as many as my patience let me Nov 04 15:05:20 wow, that's verbose turned up to 11 Nov 04 15:12:44 That's disappointing. The log just shows the sorted providers for u-boot are just the latest one from meta-atmel Nov 04 15:13:17 d_thomas: can you just put your layer on github or such? Nov 04 15:15:22 https://pastebin.com/CzuAKY7X Nov 04 15:15:26 That's the recipe Nov 04 15:16:09 i don't think that the recipe in itself is the problem Nov 04 15:16:10 in a meta-my-custom-layer/recipes-bsp/u-boot directory Nov 04 15:17:03 i have no better advice at the moment other to make a fresh layer, add just the u-boot and start out testing from there. remove your other custom layer for the build, see if it works or breals. Nov 04 15:17:09 I know my custom layer is getting used, because I had to modify the AT91Bootstrap bootloader to build the way I wanted in Yocto. So that bbappend file is working Nov 04 15:17:27 and if it breaks, show the whole minimized layer Nov 04 15:18:30 there just isn't much else in the layer..... the bootloader bbappend, a hello world program, and u-boot Nov 04 15:18:57 then, put it on github. Nov 04 15:19:03 if there's nothing magic inside Nov 04 15:32:36 Is it possible I just need to rebuild the entire image and not just u-boot? Nov 04 15:34:27 no Nov 04 15:38:47 Before posting the repo to github, I'd need to scrub out my ssh configuration. But it's just a basic layer I'm building that I don't see how that would be breaking anything. Seemed like I just needed to get the directory and filename convention correct and this should have worked. Nov 04 15:39:01 rburton: meta-ti uses config fragments Nov 04 15:39:47 but not linux-yocto specific "scc" Nov 04 15:40:44 d_thomas: if you keep ssh configuretion inside the layer its a bad idea anyways :P Nov 04 15:41:30 Moving it is on the list of things to do. This was just to get an image going that was usable for others Nov 04 15:42:04 Getting Yocto to build u-boot, kernel, etc is just for my own sanity. :] Nov 04 15:42:22 d_thomas: whatever. i already invested a substantial amount of time trying to help you, which is fine. but my patience is used up by now - either i can see the whole thing, or' i'm just out. Nov 04 15:42:54 letothe2nd: I'm new to this but... what's the impact of layer priorities in figuring out which recipe to pick? Nov 04 15:43:26 because that might explain why an older version gets picked up? Nov 04 15:43:32 just throwing ideas Nov 04 15:44:11 qschulz: AFAIK none, it should just kick in if things collide, but i might be wrong. yet, with a complete layer i can try and reproduce. which i am also willing to do, but no more poking. Nov 04 15:45:32 letothe2nd: https://www.yoctoproject.org/docs/2.6/bitbake-user-manual/bitbake-user-manual.html#var-BBFILE_PRIORITY ah found it! Nov 04 15:45:56 "The precedence established through this variable stands regardless of a recipe's version (PV variable)" Nov 04 15:46:00 d_thomas: ^ Nov 04 15:46:37 Ah, so my layer needs to be on the same priority level as meta-atmel? Thanks, I'll give that a try Nov 04 15:47:54 oh weird, meta-atmel is 10 and I'm at 6 Nov 04 15:48:17 (we could easily have looked at it if the layer was up) Nov 04 15:51:44 It was the priority Nov 04 15:52:07 *sighs* Nov 04 15:52:18 Sorry letothe2nd. I think long term I could put my changes into a meta-atmel into a public layer and the secret sauce into a private layer Nov 04 15:57:23 d_thomas: maybe worth noting that, IIRC, this does not apply to bbclasses, where the first occurence of the bbclass in BBLAYERS to be found is the one taken Nov 04 15:57:37 to be taken with a grain of salt and experimentation :) Nov 04 16:00:15 qschulz: interesting, good to know Nov 04 16:03:38 qschulz: pretty sure classes are searched for using BBPATH Nov 04 16:11:11 qschulz, at least if metadata that comes before yours in BBLAYERS inherits a class that you want to override in yours, then the "wrong" bbclass is taken Nov 04 16:11:19 that happened for me Nov 04 16:11:57 RP, ah, for classes the priority it completely ignored? Nov 04 16:13:22 litb: not sure priority makes sense for classes Nov 04 16:13:56 ah the old 'bblayers order' vs bbfile priority thing pops up again :) Nov 04 16:14:12 lulz Nov 04 16:14:15 kergoth: part of me wants to delete a load of these variables Nov 04 16:14:35 RP: gogogo! Nov 04 16:14:39 it's tempting for sure. we have so much legacy stuff in all of this. i can't imagine many folks use bbpath+bbfiles to set up anymore Nov 04 16:15:14 BTW sometimes I write bb.build.inherits_class('foo'): and i have seen others that do that Nov 04 16:15:28 RP: here something to get you started: https://www.youtube.com/watch?v=ZpUYjpKg9KY Nov 04 16:15:36 only the metadata knows what's been inherited, not the global bb.build python module :) Nov 04 16:15:45 globals aren't nice Nov 04 16:15:46 maybe it would be cool if there is a _bbclass- override for each class inherited. then some of those checks could go Nov 04 16:19:11 litb: each override slows down parsing. Are you sure you'd want to do that? Nov 04 16:19:22 better would be d.inherits() Nov 04 16:19:49 in fact, it would be natural if the override was _class- because it would be compatible with the BBCLASSEXTEND names, afaics Nov 04 16:20:01 RP, hm, I see Nov 04 16:24:12 inherits() is fairly common Nov 04 16:31:52 I mused at the OE meeting about a) fixing bitbake memres b) making it default c) making some kind of layer setup support in bitbake d) requiring it for eSDK e) replacing eSDK with that simpler mechanism (and simplifying selftests to use it ) Nov 04 17:02:28 rburton, RP - a colleague wrote a tool that would print 'critical paths' of Yocto builds: https://github.com/oesse/find-critical-path Nov 04 17:02:48 I am now convincing them to rewrite it in python, so it can be merged into buildstats directly Nov 04 17:03:05 nice Nov 04 17:03:16 i've something here somewhere that probably isn't as good :) Nov 04 17:03:25 c++! Nov 04 17:03:26 cik Nov 04 17:03:50 rburton, they didn't ask me about the unfortunate choice of implementation language :( Nov 04 17:03:53 boost as well! Nov 04 17:04:47 but their approch is based on computer science: they implement a well proven algorithm Nov 04 17:06:58 kanavin: nice, I've always just looked at the graph :) Nov 04 17:17:39 hi, modutils.sh is supposed to run on boot from meta? Nov 04 17:17:48 it seems that it fails at this condition in our case: [ -f /etc/modules ] || [ -d /etc/modules-load.d ] || exit 0 Nov 04 17:17:55 so it skips the rest, like important depmod, etc. Nov 04 17:18:23 is it reasonable my board has neither /etc/modules, nor /etc/modules-load.d Nov 04 17:34:13 I'm upgrading my work to Zeus. I have a custom kernel which has to remain at 4.14 for the time being. I've defined my own Linux recipe modeled after linux-yocto. This has been working fine for me since Sumo. However, I'm now seeing failures in my perf build. My failure log is here - Nov 04 17:34:14 https://gist.github.com/mabnhdev/50ee5408ce9c291e036321395f470492. Any guidance on addressing this issue would be appreciated. Nov 04 17:42:42 mabnhdev, not sure, but it appears that it doesn't like your python version? Nov 04 17:45:55 litb Yes, I added NO_LIBPERL=1 NO_LIBPYTHON=1 to EXTRA_OEMAKE and it complains less. But those warnings are still there and it now fails in do_install. I'm not sure that's the right way to go, though. Nov 04 17:51:17 Here's the failure with NO_LIBPERL=1 NO_LIBPYTHON=1: https://gist.github.com/mabnhdev/54fa39a756fcebadce1c49f888493b03 Nov 04 17:57:16 mabnhdev, another parameter says PYTHON=python3 . dunno whether or not that contradicts NO_LIBPYTHON=1 Nov 04 18:02:02 mabnhdev, maybe the shebang line in that setup.py script is too long for your kernel to interpret. I once read some code in yocto that tried to minimize this path length Nov 04 18:02:37 ideally it would rely on PATH, instead of having an absolute pathname. maybe do_devshell could help Nov 04 18:13:49 mabnhdev: it would be interesting to hear if some of the mismatched header file warnings go away if you cherry-pick a commit on master to your branch. might not help, but you never know. Nov 04 18:14:02 see: perf: drop 'include' copy Nov 04 18:14:28 also, it might be possible that 4.14 is just to old to support the python3 only build, I’d have to double check when that transition was made. Nov 04 18:14:57 in that case, you might have to revert the python3 changes in zeus and take your chances with the python 2.7 EOL Nov 04 18:16:34 @zeddii - I should have both python 2.7 and python3 defined. I'll have to check that. I actually only need python 2.7, but including python3 was always the path of least resistence. Nov 04 18:37:55 the point is that we integrated patches in zeus to go to python3 only for the kernel bits, towards the goal of not having python3 in the release. Nov 04 18:38:16 but if the kernel is too old to fully support python3 perf, you’d have to revert those, or come up with your own patches, etc. Nov 04 18:50:43 zeddii Ah. Understood. Is perf a "required" package? Can I just get rid of it to move forward? Nov 04 18:51:15 yep. you definitely can. Nov 04 18:51:15 mabnhdev: do you have https://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg127705.html in your build? Nov 04 18:54:34 JaMa: Yes, I do have that patch in my build. Nov 04 20:19:22 qschulz: you around? did you get to talk to khem? Nov 04 22:23:35 I'm not sure what I'm missing here Nov 04 22:23:52 I'm creating a recipe meant to be used as a tool during the build Nov 04 22:24:05 it depends on openssl, so I add it as an RDEPENDS Nov 04 22:24:18 but openssl doesn't get installed to the sysroot when I build mytool-native Nov 04 22:36:08 I've minimized what I'm trying to do into these to small recipes: https://gist.github.com/marler8997/f8ceeeff80a0e1cb03e9c223654d0fc2 Nov 04 22:37:02 I would think that if you added RDEPENDS to a recipe, that it would install those dependencies into the sysroot? Nov 04 22:37:29 if you are building the "*-native" version of the recipe Nov 04 22:39:27 rdeps are used when building images or doing package installs Nov 04 22:39:40 if something is needed during build then use depends = ... Nov 04 22:39:48 right Nov 04 22:39:52 but this is an indirect dependency Nov 04 22:40:00 A DEPENDS on B Nov 04 22:40:19 well, A DEPENDS on B-native Nov 04 22:40:31 and B has RDEPENDS Nov 04 22:41:04 so, I would think that if you want to use B-native, which gets installed to the sysroot, then you would need the RDPENDS of B Nov 04 22:41:29 Otherwise, you would need to write a different recipe for both B and B-native right? Nov 04 22:42:05 not really you can use class-native override Nov 04 22:42:40 so you're saying I should do this: Nov 04 22:42:50 DEPENDS_class-native = "bash coreutils openssl" Nov 04 22:43:01 RDEPENDS_${PN} = "bash coreutils openssl"? Nov 04 22:45:48 rdeps are encoded into packages ( rpms, ipk etx metadata) since there are no output packages for native packages rdeps might go unnotices Nov 04 22:45:48 Actually, it would be: DEPENDS_class-native = "bash-native coreutils-native openssl-native" Nov 04 22:46:18 right, I understand what's goin on, I just don't understand the right way to do this Nov 04 22:46:43 I want to write a recipe that works both with "-native" and without "-native". I would think I could configure the same dependencies for both Nov 04 22:46:45 DEPENDS_class-native = "bash-native coreutils-native openssl-native" seems fine Nov 04 22:46:54 but that doesn't seem right does it? Nov 04 22:47:04 Now I have to code the same dependencies twice Nov 04 22:47:44 DEPENDS_class-native = "bash-native coreutils-native openssl-native" and then RDEPENDS_${PN} = "bash coreutils openssl" Nov 04 22:47:53 is that really the right way to do this? Nov 04 22:49:15 usually rdeps are built too so I am sure it should be building the rdeps but it might not be staging them for native package sysroots Nov 04 22:49:57 the RDEPS are not availible in the sysroot so my recipe that depends on openssl-wrapper-native fails because openssl isn't installed to the sysroot Nov 04 22:50:12 I know I can add DEPENDS += "openssl" Nov 04 22:50:17 but that doesn't seem correct Nov 04 22:50:34 I mean DEPENDS += "openssl-native" Nov 04 22:51:05 am I really supposed to configure the same dependencies twice...once for when it is installed to the sysroot and one for when it is installed to the target rootfs? Nov 04 22:54:57 rdeps are target specific Nov 04 22:55:14 right, I understand what RDEPENDS does Nov 04 22:55:42 it causes the packages listed to be installed when you install the PN from RDEPENDS_PN Nov 04 22:56:21 in the example I posted, what is the right way to configure openssl-wrapper.bb so it works both natively and on the target Nov 04 22:56:28 openssl-wrapper is just creating a bash script that called openssl Nov 04 22:56:40 so it requires both bash and openssl to be installed Nov 04 22:57:24 the only way I know how to make that work both natively and on the target is to use DEPENDS += "bash-native openssl-native" and RDEPENDS_${PN} += "bash openssl" Nov 04 22:57:31 rdeps should get mapped to native as well Nov 04 22:57:33 but that doesn't seem right Nov 04 22:57:33 hmm Nov 04 22:58:17 right, it would get mapped to native Nov 04 22:58:23 but sysroot doesn't use packages Nov 04 22:58:52 it uses SYSROOT_DIRS for normal recipes and SYSROOT_DIRS_NATIVE for "*-native" recipes Nov 04 22:59:15 SYSROOT_DIRS uses common library directories and SYSROOT_DIRS_NATIVE uses common bin/config directories Nov 04 22:59:53 it took me a while to realize that the sysroot is populated completely differently from the packages Nov 04 23:00:12 and that sysroot uses DEPENDS and the packages use RDEPENDS Nov 04 23:01:44 at least that's how I understand it, when I think about it more, it seems like "*-native" packages should actualy be using RDEPENDS to know which "*-native" packages it depends on...but that doesn't seem to be the case in my example Nov 04 23:12:23 it seems very odd to me that there are 2 different systems for "native runtime dependencies" and "target runtime dependencies" Nov 04 23:12:50 as I see it, this comes from the fact that the sysroot is populated differently from the target rootfs Nov 04 23:13:16 if sysroot was populated from the packages, then this would work as expected Nov 04 23:20:12 openssl seems to not have option -v so maybe you want to use something like 'help' Nov 04 23:20:42 and perhaps thats what the problem is Nov 04 23:33:14 the problem is it can't find openssl Nov 04 23:33:18 because it's not being installed to the sysroot Nov 04 23:33:37 but when I add DEPENDS_class-native += "openssl-native", then it does get installed to the sysroot **** BEGIN LOGGING AT Tue Nov 05 00:31:22 2019 Nov 05 00:59:26 emg: let run your container as a normal user via (docker) `--user "$(id -u):$(id -g)"`. Nov 05 02:32:47 New news from stackoverflow: yocto bitbake core-image-sato **** ENDING LOGGING AT Tue Nov 05 02:59:58 2019