**** BEGIN LOGGING AT Wed Mar 03 03:00:25 2021 Mar 03 03:20:37 is this thing on? Mar 03 03:20:49 * yates wonders if anyone can hear him Mar 03 03:55:28 sure is quiet in here. Haven't heard anyone for hours. Mar 03 07:45:24 good morning Mar 03 08:11:05 hello guys Mar 03 08:12:28 I've modified some code of a device driver inside the kernel. There is a way to force a "whole compilation" of the kernel without refetching the original source code so that the modifications won't be lost ? Mar 03 08:23:04 sigh, SoC vendors and their BSP layers... Mar 03 08:34:31 hi guys ,quick question, how do i make sure that kernel modules were successfully built Mar 03 08:34:41 * dwagenk sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/NvqEMHYVVtWefvLWUFXfnIqN/message.txt > Mar 03 08:35:06 i mean it really hard to flash image on board and run the board everytime Mar 03 08:39:50 yo dudX Mar 03 08:45:33 yates: linux-yocto-dev is what we use to keep up with mainline latest development kernels. And yes, we do have native and cross compilers of various kinds Mar 03 08:51:17 RP: kinds: working ones, and not working ones :) Mar 03 09:04:19 how should I fix requirements for BSP SW deliveries with yocto. Require compatibility with latest LTS? Require following https://www.yoctoproject.org/docs/3.1/bsp-guide/bsp-guide.html ? Require that none of the features and bbclasses in poky are broken or modified? I know the reqs will be violated but at least then I have the stick... Mar 03 09:19:27 mcfrisk: this is what we tried to design YP Compatible to try and help Mar 03 09:27:43 Hello. How to find with bitbake command what layer a recipe belongs? Mar 03 09:27:46 RP: will yocto-check-layer help validate that poky features and bbclasses are not modified by the layers? I wonder if I should put that into requirements too. Mar 03 09:32:59 nacknick: bitbake-layers show-layers or something close Mar 03 09:36:09 LetoThe2nd: show recipes worked. thanks Mar 03 09:52:26 mcfrisk: it verifies the signatures don't change adding/removing the layer Mar 03 09:52:50 mcfrisk: that in theory should mean you can at least configure anything they modify Mar 03 09:53:17 mcfrisk: obviously nothing is perfect but it should go a long way to that Mar 03 09:53:30 hello everyone Mar 03 09:53:47 hey RP, I don't need anything, just wanted to thank you for the amazing work :) Mar 03 09:58:22 zyga: Hi, thanks! Its a team effort :) Mar 03 09:59:14 RP, yeah, just being a maintainer one rearely hears positive things, usually it's the silence or "hey it is broken" Mar 03 09:59:53 zyga: You're right, its not often you hear that, thanks :) Mar 03 10:09:38 RP: huh? it is not broken? Mar 03 10:14:01 LetoThe2nd: depends whether I read my email :) Mar 03 10:18:33 so, don't read your email, all is well! Mar 03 10:23:21 yates: linux-yocto-dev is where bruce stages the new kernel releases Mar 03 10:33:18 @LetoThe2nd: Oida! It's usually the hardware. Software is never broken. Mar 03 10:36:14 RP abelloni : my oe-selftest failed with wic errors about y2k, is that known? Mar 03 10:37:35 RobertBerger: hrhrhr. OIDA! Mar 03 10:50:21 rburton: was fixed... Mar 03 10:51:06 rburton: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=a334cbb12d405621e38b1bce011ec45a311b9baa but should have fixed references there too Mar 03 10:53:42 rburton: its not the warning causing the issue, I'm guessing the dosfs patch for wic was missing (but was later added to master by me yesterday) Mar 03 10:54:02 rburton: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=d53dddd7ca22c68f0b8ae010c38b330aa7a4bc15? Mar 03 11:06:48 ouch, FOO_class-target += "bar" overwrites whole FOO to "bar", must use FOO_append_class-target += "bar" to get the desired append for target class. didn't see that coming.. Mar 03 11:11:22 ouch^2, now also all perl files get "owned by uid 1005, which is the same as the user running bitbake". I guess time to wipe tmp and hope for the best. baking is fun :) Mar 03 11:16:29 jeez, wiping tmp didn't help. do I have a corrupted sstate cache? "ERROR: binutils-2.34-r0 do_package_qa: QA Issue: binutils: /usr/lib/libbfd-2.34.0.20200220.so is owned by uid 1005, which is the same as the user running bitbake. This may be due to host contamination" Mar 03 11:16:42 mcfrisk: wipe more! wipe more! Mar 03 11:18:14 mcfrisk: https://youtu.be/9QP4a03oFbQ Mar 03 11:18:24 is this pseudo being out of sync with build processes? I'm playing with a patch to libblkid in util-linux which did trigger recompilation of util-linux-native etc. hmm. I kind of want to understand but not sure if I dare to.. Mar 03 11:27:13 hmm, I had tried to build a BSP layer update with that sstate cache, maybe that was it. I can't see how my util-linux patches could have broken and contaminated sstate this badly. Mar 03 11:47:09 mcfrisk: that util-linux patch did odd things to my local build. Its on hold until I figure out what happened as it was very very odd Mar 03 11:47:12 RP: cool thanks Mar 03 12:13:13 RP: I've noticed interesting issue which I'm not sure is worth supporting, when you upgrade host distro (e.g. ubuntu 20.10 to 21.04) you need to clean pseudo-native for incremental build, otherwise there is a conflict in sysroot https://paste.ubuntu.com/p/F6xzCCBnZy/ Mar 03 12:26:08 Hmm, what a horrible dependency chain: "build-appliance-image.do_configure" -> "make-mod-scripts.do_compile" -> "linux-yocto.do_compile_kernelmodules" -> "linux-yocto.do_shared_workdir" Mar 03 12:26:39 JaMa: that sounds like a bug, that shouldn't happen :( Mar 03 12:34:48 JaMa: that sounds very like the problem where something is wrong with the sstate management code seen with util-linux too Mar 03 12:35:00 I think it's effect of "uninative: Don't use single sstate for pseudo-native" because it doesn't remove the old ${BUILD_ARCH}_${ORIGNATIVELSBSTRING} before building the new one, but on the other hand I don't remember similar issues before using uninative (where it would affect all native recipes) Mar 03 12:36:18 JaMa: what should happen is it should remove all "stale" things from the sysroot before installing new ones Mar 03 12:36:45 JaMa: do you have the task logs for that failure? Mar 03 12:36:57 yes it might not be specific to pseudo-native, I've seen weird native pseudo also from nodejs-native, autoconf-native and earlier pseudo-native as well (which prompted my sstatesig.py change to report error when manifest isn't found) Mar 03 12:38:13 but I've tried various ways how to reproduce it (upgrade/downgrade,arch-change and various combinations of this), but nothing caused that failure I'm randomly seeing from jenkins builds Mar 03 12:39:20 yes I have task log Mar 03 12:40:06 JaMa: I'm curious if anything in the earlier tasks saw that netry in the sysroot as stale Mar 03 12:41:43 would this show an warning in cooker log or only in individual log.do_prepare_sysroot or similar? Mar 03 12:42:08 I have backup of whole TMPDIR before restarting the build from scratch Mar 03 12:42:10 JaMa: wouldn't show as a warning, would just be a message in one of the individual logs Mar 03 12:42:32 JaMa: maybe in the one that failed, maybe in one of the earlier tasks Mar 03 12:46:14 there is surprising (for me) number of "exists in sysroot, but is stale" in the log.do_prepare_recipe_sysroot logs including about pseudo-native Mar 03 12:47:36 JaMa: does it then go on to remove it? Mar 03 12:47:42 It should... Mar 03 12:54:16 you mean in pseudo-native logs? should it be removed there? I see quilt-native stale and removed in log.do_patch and then attr,autoconf,automake,gettext-minimal,gnu-config,libtool,m4-native,pkgconfig,quilt,sqlite3,texinfo-dummy -native in log.do_prepare_recipe_sysroot, but nothing about stale pseudo-native Mar 03 12:56:15 log.do_populate_sysroot on the other hand shows removing the old pseudo-native in earlier task, but in current it doesn't Mar 03 12:57:00 previous pseudo-native rebuild https://paste.ubuntu.com/p/DXtBKRjK2d/ the last one which failed https://paste.ubuntu.com/p/3rM6GJCJ86/ Mar 03 12:57:44 that's why I was assuming it didn't find the "old" pseudo-native in sysroot, because the ORIGNATIVELSBSTRING in the manifest path changed due to ubuntu upgrade Mar 03 13:01:21 SSTATE_PKGARCH in pseudo-native is now x86_64_ubuntu-21.04, while the pseudo-native in sysroot has x86_64_ubuntu-20.10 and sstate_clean() didn't find this old one Mar 03 13:06:21 RP: I don't think we talk about the same util-linux patch, mine reduces the file system autodetection support in libblkid to ext4, nice one for faster mount times on target. am on dunfell, wiped sstate now builds are fine again. also using the worst BSP ever so not sure what is causing this. trying to run poky/scripts/yocto-check-layer now for all layers.. Mar 03 13:12:13 Is anyone on ZFS (like me)? I'm wondering how people workaround the size issue on hosts with compression-enabled zfs. Mar 03 13:23:09 khem: there is a typo here https://lists.openembedded.org/g/openembedded-devel/topic/meta_python_patch_2_2/81029710?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,20,81029710 Mar 03 13:23:23 I'll fix in a v2. Don't merge it from master-next to master yet. Mar 03 13:23:36 All also add the packages in the pkggroup Mar 03 13:33:44 I've combined them all in one series: https://lists.openembedded.org/g/openembedded-devel/message/89832 Mar 03 13:42:25 mcfrisk: we are talking about different util-linux patches then, yes Mar 03 13:43:25 RP, rburton: thank you for clarifying. Mar 03 13:44:41 RP: regarding the tools, i know yocto can provide both native- and cross-tools; my question was, how does it generate them? can you point me to an example layer/recipe? Mar 03 13:45:07 JaMa: I'd have expected it to have removed it there. There is a definite bug :/ Mar 03 13:53:53 gah, ltp broke reproducibility on the second run :( Mar 03 13:58:39 what does the "e" mean in "eSDK"? Mar 03 13:59:08 extraordinary! Mar 03 13:59:25 enemic? Mar 03 13:59:39 energized Mar 03 14:00:08 ..but seriously, folks Mar 03 14:00:30 there is an "SDK" and also an "eSDK"; what's the difference? Mar 03 14:01:04 tongues held by cats? Mar 03 14:01:30 extensible Mar 03 14:01:36 the other is non-extensible Mar 03 14:01:40 yates: well.. RTFM suggests it means "extensible" :) Mar 03 14:01:47 and the e means it ships a bitbake environment Mar 03 14:02:12 in terms of, the SDK just being nailed down to the image, and the eSDK being a kind of pre-canned build that you can extend. Mar 03 14:02:17 RP: but how would it be able to find the ORIGNATIVELSBSTRING value from previous build? It doesn't use any wildcards when searching previous one to remove, is this use-case worth having another exception for pseudo-native handling? Mar 03 14:02:52 hopefully people don't change host distro very often between incremental builds Mar 03 14:03:28 LetoThe2nd: which one of the, like, 15 manuals should i look in? Mar 03 14:03:34 ;) Mar 03 14:03:48 yocto needs to document its documentation... Mar 03 14:04:02 hey qschulz we need you here! Mar 03 14:04:03 google? Mar 03 14:04:56 yates: i mean... actually googling "yocto esdk" gives me https://wiki.yoctoproject.org/wiki/Extensible_SDK as first hit Mar 03 14:05:12 yates: so the gentle nudge is well earned :) Mar 03 14:06:08 what happens if google goes under? Mar 03 14:06:21 ... ha ha Mar 03 14:06:44 yates: no worries, people will find other lame excuses to just dump stuff in IRC. i'm not worried about big g going amiss. Mar 03 14:06:57 ;-) Mar 03 14:07:39 | LD .tmp_vmlinux.kallsyms1 Mar 03 14:07:39 | arm-tdx-linux-gnueabi-ld.bfd: drivers/input/misc/dold-wheel.o: in function `dold_wheel_probe': Mar 03 14:07:40 | dold-wheel.c:(.text.unlikely+0x1e0): undefined reference to `devm_input_allocate_polled_device' Mar 03 14:07:40 | arm-tdx-linux-gnueabi-ld.bfd: dold-wheel.c:(.text.unlikely+0x300): undefined reference to `input_register_polled_device' Mar 03 14:07:41 | make[1]: *** [/home/user/yocto-colibri-imx7/build/tmp/work-shared/colibri-imx7/kernel-source/Makefile:1106: vmlinux] Error 1 Mar 03 14:07:42 guys Mar 03 14:08:59 LetoThe2nd: the problem with copping an attitude is that two can play. Mar 03 14:09:20 what to do if i get a ld error like that, i mean it's strange that linker can't reference Mar 03 14:09:22 yates: i know! i love playing! Mar 03 14:10:17 LetoThe2nd: there are fools on every corner. Mar 03 14:11:12 yates: yeah. believe me, its really hard work to be in all these places. it makes me feel extremely multiple and distributed. Mar 03 14:26:59 how can I make bitbake apply a git patch for a git submodule? Mar 03 14:28:01 LetoThe2nd: it's in the tab on the left of the website: https://docs.yoctoproject.org/sdk-manual/index.html Mar 03 14:28:32 qschulz: don't tell me :) Mar 03 14:28:40 yates: ^ Mar 03 14:31:31 medaliyou: linux/input-polldev.h is removed in newer kernels, that's all I can say Mar 03 14:32:02 please what is the alternative ? Mar 03 14:32:59 https://elixir.bootlin.com/linux/v5.4.91/C/ident/devm_input_allocate_polled_device Mar 03 14:33:02 according to bootlin Mar 03 14:33:05 it still exists Mar 03 14:33:13 5.4.91 is my kernel Mar 03 14:35:07 is it an out-of-tree driver you're trying to build? Mar 03 14:36:40 i m creating a recipe for the kernel that copies sources & headers to /drivers/X and applies PATCHES to the corresponding Kconfig & Makefile Mar 03 14:42:51 medaliyou: didn't understand what you mean. Just create a patch containing your entire driver, makefile, kconfig and everything and add it to the SRC_URI of the kernel, that should be enough Mar 03 14:42:59 (need to modify your defconfig too though) Mar 03 14:43:57 alright, just a quick last question Mar 03 14:44:47 is it a stupid idea to use an older version of /drivers/input/input-polldev.{h,c} in new kernel . Mar 03 14:45:44 there's no input-polldev.h in drivers/input. But why would you do that in the first place? Mar 03 14:45:56 don't you want to benefit from bug fixes? Mar 03 14:46:39 hhhhhhhhh, cause i have a big ass kernel module file written for 4.14.X kernel , i need to make it works for 5.4.91 Mar 03 14:48:39 * derRichard smells fun with out of tree modules Mar 03 14:48:56 * qschulz runs fast and far Mar 03 14:49:58 medaliyou: then it's time for you to upgrade the kernel module or ask your vendor to provide you with one that works with 5.4 kernels Mar 03 14:50:18 you're right bro Mar 03 14:50:20 god bless you Mar 03 14:51:56 or bite bullet and upstream it Mar 03 14:58:14 derRichard: there'll still be a backporting effort to 5.4 but yes, much safer long term :) Mar 03 14:59:36 but the input subsystem isn't usually one that changes much over time Mar 03 15:00:03 JaMa: I need to look more at the code to have an answer to that. I do think we need to fix it somehow Mar 03 15:25:23 yates: bitbake does cross and nativesdk the same way it does target vs native: there are classes for that Mar 03 17:16:18 hello, simple question, how do I access the yocto repo at a version where gcc (in meta/recipes-devtools/gcc) was at version 9 ?? Mar 03 17:16:36 need the recipe(s) to upgrade gcc on what I am working Mar 03 17:18:40 intera91: 'git checkout', work back in the releases Mar 03 17:18:59 though "one does not simply upgrade gcc" Mar 03 17:19:10 i know Mar 03 17:19:49 have to try though as program uses filesystem:: and it won't link on gcc 8 Mar 03 17:20:27 most likely easier to just upgrade the entire oe-core release Mar 03 17:28:54 intera91: what rburton says is right. Did you just email me that question too? Mar 03 17:30:16 RP, @rburton, yes am afraid so, am sorry if i broke the etiquette, Mar 03 17:31:01 intera91: mailing lists or irc but probably not both at once and don't email individual developers please! :) Mar 03 17:31:21 @RP: duly noted thanks Mar 03 17:49:31 RP: if I have a BSP layer in hand with a bunch of kernel module recipes that install stuff to KERNELSRC to enable building other modules, what should I be recommending the upstream BSP folks do instead? Mar 03 17:50:44 RP: I ask because they're triggering the pseudo abort now unless I add KERNELSRC to PSEUDO_IGNORE_PATHS for the recipes... Mar 03 17:52:14 yocto-check-layer fails on meta-openembedded too. for example meta-openembedded/meta-oe/recipes-extended/ostree/ostree_2020.3.bb changes RDEPENDS if meta-python layer is available. How should this rather be done? Via PKGCONFIG? Mar 03 17:55:36 i think adding RDEPENDS from meta-python for ostree-ptest should be done if PTEST_ENABLED, not if meta-python is in BBFILE_COLLECTIONS Mar 03 18:00:44 smurray: it can make sense for recipes to add to PSEUDO_IGNORE_PATHS if they need to Mar 03 18:02:19 RP: okay, I've sort of been doing that in my test build Mar 03 18:18:16 Hello all; berton and I are debugging an issue related to locales; it seems OE-Core does not have C.UTF-8 however it seems to be supported by glibc. Is this a known issue? Mar 03 18:40:42 otavio_: there's a variable to control whether the .utf-8 suffix isn't necessary. that is, if set, C is C.utf-8, en_US is en_US.utf-8, etc. i'd check that. Mar 03 18:41:03 otavio_: LOCALE_UTF8_IS_DEFAULT ?= "1" in default-distrovars.inc Mar 03 18:42:14 istr something going by about not all distros having C.UTF-8 Mar 03 18:42:35 maybe that's historical at this point Mar 03 18:43:05 kergoth: it is not. Mar 03 18:45:35 kergoth: we got an error (fixed in https://github.com/OSSystems/compress-tools-rs/commit/f4f06685c702dae1233110c5da4659c73c133ab3) with libarchive and it turns out to be due to C not being C.UTF-8. On Debian, Ubuntu and Fedora it works out of box as C.UTF-8 is used Mar 03 18:45:49 interesting Mar 03 18:46:15 from some research Gentoo said newer glibc supports it Mar 03 18:46:41 and Debian still has a patch for it https://salsa.debian.org/glibc-team/glibc/-/blob/sid/debian/patches/localedata/locale-C.diff Mar 03 18:47:18 smurray: yes; Debian seems to be the first to add it and others followed Mar 03 19:43:27 I wanted to make a 'macro' that could be invoked to create basic init system files for a recipe (I use runit, so the unit files many projects generate doesn't work for me for now). Mar 03 19:43:27 I set up a bbclass with a `register_service_with_init_system` python function (def style) and a `do_init_system_registration` task that runs before do_install. Mar 03 19:43:27 The idea is a .bb recipe could inherit my class, use an anonymous python function to invoke `register_service_with_init_system("service", etc)` which adds the passed parameters (as a dictionary) to a list that is stored with d.setVar() all during the parsing stage. Then during build, `do_init_system_registration`runs and reads the array out of d to write the necessary files. (I believe that d is scoped to the recipe, Mar 03 19:43:27 so my variable won't affect other recipes) Mar 03 19:43:27 This runs, but I am given the error: "The metadata is not deterministic and this needs to be fixed." Mar 03 19:43:28 I think the issue is that the value read from d in `do_init_system_registration` is different when from when it is first parsed and after the anonymous python function is run. I appreciate that yocto aims to have deterministic builds, but I would argue that this IS deterministic since I only set this variable during parse. Mar 03 19:43:28 Is there any way around this, or does anyone have a better idea than my approach? Mar 03 20:02:23 RP: looking at runqemu, I think there is a need to overhaul the -vga handling. Currently "novga" just adds an extra vga of none, which doesn't actually disable vga output. I'm thinking we probably need a QB_VGA (probably with a better name) and work from there, as qemuarm and qemuarm64 are setting the vga devices via QB_OPT_APPEND. There might be others out there, as I've not dug very deep. Am I insane for thinking Mar 03 20:02:23 this? Mar 03 20:03:16 I just wanted a sanity check before going down this rathole Mar 03 20:03:33 Hi all, I'm trying to add ipset (part of netfilter) to my build. I added KERNEL_FEATURES="features/netfilter" and I do have netfilter in the build but not ipset. Any clues or pointers? Mar 03 20:05:43 courchea: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=ipset Mar 03 20:06:01 looks like you just need to add it to the image Mar 03 20:06:18 making sure you have meta-networking ther Mar 03 20:07:34 hmmm will double check my stuff. Mar 03 20:24:44 @jonmason. I do have meta-openembedded/meta-networking, but adding ipset to CORE_IMAGE_EXTRA_INSTALL I get a Nothing RPROVIDES 'ipset' Mar 03 20:26:26 courchea: looks like you might be right Mar 03 20:26:28 http://cgit.openembedded.org/meta-openembedded/tree/meta-networking/recipes-filter/ipset/ipset_7.10.bb?h=master Mar 03 20:26:38 I see nothing there doing a RPROVIDES Mar 03 20:27:15 maybe add by hand to the recipe, verify it works, and then send a patch to the mailing list Mar 03 20:28:00 I think I know... I'm on dunfell and ipset was integrated later on.... Mar 03 20:32:50 I guess I'll have to rebuild from scratch on master. Will start that or else my laptop will be unusable for the day lol Mar 03 20:32:52 courchea: https://layers.openembedded.org/layerindex/branch/dunfell/recipes/?q=ipset Mar 03 20:32:59 meta-openwrt might have it Mar 03 20:33:08 but that does make sense Mar 03 20:33:50 @jonmason I'm building for x86-64 could I use an openwrt layer in it ? Mar 03 20:34:22 I've never messed with that layer, but I'm assuming that it would at least compile for x86 targets Mar 03 20:35:16 Ok, well already flushed my tmpdir to rebuild on master. Will see how that goes and then maybe retry dunfell woth the openwrt layer. Thanks Mar 03 20:35:19 you could always compile for machine qemux86-64 and then runqemu for it and see if it is there and works Mar 03 20:35:32 good luck Mar 03 21:07:56 jonmason: at a quick glace knowing nothing of the subject it sounds reasonable Mar 03 21:09:12 RP: I'll see if I can't get a rough patch out for comment in about an hour. I think I know what would work Mar 03 23:35:48 I am trying to find a way to set data with an anonymous python method, and then interpret that data in a python task to write some files. Whenever I do this, I get "The metadata is not deterministic and this needs to be fixed." Mar 03 23:40:01 hello I tried the hello world example from bitbake-user-manual (capter 6 ) and I got 1 error and 2 warning . could you explain me? **** ENDING LOGGING AT Thu Mar 04 02:59:56 2021