**** BEGIN LOGGING AT Thu Jan 21 02:59:57 2021 Jan 21 03:15:37 I've hit a defect in the do_unpack function that I thought I could workaround but now realize I can't. Jan 21 03:16:39 Anyone able to suggest where to look to alter the git clone statement that is used in that function? Jan 21 03:17:06 We need to add the option --origin origin Jan 21 03:17:49 Currently we assume everyone's clone command creates a remote named origin. Jan 21 03:18:39 That assumption isn't always true.  False cases break do_unpack Jan 21 04:09:22 Found it. working on a patch now. Jan 21 06:42:19 Hi guys, I was building using yocto-2.6.2 for machine qemux86 and that was working well, then I only changed the machine to qemuarm and the image I had has issues like: Jan 21 06:42:20 -  When shutting down, it gets stuck at "reboot: System halted" and never power off after that Jan 21 06:42:20 - anytime I try to ssh to it, I get "ssh_exchange_identification: read: Connection reset by peer" Jan 21 06:42:21 both issues weren't there when I had an image for qemux86, is there something else other than "MACHINE" was supposed to be changed or what could be a reason for that to happen? Jan 21 07:12:45 Hi! /msg NickServ identify danmer1904 Jan 21 08:19:30 is it expected behacvior if do_populate_lic isnt automatically set on the task dependencies unless specifically building a recipe?, or am I looking at a bug? Jan 21 08:19:51 e.g. it looks like do_populate_lic depends on do_build Jan 21 08:20:14 so if I build recipe X the task do_populate_lic for X is executed Jan 21 08:20:38 but if I build recipe Y which depends on X, the task do_populate_lic for X isnt executed Jan 21 08:30:00 I try to install the buildtool extended tarball and an extensible SDK with master from 2 weeks ago and the extensible SDK installation fails with the infamous ERROR: Task (virtual:native:/xxx/meta/recipes-devtools/pseudo/pseudo_git.bb:do_fetch) failed with exit code 'setscene whitelist' Jan 21 08:30:40 can someone please check if they can reproduce it? Jan 21 08:31:54 I use core-image-sato-sdk Jan 21 08:40:46 I am creating my own `kernel-recipes/linux/linux-mykernel`, using downstream kernel sources. In my machine BSP file, I set `PREFERRED_PROVIDER_virtual/kernel` to "linux-mykernel", so that it uses my custom kernel recipe. But in my recipe, I had to add `inherit kernel siteinfo` for it to find it (which I copied from the raspberrypi BSP). Jan 21 08:40:46 What does `inherit kernel siteinfo` do? Is it correct to include that in my custom kernel recipe? Jan 21 08:45:58 @jonesv[m]: inherit kernel: inherits this class: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/kernel.bbclass Jan 21 08:46:52 @jonesv[m]: inherit siteinfo: inherits this class: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/siteinfo.bbclass Jan 21 08:50:45 RobertBerger: While you're around, quick question: Which tool are you using to pull/manage your layers? kas? repo? Or did you come up with some own solution? Jan 21 08:50:47 @jonesv[m]: I don't explicitly inherit those classes, but I include/require meta/recipes-kernel/linux/linux-yocto.inc, which inherits kernel Jan 21 08:50:59 Aha! And this defines some do_ functions. Also it resolves my issue with the missing .config. Feels like it is fine to inherit from that when compiling from my own kernel sources, right? Or is that meant to be specific to the linux-yocto sources? Jan 21 08:51:36 Oh right. What would be the difference? Jan 21 08:52:09 @manuel__: My own solution, which is bash scripts + git: https://github.com/RobertBerger/manifests/blob/master/resy.sh Jan 21 08:54:05 @jonesv[m]: well bbclasses can define various things. linux-yocto.inc inherits a few more classes Jan 21 08:54:22 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto.inc#n44 Jan 21 08:54:25 RobertBerger: Thanks! Jan 21 08:55:48 @manuel__: I used repo before, but it did not fit my workflow. If you search for an "out of the box" solution, I guess kas is a a good option. Jan 21 09:02:05 RobertBerger: resy, i hoi di mitm... Jan 21 09:15:01 @LetoThe2nd: Oida ;) Genau oda Maresi Jan 21 09:15:20 RobertBerger: OIDA! Jan 21 10:04:55 paulg: i've only seen that when running the same py in both py2 and py3 Jan 21 11:28:11 the buildhistory installed-packages-sizes refers to the actual unpacked accumulated file size of the packages, right= Jan 21 11:32:29 Quick, likely stupid question; I'm trying to do multiconfig build, do the target_X.conf files inherit variables from local.conf? E.g DISTRO_FEATURES_append and IMAGE_INSTALL Jan 21 11:32:50 https://docs.yoctoproject.org/bitbake/1.46/bitbake-user-manual/bitbake-user-manual-intro.html#executing-a-multiple-configuration-build Jan 21 11:33:44 LetoThe2nd: you can check that by adding the size of them all and compare it to IMAGESIZE in the image-info file in the buildhustory IIRC Jan 21 11:33:50 the IMAGESIZE is before compression Jan 21 11:35:06 Sponge5: yep. mc build is basically local.conf + mc conf Jan 21 11:35:08 Sponge5: you cna always check with bitbake -e I guess. Otherwise, not sure it makes much sense? just add the distro feature to the distro conf file and the paclages you want to install in the image recipe? Jan 21 11:35:28 qschulz: meh. you know i'm bad at maths. Jan 21 11:37:07 Sponge5: what qschulz said. its better to just select the distros through mc and have separte distro.confs, otherwise you're mixing up functionlities and make it hard for others to understand. plus is essentially means that a specific target can only be build trough mc, and not freestanding. Jan 21 11:39:08 I see, so I should aim to have local.conf as clean as possible, since confs and recipes all inherit it Jan 21 11:42:44 Sponge5: that always applies, as local.conf is meant to be temporary Jan 21 11:43:20 qschulz: it doesn't sum up exactly by the way, but basically seems to be roughly correct (give or take a couple of kB) Jan 21 12:01:17 LetoThe2nd: probably because of added rounding "errors" Jan 21 12:03:01 qschulz: yeah, not worried about it. Jan 21 12:56:43 Hello everyone. I'm running into this error when I'm trying to run my build. Please how can I fix this? Jan 21 12:56:47 https://www.irccloud.com/pastebin/lypuVVoc/ Jan 21 13:08:14 @idadel: Looks like something nasty happens which causes a Sigabort ;) Jan 21 13:08:31 #idadel: You run this in a container? Jan 21 13:09:07 @idadel: If so, which version of poky? Jan 21 13:13:35 RobertBerger: I'm using poky contrib. Jan 21 13:14:55 @idadel: can you please try with poky? Jan 21 13:17:01 Okay. I will. Jan 21 14:47:52 Is git.yoctoproject.org down? Jan 21 14:48:35 frsc: yes, it is Jan 21 14:50:04 sakoman: hm, ok. That's bad. Jan 21 14:58:30 When doing `bitbake -c menuconfig virtual/kernel` I get a lot of errors like "menubox.c:(.text+0x8af): undefined reference to `wmove'". Jan 21 14:58:55 I installed libncurses5 and libncurses5-dev, but that didn't change anything. Jan 21 15:04:40 rburton, the poky dir *might* have had pyc files dating back to py2 era that laid there inert until today; I didn't check how old they were before deleting them... Jan 21 15:05:32 but I do know I built with that machine and same dir within the last month w/o issue, and it has been on 20.04 for many months before that. Jan 21 15:06:53 python went from 3.8.5 in ubu-20.04 to 3.8.6 in ubu-20.10, so that became my #1 suspect. Jan 21 15:09:12 Anyone here who is able to fix the server at git.yoctoproject.org? Jan 21 15:09:38 frsc: that would be halstead probably Jan 21 15:16:20 qschulz, I'm checking on that now. Jan 21 15:17:48 A nice morning gift! :D Jan 21 15:20:20 halstead: thanks and good morning :) Jan 21 15:22:40 qschulz, zeddii git is back to normal. We were overloaded by web requests. Jan 21 15:25:46 the botnet is using yocto! Jan 21 15:25:57 Ok, git.yoctoproject.org seems to be up again. Thanks for fixing! Jan 21 15:28:28 frsc: you can thank halstead. As quick as usual :) Jan 21 15:34:52 halstead: thank you :) Jan 21 15:36:14 image recipes are in the distro layer, but the .wks file in the machine layer, but it is applied on image formats Jan 21 15:36:23 how do you guys keep this orthogonal? Jan 21 15:37:13 Thanks for the notice. I need to change the load alert so I get automated notice sooner. Jan 21 15:37:51 v0n: the .wks should not have any hardcoded references to the particular image involved, so i don't see how it's not orthogonal. distro opts into use of wic via image fstypes, image defines what goes into the rootfs, machine defines the wks to use Jan 21 15:40:41 halstead: Or throw more resources at the server ;) Jan 21 15:40:46 halstead: Anyway, thanks! Jan 21 15:41:37 You're welcome. Jan 21 15:49:19 blarz: o/ Jan 21 15:54:51 kergoth: in my case I'm building an initramfs image, like most linux distros, that I need to mention in the u-boot conf. The name comes from the image recipe. Jan 21 15:55:34 kergoth: maybe the image recipe should deploy a symlink with a commonly defined name? (like initramfs.cpio or something) Jan 21 16:00:48 neverpanic: oh hai ;) Jan 21 16:01:49 v0n: make your image recipe create the u-boot conf file? Jan 21 16:02:20 isn't this even more weird? Jan 21 16:05:44 v0n: what is exactly your u-boot conf file? Jan 21 16:05:55 a defconfig or a u-boot script to embed in a fitimage? Jan 21 16:10:08 qschulz: I'm using IMAGE_BOOT_FILES += "custom-initramfs" and UBOOT_EXTLINUX_INITRD = "../custom-initramfs" Jan 21 16:10:22 should these variables go into the distro image recipe? Jan 21 16:20:57 RP: same failure running oe-selftest -r efibootpartition with and without -j1, but works correctly when bitbake core-image-sato:do_testimage. The failure is setting the qmp_port Jan 21 16:20:57 qemuparams += ' -S -qmp unix:%s,server,wait' % (qmp_port) Jan 21 16:20:57 TypeError: unsupported operand type(s) for +=: 'NoneType' and 'str' Jan 21 16:20:57 See pastebin: https://pastebin.com/qz3ehJVS Jan 21 16:24:03 When I do `bitbake -c do_menuconfig virtual/kernel`, the output looks rather shitty. Lots of ^@ where, I think, borders should be drawn. Anyone an idea? Jan 21 16:26:19 sgw: so qemuparams isn't set ? Jan 21 16:27:23 Hmm, I will hae to double check then, but why does it work with testimage. Jan 21 16:27:41 tgamblin: Is there a reason you want a kubevirt container over just running qemu in a container? Jan 21 16:29:13 JPEW: I did try running QEMU in a container, but I didn't like how much I was tweaking about the way the container ran, so I started looking for k8s-native VM resources, and moto-timo and I have been bashing our heads against it periodically as a result Jan 21 16:30:31 JPEW: I'm not too attached to any specific solution as long as I can automatically run meta-python ptests as part of the pipeline, but using KubeVirt (if possible) seems less obfuscated than building a container with QEMU to boot a test image Jan 21 17:12:21 <[Sno]> otavio_: is it ok when I do the patches for meta-freescale for gatesgarth first? my master branches are not really ready for testing :) Jan 21 17:12:43 <[Sno]> I would cherry-pick from gatesgarth and do master PR then ... Jan 21 17:13:15 <[Sno]> otavio_: once linux+fsql+qoriq is on 5.4.9x Jan 21 17:24:26 tgamblin: Hmm... it seems like it would be *less* confusing to use the qemu built by OE (which should be able to access /dev/kvm with kubevirt), to run the ptest Jan 21 17:25:30 JPEW: I am starting to feel that way too, after the roadblocks I've hit :P Jan 21 17:32:13 RP: JPEW: interesting I found the different between oe-selftest and testimage, they take very different paths to the qemurunner.start() code oe-selftests goes in via targetcontrol which defaults params=None, while testimage goes through the OEQemuTarget and starts with params=d.getVar(QEMUPARAMS). which is why qemuparams in qemurunner has different default values "" vs None. I guess I will have to add a simple sanity on qemurunner for" Jan 21 17:32:14 not qemuparams is None" Jan 21 17:37:43 sgw: huh Jan 21 18:13:45 INITRAMFS_FSTYPES is usually set in the machine conf, right? Jan 21 18:36:57 Hi, I was trying to add wireguard into my build. My build uses the 4.9 linux kernel as such I was trying to add the wireguard-module as well as wireguard-tools as I need the backport for my kernel version. However in my build it fails and says that I should not ask to install a package providing wireguard-module. I noticed that the wireguard-module Jan 21 18:36:58 recipe includes a EXCLUDE_FROM_WORLD = "1" Jan 21 18:36:58 , which reading the Yocto manuals says prevents this from being included. What would the optimal thing to do here ? Jan 21 18:55:45 kergoth: did you mean that IMAGE_FSTYPES += "wic" goes into the distro conf or the image recipe? Jan 21 19:42:58 In an image recipe, which variable references the image being built? Jan 21 19:43:26 (so that I can specify UBOOT_EXTLINUX_INITRD = "../") Jan 21 21:03:06 RP: hi, sorry to bother you again but I don't want to spread out bad examples Jan 21 21:03:28 about (R)PROVIDES Jan 21 21:03:54 iirc you wrote the variable reference list, so I trust that https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-PROVIDES Jan 21 21:05:22 ant__: I thought this was discussed on the docs list and JPEW sent a fix? I wonder if its failed to apply somehow? Jan 21 21:06:08 see https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-PROVIDES Jan 21 21:06:29 vs https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-ref-variables.html#term-PROVIDES Jan 21 21:07:48 I must have mised yout answer...can you pls in short confirm += is overkill and the var is not 'overloaded' ? Jan 21 21:10:13 i.e. in our kodi_18.bb I'd add Jan 21 21:10:16 PROVIDES = "virtual/kodi" Jan 21 21:10:16 RPROVIDES_${PN} = "virtual/kodi" Jan 21 21:10:48 being that 'kodi' is still provided Jan 21 21:11:25 you see, in that layer the confusion came because the recipe was kodi- Jan 21 21:11:31 err stb_kodi.bb Jan 21 21:11:42 so you see the need for virtual Jan 21 21:16:17 RP: non need, found thx Jan 21 21:16:18 https://lists.yoctoproject.org/g/docs/message/856 Jan 21 21:17:03 sounded strange... Jan 21 21:18:30 ant__: My argument was that += is probably safer to be used in general Jan 21 21:18:54 ant__: virtual/ never makes sense in runtime variables Jan 21 21:19:09 so I'd argue the above is wrong for that reason Jan 21 21:19:39 I am trying to clean out an offended recipe :) Jan 21 21:20:09 whit no-comments on the commits... Jan 21 21:21:28 imagine I see even PE used in it :/ Jan 21 21:22:17 ant__: PE still can be needed although its rare now, thankfully Jan 21 21:23:07 RP, ant__: The commit is in master AFAICT Jan 21 21:23:52 JPEW: so it didn't update? or did I missunderstand? (sorry, I'm a bit distracted atm) Jan 21 21:26:03 he, imagine there is a kodi recipe and a kodi.bbappend in the same layer/same dir ... Jan 21 21:26:35 (while koen keep meta-kodi with the 'original' .bb) Jan 21 21:26:55 ok, go ahead... Jan 21 21:49:46 What is the simplest image recipe to create an empty rootfs? Jan 21 21:51:59 RP: what's your take on bumping the qemu machines to something more modern than core 2 duo, e.g. skylake? The use case I have locally is that we have something that performs a lot better with avx2 instructions enabled, which is beneficial in test turnaround times. Jan 21 21:52:23 Hi. Just working on a couple of recipe's that have file conflicts with base packages and I am trying to figure out how to force override the conflict. In particular I am overwriting the /etc/network/interfaces file with a custom one within my recipe. How do I tell bitbake to that my package is ok to overwrite those files from the base package? Jan 21 21:52:59 kanavin_home: I'm probably ok with it if the autobuilders have the right cpu flags Jan 21 21:54:30 RP: thanks; I guess that means host requiremets for yocto would change substantially, e.g. haswell-era cpus would not work anymore when running qemu. I'll cook up a test patchset and try it on the AB before coming out with it to the oe-core list. Jan 21 21:54:47 RP: just wanted to check upfront if there's some reason you'd be strongly opposed :) Jan 21 21:57:47 kanavin_home: I don't remember the reasoning for core2duo but it was a long time ago. I do want YP to work out the box without too many issues so it really depends how long ago haswell was out etc Jan 21 21:58:06 kanavin_home: I don't know what the "average" cpu is atm Jan 21 21:59:17 RP: skylake is almost 6 years old at this point, and is the last substantial update that came out from intel Jan 21 21:59:55 since then I think it's largely been repackaging slightly refined versions, which is why they find themselves in hot waters lately Jan 21 22:06:09 RP: I worked out my latest issue with QMP. What's a good smaller set of tests from oe-selftest to run to qmp with? Jan 21 22:07:26 sgw: I really don't remember which ones call runqemu and which don't, I'd have to look Jan 21 22:07:40 kanavin_home: we do have older autobuilders :/ Jan 21 22:07:44 RP: Ok I will take a look through them Jan 21 22:07:47 kanavin_home: we can try it, see how it looks Jan 21 22:07:59 sgw: sorry, I wouldn't know offhand Jan 21 22:08:19 No worries, thought you might. Jan 21 22:21:08 Does EXTRA_IMAGE_FEATURES affect an image recipe defined in DEPENDS? Jan 21 22:45:26 RP: It doesn't appear to have updated Jan 21 23:07:18 vmeson: I remembered what I was going to ask about. Did you see the mail "adwaita-icon-theme: add version 3.34.3 back" Jan 21 23:27:26 RP, ant__: Weird: https://docs.yoctoproject.org/ref-manual/ref-variables.html#term-PROVIDES is incorrect, https://docs.yoctoproject.org/ref-manual/variables.html#term-PROVIDES is correct Jan 21 23:30:31 RP, ndec: Ah, I see. The docs are updating correctly, ndec renamed ref-variables.rst -> variables.rst, and the old generated page stuck around. I'm guessing ant__ has an old bookmark. Should probably delete (or redirect?) the old pages Jan 21 23:30:46 heh Jan 21 23:30:48 halstead: ^^^ any tips? Jan 21 23:31:18 * JPEW eats supper Jan 21 23:31:30 RP: I see why the virtual... Jan 21 23:31:31 ERROR: Nothing RPROVIDES 'virtual/kodi' (but /oe/openpli-oe-core/meta-openpli/recipes-openpli/enigma2-plugins/enigma2-plugin-extensions-kodi.bb RDEPENDS on or otherwise requires it) Jan 21 23:31:46 sigh... a series of small issues... Jan 21 23:32:15 RP, JPEW I can remove the retired page and add a redirect. Jan 21 23:32:19 I think they added the provider to catch the renaming Jan 21 23:32:34 halstead: I suspect there were a lot of renames dropping the prefixes Jan 21 23:33:06 ant__: nothing should be RDEPENDS on that Jan 21 23:33:14 JPEW, as usual google and caches Jan 21 23:33:26 RP: right, I'm fixing it backwards Jan 21 23:34:16 but this will be a series of commits, for the mom I must spare that RPROVIDES -> virtual Jan 21 23:34:43 ah, RP, are you aware of CMake issues with mips? Jan 21 23:35:07 strangely I had to ad -latomic -lpthread to compile that kodi Jan 21 23:35:28 shouln't the class inject this? Jan 21 23:35:37 ant__: I try not to think about cmake if I can help it ;-) Jan 21 23:35:55 eh eh, I am the same but the beast is in front of me Jan 21 23:36:16 ant__: I don't know I'm afraid. I'm not aware of any Jan 21 23:36:26 add a C++ coprocessor (libfmt) ...and I am stuck to ol' C Jan 21 23:36:38 I'll bug khem oneday Jan 21 23:36:40 thx **** ENDING LOGGING AT Fri Jan 22 02:59:58 2021