**** BEGIN LOGGING AT Mon Nov 09 03:02:03 2020 Nov 09 07:37:29 good morning Nov 09 07:44:25 hi there Nov 09 07:45:39 whenever I restart my SBC I need to manually login as well as manually connect to my wifi. Is there a way to make this do automatically everytime I restart or even boot? Nov 09 08:40:32 yo dudX Nov 09 08:43:55 hi LetoThe2nd Nov 09 09:04:23 morning Nov 09 09:05:54 much so, indeed. Nov 09 09:06:22 I am trying to build qtwebengine using the dunfell branch and running into Nov 09 09:06:27 /usr/include/c++/7/cstddef:49:10: fatal error: bits/c++config.h: No such file or directory Nov 09 09:06:27 #include Nov 09 09:06:27 ^~~~~~~~~~~~~~~~~~ Nov 09 09:06:27 compilation terminated. Nov 09 09:07:51 abelal: any specifica about your build? or is it really just poky+meta-qt on dunfell head? Nov 09 09:08:10 hmmm good question Nov 09 09:09:15 poky: 33fdf03169ab2a3355e090d41ba034855d47f865 Nov 09 09:09:16 meta-qt5: a22f0e22524a921422740ce640187e14dd829552 Nov 09 09:10:53 * LetoThe2nd will admittedly not look up the hashes now. Nov 09 09:11:03 any other stuff in the mix? Nov 09 09:11:24 any specific configuration? etc. pp. Nov 09 09:12:46 mmm if it makes any difference i'm building one of the atmel machines, sama5d27 to be specific but I don't think that would play a role Nov 09 09:12:58 nothing has been changed in the default configs Nov 09 09:13:29 maybe I am missing something on the host? Nov 09 09:13:53 do I need the g++multilib on the host? Nov 09 09:14:00 abelal: that rings a bell, I think if you're building on a 64-bit host for a 32-bit target you need some extra stuff to build qtwebengine Nov 09 09:16:17 abelal: something like lib32stdc++-5-dev gcc-multilib g++-multilib would solve it on old ubuntu 18.04 Nov 09 09:17:07 So if you translate that to your current build host os, it should work Nov 09 09:25:30 hmmmm Nov 09 09:25:39 thanks erbo I'll try that out Nov 09 09:27:46 erbo: indeed, qt5 still pulls in a few host headers Nov 09 09:27:48 JaMa: ^ Nov 09 10:06:19 hello folks o/ congrats on the gatesgarth release Nov 09 10:13:57 no condolences? Nov 09 10:18:30 LetoThe2nd: condolences on zeus being EOL Nov 09 10:19:08 qschulz: ++ Nov 09 10:30:27 manuel1985: howdy! just had a look concerning the esdk problem with container distro. sadly, can't really reproduce it :( Nov 09 10:33:00 manuel1985: i initially thought linux-dummy would be problematic, but it doesn't seem to be the case, at least not directly. its basically unmaintained, but can you try with https://github.com/LetoThe2nd/meta-containerization.git being the base setup of the container distro? just add dunfell to the compatible series, it should work Nov 09 11:02:01 Hey everyone, I've got a technical question. Me and a colleague developed a small device for disaster preparedness for scientific purposes. We used the orange pi zero LTS (http://www.orangepi.org/orangepizerolts/) so far and were quite happy with it. Before we build some 100 devices based on that I would like to have an external opinion if somebody more experienced sees a very obvious prohibitive reason not to use that Nov 09 11:02:02 board. I'm not a truly embedded expert event though I managed (after a really steep learning curve) to get our yocto linux running on that board... So, do you have any opinion on that board? Nov 09 11:03:22 emrius: You may want to try #elinux as that's not really Yocto specific Nov 09 11:07:10 paulbaker: Ah ok, great! I will drop a message there as well. Thanks Nov 09 11:11:16 emrius: if it fits your needs and the hw does what you want under the specifications you need and they guarantee, why not. the only thing that obviously comes to my mind is that i would be very reluctant to base a long term solution on a board like that - just for reasons of availability etc. if its a one-off, you can just judge by specs/price. Nov 09 11:13:19 LetoThe2nd: Thanks for your valuable feedback!! That helped a lot. We kind of trust the 'LTS' suffix but, well, you never know... Nov 09 11:14:28 emrius: trust in suffixes is worth exactly nothing, unless they guarantee - in written, legally binding form - a specific timeframe for availability. and even that can be broken. Nov 09 13:01:04 kanavin_home: another thing we should work on is reproducible builds for world Nov 09 13:22:07 manuel1985: correction: i can reproduce it. Nov 09 13:25:09 zeddii: hey CCC (crazy canadian club)! Nov 09 13:28:25 * zeddii pops up Nov 09 13:29:17 \m/ Nov 09 13:31:04 zeddii: fun observation (a.k.a. unexpected behaviour a.k.a. probably bug n.a.k.a. feature): populate_sdk_ext breaks with some error about unexpected tasks if linux-dummy provides the kernel. any pointers? interested in a log? Nov 09 13:32:41 I have seen that float by, but I can't recall exactly where. A log would be helpful. Nov 09 13:34:59 oh zeddii is here Nov 09 13:35:00 how handy Nov 09 13:35:04 as perf just exploded Nov 09 13:35:38 2020-11-09 13:18:23 - ERROR - /builds/work/build/tmp/work/tc0-poky-linux/perf/1.0-r9/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/10.2.0/ld:/builds/work/build/tmp/work/tc0-poky-linux/perf/1.0-r9/perf-1.0/plugins/libtraceevent-dynamic-list:2: syntax error in dynamic list Nov 09 13:35:42 zeddii: ^^ thoughts? Nov 09 13:36:14 what kernel version is it from ? That smells like the binutils issue. Nov 09 13:36:47 * rburton mumbles Nov 09 13:36:57 good news, i can replicate Nov 09 13:37:00 yeah maybe it is Nov 09 13:37:22 there's a libtraceevent commit to fix that right up, I sent the patch to someone else just last week :D Nov 09 13:37:35 now only, if I could find the directory I exported the patch to. .. Nov 09 13:38:12 - $(NM) -u -D $1 | awk 'NF>1 {print "\t"$$2";"}' | sort -u;\ Nov 09 13:38:12 + $(NM) -u -D $1 | awk 'NF>1 {sub("@.*", "", $$2); print "\t"$$2";"}' | sort -u;\ Nov 09 13:38:15 that one? Nov 09 13:38:15 ahah. there is Nov 09 13:38:19 From c2fd34d4311033120fa502aa8bd4723cdeee0103 Mon Sep 17 00:00:00 2001 Nov 09 13:38:19 From: Ben Hutchings Nov 09 13:38:19 Date: Sat, 25 Jul 2020 02:06:23 +0100 Nov 09 13:38:21 Subject: [PATCH] libtraceevent: Fix build with binutils 2.35 Nov 09 13:38:25 yes, thats it Nov 09 13:38:33 now to scream at vendor kernel people Nov 09 13:38:52 I couldn't actually remember what the binutils problem looked like :) Nov 09 13:39:04 neither could I (when asked last week). Nov 09 13:39:11 you just arrived before I flushed it out of the cache Nov 09 13:40:56 of course this is the android kernel, for mystery reasons Nov 09 13:42:19 YOU CAN'T HANDLE THE TRUTH Nov 09 13:42:36 the truth will make me angry Nov 09 13:43:05 no doubt there. Nov 09 13:44:05 no doubt, indeed. https://youtu.be/TR3Vdo5etCQ Nov 09 13:45:52 zeddii: http://paste.ubuntu.com/p/HzVJ8nZ5WT/ Nov 09 13:48:19 ahah. yes, I have seen that. It might have been internally. it's similar to the "linux-dummy: Add do_compile_kernelmodules" fix in oe-core. Nov 09 13:48:53 zeddii: something in gatesgarth/master? Nov 09 13:49:46 that's from 2019, when we added the empty task to keep things moving. I recall in the thread (that I can't find now), that do fetch was done the same way. Nov 09 13:50:07 the eSDK is heavily used here, so it must be in my 'work' email. Nov 09 13:51:08 zeddii: well i gave it a quite tinkering test and added empty fetch and package_setscene tasks, but that didn't do thetrick. Nov 09 13:51:27 hmm. exactly the same error ? Nov 09 13:52:07 lemme re-run Nov 09 13:52:39 I have similar classes for containerizing meta-virt apps, but I don't think the internal folks are using them, so they haven't been run against the eSDK. Nov 09 13:56:26 hum, you tell me: http://paste.ubuntu.com/p/2JfKS2b9SY/ Nov 09 13:59:27 hmm. yes, looks the same. tried to run unexpectedly. Nov 09 13:59:29 * zeddii ponders. Nov 09 14:00:51 i'd say it goes boom. https://youtu.be/OriR-vTOqYg Nov 09 14:06:56 zeddii: any pointers where i could start digging? Nov 09 14:08:26 not yet, trying to find that reference. I found the EFI one, but that was a misconfiguration on something that should never have depended on kernel .. but yours has a valid virtual/kernel depedency. Nov 09 14:08:55 so I understand, this is the first time you've tried it with the eSDK ? i.e. it hasn't been broken, it just may have never worked. Nov 09 14:11:22 zeddii: never tried so far, has been reported to me too. just having that famous short look.. Nov 09 14:11:45 * zeddii nods Nov 09 14:12:23 I'm thinking I'll run into this soon in my Xilinx stuff, so I'm interested. trying to mock up a reproducer here. Nov 09 14:13:09 zeddii: thx. Nov 09 14:13:26 manuel1985: so here you go ^^^^ Nov 09 14:29:55 RP: right, one challenge for reproducible world is that world takes a lot of time to build from scratch Nov 09 14:30:48 kanavin_home: it should happen in parallel with other selftests so that in itself shouldn't stop us. We could also exclude some specific recipes if that help... Nov 09 14:30:50 RP: I guess that can be addressed by having dedicated builders that take reproducibility test, and do just that Nov 09 14:31:45 RP: I guess llvm and webkit are the worst offenders in core Nov 09 14:32:12 mhh... wurst offenders... Nov 09 14:41:34 kanavin_home: selftest is parallelised so the reproduibility should already be run it its own thread FWIW Nov 09 14:51:37 in https://docs.yoctoproject.org/ref-manual/ref-variables.html?highlight=bbmask#term-BBMASK, why do we have one example with a leading / and one without? Nov 09 14:52:42 and more specifically, which one's correct :p? Nov 09 15:03:04 devtool hates me. i have a kernel recipe with a line like this in SRC_URI "file://arch/arm64/boot/dts/;subdir=git/", the goal is to keep devicetree files in the layer to work better with it. Nov 09 15:03:44 when i run devtool modify my-kernel, it ignores the files in arch/arm64/boot/dts/, nothing is copied to oe-local-files Nov 09 15:04:02 and when i run devtool finish or update-recipe device unlinks all files from arch/arm64/boot/dts/ Nov 09 15:04:05 WTF Nov 09 15:04:15 is this a bug? a feature? Nov 09 15:04:53 devtool update-recipe seems to have --no-remove, sounds better Nov 09 15:04:59 but devtool finish has not :-( Nov 09 15:06:22 derRichard: devtool doesn't work like do_patch() Nov 09 15:06:40 what does this mean? Nov 09 15:06:53 sadly, I use devshell since that calls the real do_patch() and working tree is always setup correctly just like for do_compile() Nov 09 15:07:08 RP: right, but it still shared the same worker machine with the rest of the selftest, and it'd probably be better to allocate a dedicated worker? Nov 09 15:07:11 devtool and bitbake build apply patches from SRC_URI differently Nov 09 15:07:37 kanavin_home: in practise its not been too bad. You could argue that for several of the oe-selftests Nov 09 15:07:59 mcfrisk: so devtool crap and should not be used? ;-) Nov 09 15:08:25 derRichard: patches to improve it and add more tests welcome Nov 09 15:08:41 derRichard: errm, well yea... :( Nov 09 15:09:15 RP: i'm currently reading devtool source, yes Nov 09 15:09:19 i makes me very sad Nov 09 15:09:29 *it Nov 09 15:09:40 anyway, sorry for the rant. i try to find a solution Nov 09 15:09:50 first i need to understand what exactly is going on Nov 09 15:10:00 RP: right, I hope to find a bit of time to work on this. Nov 09 15:11:36 derRichard: why subdir for your SRC_URI? Nov 09 15:12:39 qschulz: because it is useful to have stuff like customer specific device tree files in the layer instead in the patch queue Nov 09 15:13:17 and by talking away my use case we cannot get devtool fixed ;-P Nov 09 15:14:26 derRichard: I'm not questioning DTS files in layer (though... well..) but rather why subdir is git and why you need this? Nov 09 15:15:43 qschulz: i've always used it like that. is there a better way to host my dts file in the kernel recipe dir? Nov 09 15:20:53 in devtool source i see: Nov 09 15:20:54 # Ignore local files with subdir={BP} Nov 09 15:20:54 srcabspath = os.path.abspath(srcsubdir) Nov 09 15:20:55 local_files = [fname for fname in local_files if os.path.exists(os.path.join(workdir, fname)) and (srcabspath == workdir or not os.path.join(workdir, fname).startswith(srcabspath + os.sep))] Nov 09 15:21:08 does do we need to ignore subdir={BP} files? Nov 09 15:21:17 *why do we Nov 09 15:25:33 derRichard: is S = ${WORKDIR}/git in your recipe? Nov 09 15:25:45 yes Nov 09 15:25:50 could you put subdir to ${S} instead of git? Nov 09 15:26:04 s/put/set Nov 09 15:26:25 does not work. bitbake wants subdir to be a subdir of ${WORKDIR} Nov 09 15:26:37 shit Nov 09 15:26:40 I think that's the issue Nov 09 15:27:37 because devtool unpacks and stores files/sources differently than "Yocto" Nov 09 15:28:35 grrrrrr Nov 09 15:28:51 derRichard: but you're already in the source code so go on with it Nov 09 15:28:57 but that's my wild guess Nov 09 15:29:24 yeah, i'm trying to figure what is wrong :( Nov 09 15:30:06 derRichard: FYI, I had issues with patches with patchdir=.. (patching the files from the layers, don't ask why we wanted to do that please) Nov 09 15:31:21 is there another way to have dts files for the kernel outside of the kernel source tree? Nov 09 15:32:18 derRichard: I would first try to install the files without intermediate subdirectories in the layer Nov 09 15:32:30 so remove arch/arm64/boot/dts/ from your path Nov 09 15:33:02 if it still does not work, you could remove subdir=git and manually put your DTS into the correct place by adding a do_configure_prepend cp'ing them to the correct dir Nov 09 15:39:09 qschulz: sorry, i don't understand. the line is "file://arch/arm64/boot/dts/;subdir=git/" what shall i remove? Nov 09 15:39:26 hello, even though lua itself is part of meta-oe, it does not seem Yocto project or meta-opembedded are packaging any lua components like lua-openssl, etc. Nov 09 15:40:31 hmm, i see in devtool "if bb.data.inherits_class('kernel-yocto', rd)" Nov 09 15:40:35 but my kernel recipe does: Nov 09 15:40:36 inherit kernel Nov 09 15:40:36 require recipes-kernel/linux/linux-yocto.inc Nov 09 15:40:40 maybe this is the problem? Nov 09 15:40:47 Would upstreaming more recipes for lua be welcome in meta-openembedded or somewhere else in yocto project related layers? Nov 09 15:43:42 meta-oe is fine unless you end up adding so many that a meta-lua makes sense Nov 09 15:44:04 derRichard: linux-yocto.inc inherits the kernel-yocto bbclass Nov 09 15:44:22 So that should be true already Nov 09 15:47:46 looks like this if does not evaluate to true for me: Nov 09 15:47:47 if (os.path.exists(srcdir) and os.listdir(srcdir)) and (kernelVersion in staging_kerVer and staging_kbranch == kbranch) Nov 09 15:52:30 derRichard: my 2ยข on os.path.exists(srcdir) ;) Nov 09 15:52:57 i bet on staging_kbranch == kbranch Nov 09 15:52:58 :D Nov 09 15:53:02 (if srcdir is supposed to be where your files are exported) Nov 09 15:53:07 debug patch in progress Nov 09 16:03:24 I get lua-openssl-20200709-rc1 do_package_qa: QA Issue: lua-openssl: The install log indicates that host include and/or library paths were used. Nov 09 16:03:46 Does it say anywhere what specific installation command does this? Nov 09 16:05:12 here is the log: https://pastebin.com/ZV6F6XGs Nov 09 16:05:38 can not really spot what the offending line is Nov 09 16:06:25 qschulz: shouln't this work? Nov 09 16:06:26 do_configure_prepend() { Nov 09 16:06:26 cp -a ${WORKDIR}/mydts ${S}/arch/arm/boot/dts/ Nov 09 16:06:26 } Nov 09 16:06:52 kernel build fails to find my dts files and looking to the source dir confirms, nothing copied :( Nov 09 16:07:10 it fails long after do_compile Nov 09 16:07:15 then again, its probably this: rmdir: failed to remove '/tmp/luapath-31f96199004aed82': Directory not empty Nov 09 16:07:38 derRichard: time to check your SRC_URI is correct Nov 09 16:07:51 derRichard: bitbake virtual/kernel -e | grep -e "^SRC_URI=" Nov 09 16:07:54 do you have your files in there? Nov 09 16:09:13 they are there, "file://mydts" Nov 09 16:09:25 othwise cp would fail Nov 09 16:09:27 but it does not Nov 09 16:10:01 indeed, but how come they're not copied and cp "works" then? Nov 09 16:10:30 that's why i'm asking :) Nov 09 16:10:54 * derRichard does a cleanll Nov 09 16:10:56 are you still trying only with devtool or also "normal" bitbake? Nov 09 16:11:04 normal bitbake Nov 09 16:11:11 no devtool at all Nov 09 16:11:30 what do you have in WORKDIR/mydts then? Nov 09 16:13:11 my device tree files Nov 09 16:13:39 in WORKDIR/temp do you have a do_configure? Nov 09 16:13:44 do you have your cp -a in there? Nov 09 16:14:00 let me check Nov 09 16:14:12 will take a few mins. Nov 09 16:17:01 lua-openssl expects a host /tmp directory: mk/luapath:160:: ${TMPDIR:=/tmp} # sane TMPDIR Nov 09 16:17:24 what do I set the TMPDIR in my recipe so that I pass the QA check? Nov 09 16:17:37 not sure what is appropriate to do here Nov 09 16:18:03 create a directory under ${WORKDIR} to act as /tmp? Nov 09 16:19:49 qschulz: yes, i see cp -a ... in my do_configure Nov 09 16:20:18 is ${S} right for the kernel recipe? Nov 09 16:20:51 the yocto kernel class does so much black magic these days :-( Nov 09 16:23:23 ah, yes ${S} seems to be wrong Nov 09 16:23:25 grrr Nov 09 16:23:50 i see the file not under git/, one level above Nov 09 16:24:20 but i have S = "${WORKDIR}/git" Nov 09 16:24:30 i need some booze soon ;) Nov 09 16:28:44 qschulz: oh damn, i'm sorry. arm vs. arm64 Nov 09 16:28:53 time to take a break Nov 09 16:29:24 derRichard: or some booze ;) Nov 09 16:32:04 qschulz: yeah. i tried too much in too little time :D Nov 09 16:32:35 later i'll see how badly devtool interacts with the new do_configure_prepend approach :) Nov 09 17:11:30 qschulz: also when i add my dts files using do_configure_prepend, devtool update-recipe/finish removes them :-( Nov 09 17:13:48 Hello, still pretty new to yocto. I've gotten sdk building & execs work when placed on the target device (both host & target are x86-64), but when running against the build host it is attempting to link using /lib/ld-linux-x86-64.so.2 which doesn't exist on my ubuntu system. Adding as symlink to right ld-linux.so fixes it, however this is meant to be sharable internally. Is there a way to fix/customize this in the sdk Nov 09 17:13:48 installation? Nov 09 17:15:15 christner: is that sdk for 32bit target ? Nov 09 17:15:21 no Nov 09 17:15:21 christner: try apt install libc6-i386 Nov 09 17:15:31 both are 64 bit Nov 09 17:16:32 tried that, already installed Nov 09 17:17:09 christner: apt-file search ld-linux-x86-64.so.2 says this is coming from libc btw Nov 09 17:20:58 christner: tbh, I'd expect that behavior. OE default for target w/o setting up multilib is /lib, not /lib64. Nov 09 17:21:45 christner: if you want to be able to take target binaries and run them on the build host, you'll need to set things up to avoid that Nov 09 17:22:50 yea, looks like libc6, on my ubuntu 18.04 system, it looks like it's located in /lib64/ld-linux-x86-64.so.2 instead of /lib/ld-linux-x86-64.so.2 Nov 09 17:23:11 smurray: where in the yocto build would be a good starting place to look to set this up? Nov 09 17:23:30 smurray: we should change that... Nov 09 17:24:47 RP: heh, it wouldn't shock me if opinions varied on what that default should be Nov 09 17:25:22 smurray: for a long time I never dared change the default but I think I feel brave enough now Nov 09 17:25:45 kanavin_home: pppd maintainer seems keen, might be a good opportunity there :) Nov 09 17:26:18 RP: I wouldn't have any objection here Nov 09 17:26:39 smurray: I keep forgetting to propose a patch... Nov 09 17:27:06 paulbarker: the old stable kernels in meta-stable don't build perf with current gatesgarth. do you want to ship exactly upstream or will you take patches? Nov 09 17:27:17 RP: Morning! Is there a way with tinfoil to get the dependent packages/recipes that would go into creating a given image? Nov 09 17:27:33 it seems to be single recipes or all Nov 09 17:29:31 sgw: you can likely find all dependent tasks. It would have no idea about packages Nov 09 17:32:21 Ok, I will have to dig around a little more, is there some more docuemtation or examples of that other than in the code? Nov 09 17:34:50 christner: I think just inheriting multilib will do it with the defaults it has for x86-64, otherwise you can try over-riding BASELIB. Nov 09 17:35:14 smurray: thanks, I'll give those a go Nov 09 17:44:29 RP: I am missing the context, keen on what, and what is the opportunity? Nov 09 17:45:43 kanavin_home: you're cc'd on a github pppd discussion I think Nov 09 17:46:58 christner: if you try multilib, docs are here: https://docs.yoctoproject.org/dev-manual/dev-manual-common-tasks.html#combining-multiple-versions-library-files-into-one-image Nov 09 17:52:48 RP: I think this patch is primarly of interest https://github.com/openembedded/openembedded-core/blob/master/meta/recipes-connectivity/ppp/ppp/0001-Fix-build-with-musl.patch and it's on Khem to submit that. I'll ping him. Nov 09 17:59:58 rburton: I got the notification half an hour late for that message for some reason. Nov 09 18:00:43 Which kernel versions? I got a fix backported to 4.19, earlier than that may have other issues Nov 09 18:00:47 kanavin_home: thanks, I hadn't been able to look at our patchset yet but it is a rare opportunity to see upstream interested Nov 09 18:05:44 paulbarker: 5.3 and 5.7 Nov 09 18:07:23 rburton: Sadly both those are EOL on kernel.org so I don't want to carry patches for them Nov 09 18:07:29 ok Nov 09 18:07:46 I'm prepping a bbappend for them Nov 09 18:07:59 as perf won't build at all and we still have BSPs that want them Nov 09 18:08:13 smurray: even better, thanks again Nov 09 18:12:36 rburton: On master I'm aggressively dropping recipes for EOL kernels, for releases BSPs should be selecting kernels which are maintained until the expected EOL for that BSP release Nov 09 18:12:52 I'm not going to change anything that would break dunfell or gatesgarth though Nov 09 18:13:01 yeah you'd think that would be obvious wouldn't you Nov 09 18:15:29 I feel guilty that my layer has encouraged the wrong choices there, I can fix that going forward on master at least Nov 09 18:18:00 The idea with meta-kernel was you say "I want a stable kernel" and you follow 5.7 -> 5.8 -> 5.9, or you say "I want an LTS kernel" and you get 5.4 until 5.10 is released and settled in Nov 09 18:18:32 I'll add a todo for this week to really clarify things in the readme Nov 09 18:18:47 Hi all, wanted to know if someone has a recipe to install things via `python3 wheel` Nov 09 18:18:48 I'm renaming it to meta-linux-mainline at some point soon as well Nov 09 18:20:52 I have `tensorflow-lite 1.15.2` installed on the board and the dev team want the python3 tensorflowlite-interpreter which is a downloadable wheel file as mentioned on the documentation page (https://www.tensorflow.org/lite/guide/python?hl=en) Nov 09 18:22:42 I am unaware of any `wheel.bbclass` which I could inherit in the recipe. Nov 09 18:23:43 christner: after a couple of quick experiments here, I think over-riding BASELIB is likely to be a lot less hassle than trying to coax multilib to do what you want Nov 09 18:35:32 Hi! I need to populate extended SDK with Python modules (python3-click). I added Nov 09 18:35:33 TOOLCHAIN_HOST_TASK += "python3-click" Nov 09 18:35:46 to example-image.bb Nov 09 18:37:03 But after installation of the SDK there is no such module for Python3 (sdk_ext/buildtools/sysroots/x86_64-pokysdk-linux/usr/bin/python3) Nov 09 18:39:55 Hi, when i build my SDK i trigger a "ssh-keys-dev : Depends: ssh-keys (= 0.1-r0) but it is not installable" Nov 09 18:40:04 This is coming from : http://git.yoctoproject.org/cgit/cgit.cgi/meta-web-kiosk/tree/recipes-common/ssh-keys/ssh-keys_0.1.bb Nov 09 18:40:35 And this package is selected by CORE_IMAGE_EXTRA_INSTALL += "ssh-keys-server" Nov 09 18:40:49 I'm not sure how to say to Yocto that it's a Runtime depends and not required for SDK dev Nov 09 18:41:21 clementp[m]: You can either allow an empty `ssh-keys` package to be created or override the deps for `ssh-keys-dev` Nov 09 18:42:20 Or prevent the `ssh-keys-dev` package from being created if you really don't need it Nov 09 19:41:26 khem: do you plan on branching gatesgarth for meta-clang at some point? Nov 09 19:44:08 rburton: yes I usually do that a bit later when we approach clang major release. Do you think we should do it now ? if it makes your life easier I could do that Nov 09 19:44:36 i can track master, i just wanted to make sure you were not planning on breaking master when building against gatesgarth ;) Nov 09 20:19:03 keeping master helps me keep my meagre resources testing it for both 3.2 and master as long as I can Nov 09 20:20:06 qschulz: i think i've found the problem Nov 09 20:20:24 remember this if is not true: if (os.path.exists(srcdir) and os.listdir(srcdir)) and (kernelVersion in staging_kerVer and staging_kbranch == kbranch) Nov 09 20:20:43 devtool fills the variables like that: Nov 09 20:20:56 kernelVersion 5.4.61-rt37 Nov 09 20:20:57 staging_kerVer 5.4.61 Nov 09 20:20:57 staging_kbranch v5.4-rt Nov 09 20:20:57 kbranch master Nov 09 20:25:21 yeah, get_staging_kver() is b0rked :( Nov 09 20:25:39 to get the kernel version string you need more than just the Makefile Nov 09 20:27:40 but i don't see why kbranch is master Nov 09 20:27:42 another riddle Nov 09 20:37:20 all this breakage comes from: 015c87d95292 ("devtool/standard.py: Update devtool modify to copy source from work-shared if its already downloaded") Nov 09 20:43:33 hm, there is more Nov 09 20:44:20 Simple question, in a layer where I have an image, can I have a conf/machine/.bbappend where I can override variables without changing the machine name? Nov 09 20:44:45 (3rd party vendor has obnoxious dependencies on machine name, and I'd rather not just edit their file, but that's what they suggest) Nov 09 21:10:29 Shikadi: I'm pretty sure bbappends won't work for the machine conf files. They get included due to meta/conf/bitbake.conf. But you could make another conf file and include it via local.conf, or another configuration file, here is one of the times an example was given on the list. https://www.yoctoproject.org/pipermail/yocto/2017-October/038432.html Nov 09 21:12:46 Thanks, I'll give that a try... Nov 09 21:20:20 rewitt: Awesome, that worked perfectly, thanks! Nov 09 21:29:21 Shikadi: Great! :) Nov 09 21:44:55 bluelightning: morning! you around now? I am trying to write a tinfoil script that can get me a list PNs/recipes based on a given image. I see I can do it on a particular recipe or a world equiv. Nov 09 21:45:30 hi sgw Nov 09 21:45:56 it's a bit difficult to do it from tinfoil, your best bet is to base it on the image manifest (or buildhistory) Nov 09 21:46:21 since the full package dependencies aren't determined until packages are produced, and that influences what goes into the image Nov 09 21:50:25 I kind of dug into both of those and could not really find the hooks for the data I wanted. I have to refresh my memory, but I think buildhistory did not work well if it was rebuilding images from existing packages or sstate. image manifest, I don't exactly recall it's short comings. Nov 09 21:50:59 bluelightning: maybe there some hooks or details I missed. Nov 09 21:53:42 Hey all. I have a solution for this https://lists.yoctoproject.org/g/yocto/topic/74637733?p=Created,,,20,1,0,0 but i cannot find a way to reply to this thread. There is no mailto: link. Am i missing something obvious? Nov 09 21:54:29 ptsneves: if you don't get the mails to your inbox then login to the web site and you can press reply Nov 09 21:54:46 but a solution is very interesting :) Nov 09 21:58:10 i cannot find any reply button even though i am logged in. Each message only has the link button which goes to a page where the message is displayed. Also the more only shows "Show more messages from this user" Nov 09 21:58:47 well the solution is sudo ln -fs /usr/lib/python3.8/_sysconfigdata__x86_64-linux-gnu.py /usr/lib/python3.8/_sysconfigdata.py Nov 09 21:59:35 i guess ubuntu adds the arch by default as well as _sysconfigdata__linux_x86_64-linux-gnu.py but not _sysconfigdata Nov 09 22:00:02 i tried to reinstall python3 but it seems this is how upstream ubuntu "wants" things Nov 09 22:06:05 Pretty sure that's a workaround not a solution Nov 09 22:08:52 ah ok. in that sense. The mailing list had neither. Nov 09 22:10:55 worth replying to the thread still Nov 09 22:11:01 the problem is a little thorny Nov 09 22:12:26 sgw: buildhistory should definitely work from sstate, if it doesn't that is a bug we need to fix Nov 09 22:12:59 sgw: image manifest doesn't have recipes in it, but you can look those up via pkgdata Nov 09 22:13:55 yeah...i still cant. :( Nov 09 22:16:10 what is the correct mailinglist for devtool related stuff? Nov 09 22:17:21 bluelightning: let me dig back into it, if you have any good examples to share, they would be most welcome! I think there is a community need for something like this as we talked about before. Nov 09 22:23:04 Is there any plan to upgrade to binutils 2.35.1? I can submit a patch if it would in the interests of the community Nov 09 22:23:42 please do Nov 09 22:23:55 check with khem that he doesn't have a patch ready to be sent first Nov 09 22:24:35 4823 Nov 09 22:25:18 4839 Nov 09 22:25:32 damn wrong window Nov 09 22:26:35 I don't get the difference between SRCREV and SRCPV. Okay, with SRCREV I tell the fetcher which repo revision to fetch. And SRCPV is set by the fetcher based on the revision it fetched: `SRCPV = "${@bb.fetch2.get_srcrev(d)}"` So they're having the same value. Except... when? Nov 09 22:26:40 rburton: haha :) Nov 09 22:26:41 rburton at least it is not in the mailing list Nov 09 22:27:12 manuel1985: a version might be 5.6+git Nov 09 22:29:05 RP: But thats PV, isn't it? Nov 09 22:29:38 I know `PV = "1.0.5+git${SRCPV}"` e.g. Nov 09 22:30:17 manuel1985: ah, right, yes. SRCPV is the revision in a form which can be included there Nov 09 22:30:46 manuel1985: its so you can do things like set SRCREV=${AUTOREV} and still have PV be correct Nov 09 22:31:17 RP: Ah ok, I get it. Thanks! Nov 09 22:48:02 ptsneves: if you work on patches for binutils thats fine, I will wait for them Nov 09 23:10:33 hey guys, running into a small issue that i've tried to resolve on my own for a while now. Nothing crazy specific. I'm trying to write a recipe in which I create two groups, create two users, and then add those users to those groups. For some reason, only one of the groups is made Nov 09 23:10:58 useradd looks like: USERADD_PARAM_${PN} = "-u 1200 -d /home/nano -G i2c,gpio -m -p yFTYm1b18SPr6 nano; -u 1201 -d /home/pdu -G i2c,gpio -m -p JU1wTQ9mH04ns pdu" Nov 09 23:11:19 groupadd param looks like `GROUPADD_PARAM_${PN} = "-g 880 i2c; -g 890 gpio"` Nov 09 23:11:59 After build and flashing, only the group `i2c` is valid, with users successfully added. Any idea as to why the second gets skipped? Nov 09 23:12:44 did you look through meta-skeleton/recipes-skeleton/useradd/useradd-example.bb Nov 09 23:12:57 I did, and modeled this recipe after that recipe Nov 09 23:13:48 rburton: are these your debit card PIN number ? Nov 09 23:13:56 It shows two groups being added using that `groupadd_param` but they didn't show using the `-G` modifier on `useradd_param` Nov 09 23:14:24 I suppose I could split it into two recipes and try it like that before combining again **** ENDING LOGGING AT Tue Nov 10 00:42:46 2020 **** BEGIN LOGGING AT Tue Nov 10 00:48:44 2020 Nov 10 00:52:56 RP: I think libical is breaking due to icu update staged in master-next Nov 10 01:02:21 sent a patch, I think living on bleeding edge is depressing Nov 10 02:01:24

i suck dick **** ENDING LOGGING AT Tue Nov 10 02:59:56 2020