**** BEGIN LOGGING AT Mon Apr 06 02:59:58 2020 **** ENDING LOGGING AT Mon Apr 06 05:10:20 2020 **** BEGIN LOGGING AT Mon Apr 06 05:12:21 2020 Apr 06 08:23:43 good morning Apr 06 09:24:44 hi Apr 06 09:26:42 is that possible to add an IMAGE_FEATURE as a RDEPEND of a recipe? Apr 06 09:26:53 like `x11-base` Apr 06 09:30:42 didile: maybe you can create your own distro Apr 06 09:31:33 I did, but I want to be able to upgrade my old one and I'd like OPKG to install all needed X11 dependencies Apr 06 09:31:47 didile: the principle is that, recipe configuration is local to the recipe. Image recipe is a recipe. Package recipe is a recipe. Apr 06 09:32:00 didile: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#usingpoky-extend-customimage-imagefeatures IMAGE_FEATURES is for customizing the image recipe Apr 06 09:32:05 ok Apr 06 09:32:20 I tried x11-base and it didn't work Apr 06 09:32:45 packagegroup-core-x11-base as a recipe dependency build Apr 06 09:33:35 didile: packagegroup is only for runtime AFAIK Apr 06 09:34:09 (I mean, it's an empty package which is just pulling a bunch of packages at runtime, it does not make sense as a build dependency) Apr 06 09:34:30 what are you trying to achieve (the initial issue) and what is not working as you expected? Apr 06 09:34:33 as RDEPENDS Apr 06 09:35:07 I want to upgrade my package with `opkg upgrade` and I want the upgrade to pass well Apr 06 09:35:30 my package need X11 but it isn't installed on the old image Apr 06 09:35:54 I use an .Xsession file to start my app with the system and I want all the X11 dependencies to be installed Apr 06 09:36:09 my package uses Electronjs Apr 06 09:36:39 for now my recipe contains only those dependencies: Apr 06 09:36:40 REQUIRED_DISTRO_FEATURES = "x11"inherit distro_features_checkRDEPENDS_${PN} += " \ nss \ gtk+3 \ cups \ alsa-lib \ libxscrnsaver \" Apr 06 09:40:19 and i added x11-base to my image Apr 06 09:40:42 adding a dep to the image won't change already installed images Apr 06 09:41:27 yes Apr 06 09:41:44 install the packagegroup explicitly on the target, or make a new packagegroup that installs both your app and everything else it needs in the system (such as a working x server) Apr 06 09:41:48 so how can I upgrade an old image to fit the new one Apr 06 09:41:51 (ps use wayland) Apr 06 09:42:06 ok Apr 06 09:42:51 so you have a packagegroup which is 'my app, fully working' not just the hard dependencies (the client libs). Apr 06 09:43:07 and if you want feeds to work for upgrades, remember to turn on the PR service Apr 06 09:43:07 I see Apr 06 09:44:03 what's the "PR service"? Apr 06 09:45:59 top hit of googling 'yocto pr service' is a big wiki page explaining it all Apr 06 09:48:20 ok sounds powerful Apr 06 09:52:04 I add a .Xsession file manually to start to app with X11 Apr 06 09:52:12 is there a better way to do it? Apr 06 09:52:43 I also add postinstall scripts to restart the xserver Apr 06 10:08:52 when I install packagegroup-core-x11-base, I get an error: Apr 06 10:09:14 Collected errors: * pkg_run_script: package "adwaita-icon-theme-symbolic" postinst script returned status 127. * opkg_configure: adwaita-icon-theme-symbolic.postinst returned 127. Apr 06 10:20:48 the error should have been above somewhere, i guess a missing dependency that is usually satisfied some other way Apr 06 10:22:21 //var/lib/opkg/info/adwaita-icon-theme-symbolic.postinst: line 14: gtk-update-icon-cache: command not found Apr 06 10:23:39 yeah missing dep Apr 06 10:23:55 easily fixed in the recipe, you should fix and send a patch :) Apr 06 11:09:43 I have no idea how to fix it Apr 06 11:12:12 didile: find the package who provides gtk-update-icon-cache and add it to RDEPENDS of adwaita-icon-theme-symbolic package I'd say? Apr 06 11:54:37 the gtk-update-icon-cache is present Apr 06 11:55:07 but it runs an update-alternative and do it after adwaita-icon-theme needs it Apr 06 11:55:33 gtk-update-icon-cache-3.0 -> gtk-update-icon-cache Apr 06 11:57:49 ah, fun Apr 06 11:58:00 file a bug please Apr 06 11:58:09 at least you can re-run the install and it will work now Apr 06 11:58:32 https://pastebin.com/0fSSAQDj Apr 06 11:58:44 yes a re-run works Apr 06 11:59:15 //var/lib/opkg/info/adwaita-icon-theme-symbolic.postinst: line 14: gtk-update-icon-cache: command not found Apr 06 11:59:16 then Apr 06 11:59:21 update-alternatives: Linking /usr/bin/gtk-update-icon-cache to /usr/bin/gtk-update-icon-cache-3.0 Apr 06 12:27:55 New news from stackoverflow: Bitbake do_package_qa error: Wrong location Apr 06 12:41:01 Hi Yocto members. Do you have good examples (well written and organised) of Yocto distro to share. Thanks! Apr 06 12:42:34 meta-yoe? Apr 06 12:43:04 though poky is a good example. takes oe-core and adds a tiny customisation on top in meta-poky Apr 06 13:38:15 hi guys ! Apr 06 13:39:24 Hello Apr 06 13:41:54 hi Apr 06 13:48:01 I have a quick dnf question if you don't mind : I installed it for the first time and my image size doubled right away, from 300 to 600MB. I cannot find where this comes from, the new packages in the buildhistory's installed-package-sizes.txt take 40MB all together. Apr 06 13:48:39 Or does dnf install things which are not visible in this list maybe ? Apr 06 13:55:24 rburton: Thank you ! Apr 06 14:05:25 I have two variants of local.conf, one for development builds (local.conf.dev) and one for production builds (local.conf.prod). Currently I have advise developers to move the local.conf.dev to local.conf, and to make sure that they never commit that change. However, this practice seems fishy. Is there any clean way to accomplish having two slightly different local.confs? Apr 06 14:06:00 problame: what do you have in your local.conf which warrants two different ones? Apr 06 14:07:44 qschulz: dev-vs-prod ssh authorized_keys entries, different packages installed, etc Apr 06 14:07:59 I found https://www.yoctoproject.org/pipermail/yocto/2018-June/041372.html Apr 06 14:08:12 Is that what I'm supposed to do? Create different distros? Apr 06 14:13:22 hm, the people on the thready seem to agree that this is bad practice Apr 06 14:14:28 I _could_ have two variants of my image recipe, one for dev and one for prod. However, that doesn't necessarily cover all the options I set in `local.conf` Apr 06 14:14:36 (like, e.g. DISTRO_FEATURES) Apr 06 14:23:33 problame: DISTRO_FEATURES changed? new distro :) Otherwise, you give a script which does the local.conf.dev > local.conf and you add local.conf to .gitignore? Apr 06 14:25:12 qschulz: I want to do things right, so if creating a new distro is the way to go, that's what I'll do Apr 06 14:29:17 curious what distro features you're changing for dev vs prod Apr 06 14:33:03 basically local.conf should only be *local* tweaks Apr 06 14:39:31 rburton: yeah, i "inherited" that project from a code-drop from some other company Apr 06 14:40:05 got deep into yocto over the past two weeks, still a lot to learn though, it seems to me that best practices are not really encouraged, even in many books about Yocto Apr 06 14:40:28 (and it seems like the devs I inherited the project from built the entire product based on `local.conf` /o\ ) Apr 06 14:42:38 boo Apr 06 14:43:01 we should have a hall of shame I think :D Apr 06 14:43:25 a lot of the time the dev image is just the normal image included into the recipe but extra packages and ssh/password/etc changes Apr 06 14:43:28 all of which is image-wide Apr 06 14:43:46 maybe switch packages to pull in different configurations Apr 06 14:44:26 if you really do need to change distro features for dev then have two distros and makes sure that the dev one simply includes the main one then adds what it needs, to ensure that they're mostly identical Apr 06 14:49:49 rburton: the DISTRO_FEATURES question was more or less theoretical, although I don't really get why we have the concept of distros in addition to image recipes Apr 06 14:50:07 if you have the time to spare, I'd be interested in learning about that Apr 06 14:50:12 distro is a wider scope that images Apr 06 14:50:19 you may well want more than one image Apr 06 14:50:28 a production and a development one, for starters Apr 06 14:50:42 or an initramfs and the full filesystem Apr 06 14:53:55 and the relationship between distro and image is 1:many? Apr 06 14:55:05 (also one practical question: when creating my own distro in meta-mycompany/conf/distroy/mydistroy.conf, do I need to `require` or `inherit` from something? I basically want `poky` but with a few tweaks to `DISTRO_FEATURES`, encapsulated in the mycompany layer Apr 06 14:55:06 problame: https://www.youtube.com/watch?v=o-8g0TPVVGg Apr 06 14:56:24 problame: i'm not sure you want to inherit poky, it can drastically change if the project want between two releases. The point of poky AFAIU is to provide a test distro for build servers and tests. So for example, one day it might change to systemd as init system Apr 06 14:58:06 problame: with LetoThe2nd example IIRC, a distro is a "choice of materials": legos or mechanos? an image is what you create with it: boat? car? house? Apr 06 15:00:11 qschulz: as I said, I'm refactoring an existing project that was entirely in local.conf into a structure that follows yocto best practices Apr 06 15:00:58 since the local.conf used poky as distroy, but changed some DISTRO_FEATURES, I want to make a lateral move (no changes, just code / config structure) Apr 06 15:01:17 so... under that premis, do I need to require or inherit something? Apr 06 15:04:36 problame: well yes, poky distro file then :) Apr 06 15:05:16 problame: (BTW, we use poky and local.conf here as well, I still haven't found the time to migrate all this to our own distro :) ) Apr 06 15:07:46 problame: if you're starting with Yocto, I highly recommend the tutorials on YP Youtube channel. Also, always try to find some info from the mega-manual, if there's one thing we cannot say about YP is that it has just basic documentation :) Apr 06 15:12:49 qschulz: compared to other embedded linux distros, the docs are fairly good imho Apr 06 15:13:14 i usually avoid youtube due to signal/noise ration, but the channel seems worthwhile (maybe should be promoted more aggressively in the manuals?) Apr 06 15:13:24 anyways: so how do I inherit from poky? Apr 06 15:14:53 I like to think of a distro as the "policy" of a system (e.g. when separating "policy" vs "mechanism") Apr 06 15:15:56 recipes are the mechainsm for doing things, but as a general rule shouldn't specify policy (other than a sane default), where as the distro should be describe policy, but avoid trying to implement mechansims Apr 06 15:16:55 i could just `require conf/distro/defaultsetup.conf` (the project is still on 2.5 /o\) Apr 06 15:16:58 ? Apr 06 15:17:11 defaultsetup.conf is included already by bitbake.conf, and isn't poky Apr 06 15:17:16 poky.conf defines poky Apr 06 15:17:47 but inheriting fro another distro isn't always just a matter of pulling in its config, if you're using recipes with any distro-specific conditionals, you also want to adjust DISTROOVERRIDES so both those and your own are applied Apr 06 15:18:11 and you might be better off just copying than inheriting, otherwise future changes to the base distro could cause problems for you Apr 06 15:25:18 what kergoth said. start by copying poky.conf and then deleting the bits you don't need Apr 06 15:29:23 kergoth: huh, I can't find a poky.conf in my tree (2.5) Apr 06 15:29:53 unless you have meta-poky/meta-yocto, you probably aren't using poky at all. what's DISTRO set to in local.conf? Apr 06 15:33:12 sry, found `poky.conf` after all, apparently `fdfind` is a bit too smart Apr 06 15:34:23 (DISTRO was defaulting to `poky`, so that matches) Apr 06 15:34:40 so, do I understand correctly that `defaultsetup.conf` is much less of a moving target than `poky.conf`? Apr 06 15:52:11 problame: correct Apr 06 15:55:19 * RP triggers 3.1 rc1 build Apr 06 15:55:38 \o/ Apr 06 16:09:33 Yay! Apr 06 16:10:04 What's the easiest way to get detailed results of oe-selftest runs? detailed logs? specifically the .sum/.log files of the toolchain suites? Hmm, guess i'll grab ${B} and go frmo there Apr 06 16:18:00 RP: should I go ahead and revert those coreutils patches? Apr 06 16:19:23 tgamblin: no Apr 06 16:19:52 tgamblin: its a pain and we need to come up with better ways of dealing with this but if we were reverting we should have done it weeks ago Apr 06 16:20:11 RP: alright Apr 06 16:20:15 kergoth: there is a testresults.json file with them all in? Apr 06 16:36:58 curious: an empty meta-mycompany/conf/distroy/mydistro.conf with IMAGE_FEATURES=ssh-server-openssh gives me a shell with _no prompt_ at all Apr 06 16:49:36 can i write and call a python helper function for the do_compile task in a recipe? not just for a variable assignment Apr 06 16:50:14 opello: you can even have a full python task if you want Apr 06 16:50:26 can i mix and match? Apr 06 16:50:54 like a nominal do_compile() with shell script and a `python do_compile_prepend()`? Apr 06 16:51:14 opello: I don't think so, the full task has to be Apr 06 16:51:35 opello: but you can call python functions from shell tasks, let me get you the thing Apr 06 16:51:47 oh ok, nice, thanks! Apr 06 16:52:15 opello: ${@mypythonfunction()} Apr 06 16:52:33 ah yeah, it said that was for variable assignment, just ignoring the result is reasonable? Apr 06 16:52:39 but beware, it is impossible to pass variables between tasks (if that was in your mind) Apr 06 16:53:18 hm, i hadn't thought of the need to do that, but i'll file that away too :) Apr 06 16:54:09 opello: we use it in shell but mainly check the returned value Apr 06 16:59:42 hm, seems like it needs to wait until after fetch but is happening at parse time Apr 06 17:01:07 opello: what do you want to do? what's the issue :) Apr 06 17:04:38 heh sorry, i wrote a python function to manipulate some files in a silly, but required, way; they are in the SRC_URI; it's in essence a "compile" step from my perspective, so my do_compile() has the @{$helper(d.expand('${WORKDIR}/filename'), d.expand('${B}/filename')} and then calls gzip on the ${B} version; but the complaint is that the input doesn't exist (which i'm just testing my recipe with `bitbake-layers show-recipes` to trigger the ... Apr 06 17:04:44 ... parse, so no fetch yet) Apr 06 17:06:15 i flipped the $/@ in my written form, but it's correct in the recipe Apr 06 17:07:05 opello: but the complaint is that the input doesn't exist (which i'm just testing my recipe with `bitbake-layers show-recipes` to trigger the ... Apr 06 17:07:11 ? Apr 06 17:07:49 how did you define your python function? Apr 06 17:07:55 the exact "header" of the function is? Apr 06 17:08:11 def remove_layers(base_file, target_file, output_file): Apr 06 17:10:00 but why would a bitbake-layers show-recipes trigger a file not found? Apr 06 17:10:06 it shouldn't be executed at parse time Apr 06 17:10:17 that's what i thought :/ Apr 06 17:11:45 opello: mmmm what's d.expand supposed to do? Apr 06 17:12:09 ExpansionError during parsing : Failure expanding variable do_compile: ExpansionError: Failure expanding variable do_compile, expression was ${@remove_layers...}\n gzip -9 ... (then says IOError: [Errno 2] No such file or directory: Apr 06 17:12:40 pass variables from the recipe to the helper? should i have to pass 'd' and use d.getVar or d.expand for that? Apr 06 17:13:11 opello: wait... what is the xact line you're writing? Apr 06 17:13:33 you should have do_compile_prepend() { ${@mypythonfunction()} } Apr 06 17:13:45 not do_compile = ${@mypythonfunction()} Apr 06 17:14:16 i just put it in the body of the do_compile; so my do_compile (shell version) is two lines, ${@...}\ngzip -9... Apr 06 17:14:37 in essence the former from your examples Apr 06 17:15:48 https://gist.github.com/opello/7a1cadaf09d721431e392ad054b644e6 Apr 06 17:21:13 opello: I think you're trying to do too many things in your compile Apr 06 17:21:28 just pass d to your python function Apr 06 17:21:36 then d.getVar() Apr 06 17:21:46 might need an import os somewhere Apr 06 17:23:52 i just made a shim that does that, changed the error a bit, but still fails with: which triggered exception IOError: [Errno 2] No such file or directory: Apr 06 17:24:33 i was trying to avoid making a -native helper tool recipe that i'd ultimately depend on Apr 06 17:25:48 do you really need to do your thing in python :)? Apr 06 17:26:46 opello: remove one parameter after the other and try to find the one which is messing up. But it's very confusing it's failing at parsing time Apr 06 17:27:04 it's _a lot_ easier than doing it in a shell script :( Apr 06 17:28:16 i think the failure is that ${@...} is evaluated at parse time, which does things that rely on files existing (like opening and reading them) but that can't happen because they aren't there yet (parse is way before fetch)? Apr 06 17:28:50 i was just thinking i could add a new, custom task, defined in python, that used my helper function, and chain to to happen before do_compile? Apr 06 17:29:03 New news from stackoverflow: Yocto cross compile Qt5 'qtConfig' is not a recognized test function Apr 06 17:29:53 opello: you need to handle the sstate-cache somehow, I wouldn't really recommend Apr 06 17:30:38 opello: start small. def myfunc(d): return "test" do_compile_prepend() { ${@myfunc(d)} odes this work? Apr 06 17:31:33 opello: start small. def myfunc(d): return "test" do_compile_prepend() { ${@myfunc(d)} odes this work? Apr 06 17:31:36 oopsie :) Apr 06 17:32:36 yeah, it works, i see my print('hello world') after parse Apr 06 17:32:54 which is a problem, i need to defer the python execution until the actual do_compile is run Apr 06 17:33:48 FOO="${@myfunc(d)" in do _compile? Apr 06 17:35:27 sure, so with that (i added a return after my print) i expect i'd see FOO="hello world" in the run.do_compile.sh Apr 06 17:38:11 mmm so now that I read my code, it seems that we have functions which aren't dependent of when they're run Apr 06 17:39:19 opello: so mmmm... No clue, I'd say it's expected behavior (to execute ${@func()} at parse time) but I wasn't aware of that, so either I forgot, didn't read it yet or it's not documented or I'm wrong :) Apr 06 17:40:27 opello: can you try with do_compile[prefuncs] += "remove_layers"? heopfully you have access to d in there Apr 06 17:41:14 yup, looks like it's possible :) Apr 06 17:41:41 WARNING: Function call_remove_layers doesn't exist Apr 06 17:41:56 (that's the shim that takes d only and uses getVar) Apr 06 17:42:27 isn't this just side-stepping the tasks sysetm though? Apr 06 17:42:28 no parameters to the function Apr 06 17:42:49 d will be available in the context of the function without passing it Apr 06 17:42:57 testing :) Apr 06 17:43:31 but I've to say, gzip only in a compile looks fishy :) Apr 06 17:43:52 yeah :( i'm not ready to defend what i'm actually trying to do ... Apr 06 17:44:37 i keep getting WARNING: Function doesn't exist; whether it's a def foo(): or a python foo() {} Apr 06 17:52:25 huh, but i'm defining it just like rootfs_deb.bbclass does :/ Apr 06 17:55:59 opello: it might also depend where you're trying to run that Apr 06 17:58:30 bitbake -e shows the body in a comment block ($call\n_remove[layers] ast.py...) and a body of None later on for the actual function expansion Apr 06 17:59:32 seems like that naming is special, because if i put gibberish in, it preserves it Apr 06 18:00:31 opello: do not use remove in the name Apr 06 18:00:37 its a bitbake operator Apr 06 18:00:46 ah yeah, heh, oops Apr 06 18:00:49 (append, prepend and remove are special) Apr 06 18:01:02 * RP wishes we could spot those and warn :/ Apr 06 18:01:23 "this function looks suspiciously like a variable manipulation!" Apr 06 18:01:43 opello: wait.... so you could maybe actually call your python function from your shell without "remove" in it? Apr 06 18:01:50 i don't envy the difficulty :) Apr 06 18:02:04 opello: I tried once before to add such warnings and failed :( Apr 06 18:02:06 qschulz: i don't think it changes the time of execution issue though Apr 06 18:02:12 * RP needs to try harder, clearly :/ Apr 06 18:02:15 opello: mmmm correct Apr 06 18:02:40 RP: just would have saved a little time here, i'm trained to check -e too late for my own good a lot it seems Apr 06 18:02:55 zeddii, sorry about the multiple kernel-cache submissions. I thought my email client was not set up properly Apr 06 18:03:23 RP: while you're here :) we went for postfuncs because calling ${@func()} would generate some errors *at parsing time* Apr 06 18:03:58 RP: 19:12 opello| ExpansionError during parsing : Failure expanding variable do_compile: ExpansionError: Failure expanding variable do_compile, expression was ${@remove_layers...}\n gzip -9 ... (then says IOError: [Errno 2] No such file or directory: Apr 06 18:04:43 RP: ${@remove_layers(d.expand('${WORKDIR}/${DOCKER_BASE_FILE}'), d.expand('${WORKDIR}/${DOCKER_IMAGE_FILE}'), os.path.splitext(d.expand('${B}/${DOCKER_IMAGE_FILE}'))[0])} in do_compile Apr 06 18:04:56 in this instance the ${@pythonfunc()} was opening a file that didn't exist yet, because fetch hadn't happened Apr 06 18:05:21 (thus EIO) Apr 06 18:06:02 RP: I dont' remember reading in the docs that python functions called like this are executed at parsing time? Is this correct? Apr 06 18:06:18 this = my understanding of how this works Apr 06 18:12:45 qschulz: bitbake has to expand variables/functions at parse time to compute their hashes Apr 06 18:13:00 qschulz: so yes, anon python will execute during parsing in many cases Apr 06 18:14:03 qschulz: The recent fix for SOURCE_DATE_EPOCH that went into bitbake a few hours ago is an example of a case where we defer it (not deferring it was leading to a similar FileNotFound bug) Apr 06 18:58:15 Hi guys, I want to add ovs/dpdk to my Yocto image (zeus) with my own kernel recipe (4.19) but ovs of Zeus is compatible until Kernel 4.17 only. So I had to take ovs and dpdk from meta-{virtualization,dpdk} master branch Apr 06 18:59:07 but I have this weird failure: build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/recipe-sysroot-native/usr/bin/python3-native/python3, but no providers found in RDEPENDS_openvswitch? [file-rdeps]" Apr 06 19:00:05 I see that python3 is already defined as RDEPENDS: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-networking/openvswitch/openvswitch.inc?h=master Apr 06 19:00:37 Do I miss something obvious ? (all my cache was cleaned) Apr 06 19:10:21 ebail: weird that it's taking python3 from recipe-sysroot-native for file-rdeps Apr 06 19:15:06 (it seems like a wrong auto-RDEPENDS, it seems like one of your file has defined it's using recipe-sysroot-native/usr/bin/python3-native/python3 at runtime somehow, which isn't possible) Apr 06 19:18:06 qschulz: Thanks I only copy the files from the master branch without modifying them: http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-networking/openvswitch Apr 06 19:19:54 QA file-rdeps complains about ovs-vtep file Apr 06 19:20:56 Indeed I don't understand its first location: Apr 06 19:21:00 $ find build/ -name ovs-vtep Apr 06 19:21:02 build/tmp/sysroots-components/votp/openvswitch/usr/share/openvswitch/scripts/ovs-vtep Apr 06 19:21:04 build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/packages-split/openvswitch/usr/share/openvswitch/scripts/ovs-vtep Apr 06 19:21:06 build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/package/usr/share/openvswitch/scripts/ovs-vtep Apr 06 19:21:08 build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/image/usr/share/openvswitch/scripts/ovs-vtep Apr 06 19:21:10 build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/sysroot-destdir/usr/share/openvswitch/scripts/ovs-vtep Apr 06 19:21:12 build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/build/vtep/ovs-vtep Apr 06 19:22:53 and: cat build/tmp/sysroots-components/votp/openvswitch/usr/share/openvswitch/scripts/ovs-vtep | head Apr 06 19:22:55 #! yocto-bsp/build/tmp/work/votp-poky-linux/openvswitch/2.13+AUTOINC+71d553b995-r0/recipe-sysroot-native/usr/bin/python3-native/python3 Apr 06 19:29:32 New news from stackoverflow: Yocto cross compile Qt5 cstddef: No such file or directory Apr 06 19:31:51 qschulz: I looks like the file use #! @PYTHON3@ (src: https://github.com/openvswitch/ovs/blob/master/vtep/ovs-vtep.in) Apr 06 19:42:51 <[Sno]> otavio: wow Apr 06 19:52:47 [Sno]: ? Apr 06 19:58:03 <[Sno]> otavio: merged PR in the second I submitted it :D Apr 06 20:17:35 [Sno]: the changes were simple Apr 06 20:27:47 <[Sno]> otavio: linux-qoriq update to lsdk 20.04 I can do hopefully tomorrow Apr 06 20:28:41 <[Sno]> if there is something else required to be updated, drop me a line - as long I'm in update-mood ;) Apr 07 02:00:48 New news from stackoverflow: How to specify git branch in Yocto recipe **** ENDING LOGGING AT Tue Apr 07 02:59:57 2020