**** BEGIN LOGGING AT Sun Feb 07 02:59:58 2021 Feb 07 07:49:03 The link http://www.airspayce.com/mikem/bcm2835/bcm2835-${PV}.tar.gz is invalid Feb 07 07:49:19 why is it still there then? Feb 07 16:00:40 can I somehow make a recipe to rebuild (not use cache) if output of different recipe changes? I'm trying to getrid of this nostamp (line 25) https://git.yoctoproject.org/cgit/cgit.cgi/meta-security/tree/recipes-core/images/dm-verity-image-initramfs.bb#n25 Feb 07 16:03:04 I guess this nostamp makes initramfs always rebuild whatever package I'm trying to build. probably through libc -> kernel -> initramfs dependency chain? Feb 07 16:37:05 loblik, if a recipe change, the signature of the rootfs change so you need to rebuild the initramfs anyway, right ? Feb 07 16:46:55 if I want to build whole image then yes. but most of the time I want to rebuild just one package and then it also rebuilds initramfs and kernel. that only happens if this nostamp is present. Feb 07 16:54:01 I was also thinking about removing the nostamp and writing some hook which would indicate if initramfs from cache can be reused or not. by checking if rootfs has changed. Feb 07 16:54:09 but I'm not sure if this is possible Feb 07 17:31:38 ok, I don't know the answer to your original question, but if I were you, i'd use "git blame" to try to figure out why that nostamp is here... Feb 07 17:37:50 It's there to make sure the initramfs always contains latest root hash (even in cases when bitbake does not consider rootfs image as changed). It's nicely described here https://www.yoctoproject.org/pipermail/yocto/2019-August/046464.html Feb 07 17:39:30 I'm just looking for a better solution then to always rebuild intramfs. Feb 07 18:17:47 Hi - I'm running into a confusing issue trying to build an image based on core-image-sato the the gatesgarth branch. Feb 07 18:18:18 Some of the packages fail a QA test since they seem to be dependent on glibc 2.33: Feb 07 18:18:20 ERROR: zip-3.0-r2 do_package_qa: QA Issue: /usr/bin/zipsplit contained in package zip requires libc.so.6(GLIBC_2.33)(64bit), but no providers found in RDEPENDS_zip? [file-rdeps] Feb 07 18:18:20 ERROR: zip-3.0-r2 do_package_qa: QA run found fatal errors. Please consider fixing them. Feb 07 18:18:21 ERROR: Logfile of failure stored in: /home/ori/projects/poky/build/tmp/work/core2-64-poky-linux/zip/3.0-r2/temp/log.do_package_qa.25098 Feb 07 18:18:21 ERROR: Task (/home/ori/projects/poky/meta/recipes-extended/zip/zip_3.0.bb:do_package_qa) failed with exit code '1' Feb 07 18:20:50 I can't find glibc 2.33 anywhere in sysroot and the compile log for these packages doesn't seem to be accessing it from elsewhere. Feb 07 18:42:55 * RzR played with yocto this fosdem weekend : https://twitter.com/RzrFreeFr/status/1358478781258878978#:pinball-ohos-fosdem2021 RT <3 ! Feb 07 19:06:28 Also, how can I find which packages directly depend on a package that's reported in a "Nothing PROVIDES 'package-name'" error? Feb 07 19:51:49 for native recipe how can I add bash scripts into sysroot-native? at do_populate_sysroot stage? it checks for binaries only, not for .sh Feb 07 20:14:23 I have native recipe that needs to install bash scripts into recipe-sysroot-native/, but only binaries are installed. How can I include bash scripts? Feb 07 21:13:49 dvorkindmitry: you should not be defining do_populate_sysroot at all. write a do_install that installs them to ${D}${bindir} and that's all you need to do Feb 07 21:25:45 kergoth, it doesn't work. I defined do_install and the binary is not installed into recipe-sysroot-native/ of the recipe B Feb 07 21:35:54 Ok, I think I now understand more the issue. Is there a way to actively (in a hook or something) stop a setscene task and fallback to rebuilding? Feb 07 23:01:25 dvorkindmitry: well i think it's probably what you defined in your do_install that's causing the bash script not to be created Feb 07 23:03:01 dorinda, it is worse. I can't even get the binary from A-native recipe in recipe-sysroot-native/ of the recipe B... Feb 07 23:04:21 https://pastebin.com/A5dShZh8 Feb 07 23:22:45 maybe you should try: echo "DV destdir0:${D}" > ${D}/usr/bin/profile.d/myscript.sh Feb 07 23:23:54 mkdir for profile.d first Feb 07 23:54:37 dorinda, it doesn't work Feb 07 23:54:54 no myscript in recipe-sysroot-native/ of the recipe B Feb 07 23:59:42 hmm, i don't know maybe someone else can help you out. Feb 08 00:05:28 dorinda, I see the big difference between bc-native and myrecipe-native in the workdir: Feb 08 00:05:59 bc: find ./ -name "bc" Feb 08 00:05:59 ./image/disk2/build.26/tmp/work/x86_64-linux/bc-native/1.07.1-r0/recipe-sysroot-native/usr/bin/bc Feb 08 00:06:00 ./bc-1.07.1/bc Feb 08 00:06:00 ./bc-1.07.1/.pc/no-gen-libmath.patch/bc Feb 08 00:06:00 ./build/bc Feb 08 00:06:00 ./build/bc/bc Feb 08 00:06:00 ./sysroot-destdir/disk2/build.26/tmp/work/x86_64-linux/bc-native/1.07.1-r0/recipe-sysroot-native/usr/bin/bc Feb 08 00:06:01 my: find ./ -name "myscript*" Feb 08 00:06:01 ./image/usr/bin/profile.d/myscript.sh Feb 08 00:26:02 where can I find ${bindir} definition for native recipe? Feb 08 00:52:39 Would somebody be able to point me to where I should look to understand how a .dtb is compiled from a .dts residing in the boot/dts/ directory of my kernel sources? I know that it is found from the name set in `KERNEL_DEVICETREE`, and there are classes like `classes/devicetree.bbclass` that seem related, but it feels like the actual compilation (from dts to dtb) is not done there. Is that done by some kernel tool (and not by Feb 08 00:52:39 yocto scripts)? Feb 08 00:54:13 dtc compiles it. Feb 08 00:54:27 The reason I'm asking is that my dts is in another sublevel (boot/dts/qcom/my.dts instead of boot/dts/my.dts), and it seems like something fails because of that subdir. I can workaround it by creating a folder manually in my tmp, but I'd like to understand if I'm doing it wrong or if there may be a bug Feb 08 00:55:07 And dtc is a tool built by yocto and run when compiling the kernel? Feb 08 00:55:48 the kernel tree always carries a copy of dtc. but it is its own standalone project, since it is used by more than linux. Feb 08 00:58:00 but yes, there's a dtc recipe as well. and the devicetree.bbclass makes use of it. Feb 08 01:03:13 Right. But then if at compile time "something" fails to create the right subfolder in tmp (for the .dtb.dts.tmp file), should I look into the dtc in my downstream kernel sources, or the dtc recipe? Feb 08 01:07:29 can't say. i don't know your kernel recipe, if it is using the kernel to build the dtb (kernel-devictree.dtb), how the variables have been defined in your build, etc. but it is not likely a bug in the kernel or the classes, but one in how the dts is specified (there are hundreds of builds going on daily with various dts, and they are ok). Feb 08 01:13:06 I see... Well I just say "KERNEL_DEVICETREE+="qcom/my.dtb", and it seems to find the corresponding dts. But then the qcom subfolder is missing during the build. The thing is that if I set "KERNEL_DEVICETREE+="my.dtb", then it just does not find the dts at all Feb 08 01:13:29 And I'm not really setting anything more than that 🤔 Feb 08 01:17:49 it's the kernel doing that compilation. So super unlikely there's a bug. The dts could be in the wrong place, or something else up with the vendor tree. but that's the tried and true kernel build for that dtb. Not impossible, just very unlikely. You can see how the build is handed off to the kernel in the kernel-devicetree.bbclass (which args it passes, etc). Feb 08 01:20:34 Got it, I'll go look more into that Feb 08 01:20:45 Thanks ☺️ Feb 08 02:27:50 dvorkindmitry: my guess is you didn't inherit native in your naitve recipe, or didn't use bbclassextend. just *naming* a recipe something-native doesn't mean it'll do what native recipes do Feb 08 02:28:48 dvorkindmitry: actually posting your recipe would make diagnosing it much easier **** ENDING LOGGING AT Mon Feb 08 03:01:12 2021