**** BEGIN LOGGING AT Thu Nov 19 02:59:59 2020 Nov 19 03:48:03 all is there a way to remove target-sdk-provides-dummy from sdk build ? I am facing errors while generating sdk using "bitbake -c populate_sdk Nov 19 08:49:48 kiwi_29: deb is a bit more fragile, unless you have a hard need for it we recommend rpm or opkg Nov 19 08:54:13 yo dudX Nov 19 08:54:22 * qschulz waves Nov 19 09:02:59 * LetoThe2nd "waves" back to qschulz https://youtu.be/CWzDXZPyAcQ Nov 19 09:22:31 good morning Nov 19 09:32:03 paulbarker: qschulz: you have both been nikhibaited again. Nov 19 09:45:56 LetoThe2nd: I know, does not mean I can't answer :) Nov 19 09:46:35 qschulz: obviously you're a better/braver man than me. Nov 19 09:46:48 I mean, this time the error was pretty obvious to me Nov 19 09:47:07 LetoThe2nd: there's no need for a ranking system :) Nov 19 09:47:18 really? i skimmed it and was like, is there a single line thats not obviously wrong. Nov 19 09:47:50 LetoThe2nd: let's say, two lines were the obvious mistake, the rest was not harming except cluttering the code? Nov 19 09:48:34 thats a pretty euphemistiv but probably acceptable interpretation. Nov 19 09:55:13 hello, what is the correct way to prepopulate the /dev directory with a console node for kernel's built-in initramfs in yocto? Nov 19 09:55:59 I've already taken a look at meta-initramfs, but the examples there do it at runtime Nov 19 09:57:36 Ideally I'd just like to drop a gen_init_cpio configuration file into the metadata, set a variable understood in poky and be done with it Nov 19 09:57:58 but I have doubts whether that is supported Nov 19 10:03:20 ndec: what's the issue with labels we actually use? (I can understand removing those which aren't used) Nov 19 10:03:42 qschulz: consistency? Nov 19 10:03:57 ndec: touché Nov 19 10:04:36 and since we use the section name. that means that modiyfing the section name (for any reason) will force a developer to think twice about the change.. Nov 19 10:04:54 ndec: can't remember right now but how does bitbake labels work when referenced from YP docs? Nov 19 10:04:59 (and vice versa) Nov 19 10:05:12 *(just to be sure we don't break other docs) Nov 19 10:05:15 well, vice versa does not work :) Nov 19 10:05:26 it's only YP which can refer to bitbake docs Nov 19 10:05:34 true, makes no sense for bitbake to reference YP docs :p Nov 19 10:05:49 and it works the same for labels and 'sections' Nov 19 10:06:07 e.g. :ref:`bitbake:xxx` and xxx can be a label or a section refernce Nov 19 10:07:01 if you run python -msphinx.ext.intersphinx /html/objects.inv, you will get a list of all 'references' which are exposed Nov 19 10:07:45 i haven't checked yet, if yocto-docs uses labels from bitbake-docs, we should remove the labels from bitbake as well! Nov 19 10:08:14 yeah I know for YP docs, in that case labels can be used with :ref:`label` whereas sections are always :ref:`subdir/doc:section` (or :ref:`section` if in same file?) Nov 19 10:09:11 so I'd imagine bitbake refs work the same way from YP docs perspective but I'm probably missing on something and I don't know where I'm going with this :p Nov 19 10:13:01 qschulz: we always need the subdir.. even for refs in the same file. that is something i don't like much.. but it's how it works. Nov 19 10:14:39 one other change i have in mind is to reduce the filename length.. too much duplication right now. e.g. "kernel-dev/kernel-dev-common.rst" should be kernel-dev/common.rst", at the very least. Nov 19 10:14:52 that's another magic sed for later.. Nov 19 10:15:16 :) Nov 19 10:15:30 never ending list of improvements to make :) Nov 19 10:16:01 well, that's not a bad thing at all actually! Nov 19 10:16:15 what would we do, if we were just done. Nov 19 10:16:49 indeed :) Nov 19 10:18:43 ndec: just like the kernel devs. i mean, they were basically done by 2.6.32, but they still just pretended the kernel needs more work and carried on like before :) Nov 19 10:19:04 exactly! Nov 19 11:23:20 LetoThe2nd: I don't want to hear you saying "I told you" Nov 19 11:25:02 qschulz: no worries. i'll not say it, but jsut type "I told you" Nov 19 11:25:40 qschulz: I told you. Nov 19 12:00:52 hi everyone. I am running Yocto 2.5, and have a working image recipe which includes libgdiplus. Now a collegue of mine required the 32-bit version, so I added lib32-libgdiplus to my image recipe. Now I'm getting some strange build errors saying that "The postinstall intercept hook 'update_gio_module_cache' failed," followed by " do_rootfs: The following packages could not be configured offline and rootfs Nov 19 12:00:58 is read-only: ['101-libglib-2.0-0', '102-glib-networking', '100-lib32-libglib-2.0-0']". Nov 19 12:03:34 Any ideas if this can be resolved resorting to a read/write roootfs? Nov 19 12:03:41 *without Nov 19 12:03:47 iceaway: possibly :) Nov 19 12:05:49 I have been playing around with the associated postinst scripts etc, and found a bugfix in the update_gio_module_cache which I merged to my code, but that did not really help unfortunately. Nov 19 12:07:04 iceaway: its very well possible that a) this is an issue nobody else ran into so far b) it is fixed on current master c) it doesn't play nice with RO-rootfs. even combinations thereof. Nov 19 12:09:59 The error output from the build log is actually: "/home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: 15: Nov 19 12:10:03 /home/pelle/development/var-fsl-yocto/build_kodkod/tmp/work/imx8qxpb0_var_som-poky-linux/tmlinux-image/1.0-r0/intercept_scripts-bd1c31820bf736a004f4ebe71461d6fa3ae23f7d97783c8f28a606e086741d8a/update_gio_module_cache-lib32: lib32-qemuwrapper: not found" Nov 19 12:10:25 Since it is working fine with the 64-bit build, I'm a bit confused. Nov 19 12:10:39 iceaway: that might be a dependency problem Nov 19 12:13:21 I have bee scratching my head all day about what the root cause of this could be. I'm not sure if this is a dependency for glib-2.0, or for my image. Nov 19 12:14:26 I can build "lib32-qemuwrapper-cross" by adding that to the DEPENDS of my image, but the glib-2 recipe seem to look for "lib32-qemuwrapper", which it cannot find. Nov 19 12:14:59 i'd guess it needs lb32-qemuwrapper-native - but its really all guess work. Nov 19 12:15:10 those are pathes seldom travelled here. Nov 19 12:21:16 Alright, thanks LetoThe2nd. I'll report back if I come up with anything useful that might help others. Nov 19 12:22:03 iceaway: yes, please do so. itmight also be useful to put a message on the ML just outlining your situation Nov 19 13:37:45 iceaway: IIRC the GIO stuff executes some code in QEMU as part of the build. My guess is that there is something wrong with the QEMU part of it Nov 19 14:21:52 * hmw1 sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/pWcyykbStOvdYHxMTjfiLraH/message.txt > Nov 19 15:06:11 qschulz: there's more chances to be properly nikhilized today! Nov 19 15:17:38 I know it's a beaten horse, but any quick tips on potentially speeding up image creation? Making minor changes to my recipes, but do_rootfs and do_image are always a "set it and forget it" stage of my build process. Nov 19 15:21:16 bsmerbeck: just don't create images :) Nov 19 15:21:33 bsmerbeck: nach, seriously: have suffient fast storage. Nov 19 15:26:25 LetoThe2nd: Figured that might be the answer. I'm running on a PowerEdge R730, 6Gbps SATAs, gave the VM about 20 gigs of ram, and it has a xeon e5 Nov 19 15:27:02 VM? Nov 19 15:27:24 so you're on a linux thats virtualized onto a windows box, or such? Nov 19 15:28:29 Yeah, yocto/bitbake are running on a centos VM I hosted on a newer server Nov 19 15:28:53 then get rid of the vm, thats the main bummer. Nov 19 15:29:17 I was thinking that, given I've gone through the rounds of optimizing the parallel jobs and what not Nov 19 15:29:57 Maybe i'll compare my current machine's spec to this server and see how big a difference there is now Nov 19 15:30:05 getting out of a vm is always step #1 of n, not step #n of n Nov 19 15:31:28 I've found work constraints tend to mix up the order of those steps, haha Nov 19 15:31:57 In any case, a project for another day. Thanks for the input! Nov 19 15:32:10 i guess for the wasted time in waiting for the builds you could have totally rearranged your constraints already :) but yeah, have fun1 Nov 19 15:58:45 JPEW: I was looking at whisk some time ago, and I know there was some example repository where you used it (I think it had doom for rpi or something like that), but now I can't find it again. Do you know where I can find it? Nov 19 16:10:34 zeddii: I'll try to kick the tires on k3s today... assuming you are still seeing issues ? Nov 19 16:11:21 yep. I've broken it down to a simple first step now. Get the main node (server) to stop having the 4 required containers go into a crashbackoffloop Nov 19 16:11:38 and b) how have we misconfigured it such that kubectl get logs doesn't work. Nov 19 16:12:00 make sure to use my k3s-wip branch though, that has everything you need to get to where I am. Nov 19 16:12:21 Saur: https://github.com/JPEWdev/yocto-doom-demo Nov 19 16:14:18 zeddii: I've seen a number of ways to get crashbackoffloop, so maybe one of my tricks will help... plus I've stumbled on some random incantations that achieve some logs Nov 19 16:14:48 JPEW: Thank you. :) Nov 19 16:14:50 zeddii: BTW, I LOVE the cni new bbclass idea Nov 19 16:15:25 zeddii: since I am now exclusively using cri-o and cni bridge networking in my current sandbox Nov 19 16:15:41 it still needs work, but I wanted the concept out. Looking at k8s and k3s and others, it was clear they were all just thrashing stuff into the directory blindly. Nov 19 16:16:05 zeddii: like everything else in cloud native world Nov 19 16:16:21 yup. flail with your slight variant! Nov 19 16:17:50 zeddii: we'll need to not assume docker in packagegroup-k8s-host, but you already knew that Nov 19 16:18:19 yep, it isn't required. I was actually just breaking that out more yesterday. while testing. Nov 19 16:19:02 some of the strings I was tugging on yesterday involved 'docker ps' and they failed, but at the same time, I realized the granularity needed to be better. Nov 19 16:26:27 Saur: FYI, if you poke around in that repo; it builds, but it doesn't actually do the advertised behavior of running Doom on the devices.... WIP :) Nov 19 16:38:09 JPEW: mark jonas has that already... https://gitlab.com/toertel/meta-doom Nov 19 16:38:55 JPEW: No problem. I was looking for a real example using whisk. ;) Nov 19 16:39:07 JPEW: he asked me about some small hint concerning dependencies during ELC-ALMOST-EU, and i still haven't responded... shame on me. Nov 19 16:45:02 LetoThe2nd: That's cool. I'm more interested in using doom as a cool end demo for other interestings things.... mainly, I want to demo a CI setup with kubernetes+tekton that then runs tests on my devices Nov 19 16:45:20 As an interesting demo, the "test" can be running doom :) Nov 19 16:55:07 armpit: I updated 12850... or was I supposed to go to the wiki? Nov 19 16:59:34 on an unrelated note, the netflix documentary thing on video games, had an interesting segment on doom and Romero/Carmack. so watch that first :D Nov 19 17:03:33 zeddii: I'm working on recipes for cri-tools (crictl), tektoncd-cli (tkn) and k9s, but you know how fun Go is Nov 19 17:04:07 yes, enjoy jiggling the components into the right place so go admits they are what is needed. Nov 19 17:05:04 I wasn't getting to any of those any time soon, so I'll plug away on refreshing k8s (and others) and fighting with k3s. Nov 19 17:25:17 zeddii: building k3s now ;) Nov 19 17:26:09 I primarily think it is something missing in my packagegroups, but I can't get the right log to see what it is. Nov 19 17:26:39 On an older k3s version, I had them start once last week, but haven't repeated that success yet. Nov 19 17:43:20 zeddii: I think I noticed some changes in behavior from k8s 1.18 to 1.19... hopefully something will jog my memory Nov 19 17:46:09 moto-timo, defect is fine. I will add it to wiki once the new section is written Nov 19 18:55:27 zeddii: dear lazyweb, nothing provides kernel-module-ip-set needed by ipset-6.38-r0.qemux86_64 ?? Nov 19 18:56:45 there's a fragment that turns it on. Nov 19 18:57:05 but if you know you have it on (i.e. built-in), you can hack that recipe to drop the rdepends. Nov 19 18:57:14 I've kept it around as a canary in the mineshaft Nov 19 19:04:02 zeddii: thank you. I'm not exactly paying attention because KubeCon+CloudNativeCon... Nov 19 19:07:39 LetoThe2nd: no comment, or please keep private :) Nov 19 19:14:28 anyone seen pseudo abort happening when running bitbake -c populate_sdk ? Nov 19 19:15:17 (with master of early nov... there don't seem to have been any fixes since then relating to it) Nov 19 19:28:21 I've not seen any recent pseudo fixes.. but RP would know for sure Nov 19 19:56:40 qschulz: :) Nov 19 20:02:56 zeddii: ha, crictl is already being built... I missed that Nov 19 20:03:37 zeddii: do I want packagegroup-k3s-host and packagegroup-k3s-node on the single node? Nov 19 20:11:14 when did I get so lazy Nov 19 20:11:18 sigh Nov 19 20:11:30 #2020 Nov 19 20:42:56 sorry, was in a meeting. Nov 19 20:43:17 moto-timo: they were designed to both be present to do a single node setup. which I haven't gotten working yet. Nov 19 20:43:44 I fell back to just trying to get the bloody controller to be more than "ready" .. have actual working containers. Nov 19 20:47:40 Building NodeJS for x86_64 SDK. got "fatal error: unicode/uchar.h: No such file or directory". Do I have to install ICU on my host system or add build requirement to NodeJS recipe? Nov 19 21:16:54 Any support for sstate_mirror over https/sftp/ssh with auth? Nov 19 21:22:02 if ssh is an option for you, just do the auth using that and forward a port over it? Nov 19 21:22:42 put an nginx reverse proxy in front of it? Nov 19 21:25:10 The reverse proxy idea came up. That is on the docket. The port forward over ssh I have not thought of.. hmm.. Nov 19 22:00:03 dv|2: seems so it perhaps needs some patching to work with with icu 68 if you are on master Nov 19 22:00:39 I am on dumfell Nov 19 23:05:41 bluelightning: we've fixed the known issues, its possible there are others Nov 19 23:14:55 patches welcome :) Nov 19 23:15:55 zeddii: so far, it seems like cni networking isn't live, but I have not been too deep yet Nov 19 23:16:31 zeddii: I had to get it "ready" first (yeah, use the correct virtual/foo) Nov 20 01:21:17 zeddii: for me at least, network devices are in an endless loop of crashing and restarting... do we have enough memory? Nov 20 01:22:37 zeddii: Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth15cd4fcc: Link UP Nov 20 01:22:39 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth15cd4fcc: Gained carrier Nov 20 01:22:41 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth14ee276b: Link DOWN Nov 20 01:22:43 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth14ee276b: Lost carrier Nov 20 01:22:46 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: rtnl: received neighbor for link '2129' we don't know about, ignoring. Nov 20 01:22:47 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth4cdd14ca: Link DOWN Nov 20 01:22:49 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: veth4cdd14ca: Lost carrier Nov 20 01:22:52 Nov 19 22:24:33 qemux86-64 systemd-networkd[176]: rtnl: received neighbor for link '2130' we don't know about, ignoring. Nov 20 01:22:53 Nov 19 22:24:34 qemux86-64 systemd-networkd[176]: veth15cd4fcc: Gained IPv6LL Nov 20 01:23:23 master, linux-yocto-dev Nov 20 01:30:08 moto-timo: in the README (not sure if it's checked into the branch) I suggest adding space to the image and booting with at least 2G of memory for qemu, or yes, you'll OOM Nov 20 01:31:00 zeddii: I did the 2G, so probably red herring Nov 20 01:31:28 zeddii: trying to troubleshoot why systemd-networkd is thrashing Nov 20 01:31:47 my "steady state" for networking and flannel looks like this: https://pastebin.com/ma5agnA7 Nov 20 01:31:49 up.down.up.down Nov 20 01:33:11 when I launch on the server on the command line, so I can actually see some logs .. you see it complaining about too many dns servers in resolve.conf (apparently that's not really an error, even though it displays as one), and lots of "can't connect". Before my containers went into the crashbackoffloop, I was seeing something that led me to think ssl or certifcates were wrong. Nov 20 01:34:15 I'm testing to see if mine really are sure they want to crash ;) Nov 20 01:34:16 helm-install-traefik-sms68 0/1 CrashLoopBackOff 344 29h Nov 20 01:34:22 29 hours of crash looping! :D Nov 20 02:58:52 Hello, which package provides ldconfig to target distro? is it ldconfig-native? Nov 20 02:59:24 while executing dpkg, I get ldconfig error and I see that there is no ldconfig in my core-image-minimal based distro . You would assume ldconfig is always installed ...no? **** ENDING LOGGING AT Fri Nov 20 02:59:57 2020