**** BEGIN LOGGING AT Fri Nov 27 02:59:56 2020 Nov 27 07:31:53 good morning Nov 27 07:33:18 I don't get this point https://imgur.com/daHIw44.png , if VAR1 contains "12 34" and VAR3 contains "5" but then you use VAR3 += "${VAR1}" should not this produce that VAR3 contains "5 12 34" Nov 27 07:34:06 and then if you assign VAR3 =+ "${VAR2}" this should not produce that VAR3 contains at the end "67 89 5 12 34"? Nov 27 07:34:28 good morning mckoan 👋 Nov 27 07:34:36 In my attempts to get lib32-libgdiplus building on Yocto Sumo, it seems like the variable "STAGING_BINDIR_CROSS" is causing this issue. When I build my multilib image with bitbake -e, I can see that STAGING_BINDIR_CROSS is set to the "recipe-sysroot" directory, which works fine for building libgdiplus, but when building lib32-libgdiplus, STAGING_BINDIR_CROSS is still "recipe-sysroot" not Nov 27 07:34:44 "lib32-recipe-sysroot" as required. This recipe has som postinstall intercept scripts, which I guess is the reason why other lib32-* packages work, but this one does not. Unfortunately I do not have the deep knowledge of bitbake to understand exactly why this is happening, and what the best way to resolve it is. Nov 27 07:37:49 I can see in bitbake -e that it uses ${MLPREFIX} to set up the "recipe-sysroot" dir, but $MLPREFIX appears to be the same for the entire do_rootfs-stage of my image build (i.e. empty) Nov 27 07:38:46 The solution would seem to be to set up the STAGING_DIR_HOST variable differently for postinstall-intercepts that are using multilib, but I really have no idea how to do that properly. Nov 27 07:39:27 (STAGING_BINDIR_CROSS contains STAGING_DIR_HOST, pointing at the recipe-sysroot directory) Nov 27 08:22:16 wyre: += is appending, =+ is prepending Nov 27 08:22:41 mckoan: o/ Nov 27 08:23:13 qschulz, then VAR3 =+ "${VAR2}" should be "67 89 5" Nov 27 08:24:03 yes Nov 27 08:24:47 same for the .= =. Nov 27 08:25:02 and one important thing to keep in mind, the order or declaration does not matter Nov 27 08:25:48 so, you could technically have VAR2 = "5", VAR3 += "${VAR2}", VAR2 += "3" Nov 27 08:26:13 in that case, VAR2 is 5 3 and var3 is " 5 3" Nov 27 08:26:34 only := requires direct expansion Nov 27 08:30:18 qschulz, so is there an errata in the book? https://imgur.com/daHIw44.png Nov 27 08:31:25 wyre: yes. but honestly, just test yourself, for something that easy to reproduce Nov 27 08:31:33 create a dummy recipe Nov 27 08:31:40 add your stuff, play with the variables Nov 27 08:31:46 qschulz, that would be awesome Nov 27 08:31:59 could I call bitbake for just that recipe? Nov 27 08:32:01 and run bitbake -e my-recipe and look for the line starting with your variable Nov 27 08:32:31 oh, I see Nov 27 08:32:35 I'm going to try Nov 27 08:32:56 wyre: you bitbake recipes, it can either be package recipes (SW) or image recipes (usually what one does to get an artifact (rootfs) to flash ona device) Nov 27 08:33:38 when you create a package recipe you get something like .deb? or .ipk? Nov 27 08:40:43 wyre: depends on what PACKAGE_CLASSES is set to Nov 27 10:03:09 qschulz: :| Nov 27 10:03:26 Hi, I have set variable IMAGE_ROOTFS_SIZE to 512 MiB... and I thought my rootfs image would be exactly 512MiB, but it turns out it is over 600 MiB... I tracked down issue to dnf recipe that appends to IMAGE_ROOTFS_EXTRA_SPACE. Nov 27 10:03:51 How can I make sure my rootfs will also take into account this extra space? Nov 27 10:04:00 and it will not exceed 512 MiB in total Nov 27 10:04:06 * mckoan doesn't like to run a full Yocto training using IRC Nov 27 10:10:03 yo dudX Nov 27 10:11:55 wooosaiii: maybe nailing down IMAGE_ROOTFS_EXTRA_SPACE in your machine conf works. Nov 27 10:15:03 LetoThe2nd: I don't it will work as dnf package appends to this variable: Nov 27 10:15:04 poky/meta/classes/rootfs_rpm.bbclass:IMAGE_ROOTFS_EXTRA_SPACE_append = "${@bb.utils.contains("PACKAGE_INSTALL", "dnf", " + 102400", "" ,d)}" Nov 27 10:15:39 wooosaiii: just one more reason to not use rpm/dnf :) Nov 27 10:15:45 LetoThe2nd: :D Nov 27 10:16:12 * LetoThe2nd is an ipk guy. Nov 27 10:16:39 and even more, i'm a non-runtime-package-management guy. Nov 27 10:16:50 LetoThe2nd: my solution at the moment is to install python anonymous function to check and set IMAGE_ROOTFS_SIZE variable accordingly to EXTRA_SPACE variable Nov 27 10:17:36 but feels like a dirty workaround and some more elegant solution should be possible :D Nov 27 10:17:54 like... using ipk and/or no runtime package management? ;-) Nov 27 10:17:57 RP: Should the autobuilder pick up new pushes to the master branch of yocto-docs? Nov 27 10:18:13 Looking at https://autobuilder.yoctoproject.org/typhoon/#/builders/114 it's not built the latest commits Nov 27 10:18:32 LetoThe2nd: probably could remove IMAGE_FEATURES += "package-management" yeah Nov 27 10:19:05 but greping through sources grep -r IMAGE_ROOTFS_EXTRA_SPACE . Nov 27 10:19:25 reveals more recipes do the same :D and we could stumble upon the same issue again :D Nov 27 10:19:41 RP: In fact, the last 4 builds of the docs used the same commit 276740dd3 from a week ago. Nov 27 10:32:27 paulbarker: it does sound like there is something wrong, ndec was mentioning this too Nov 27 10:33:11 i haven't been able to understand what went wrong.. Nov 27 10:36:25 RP, ndec: https://autobuilder.yoctoproject.org/typhoon/#/builders/114/builds/34/steps/3/logs/stdio Nov 27 10:36:42 Looks like it is fetching from the right place but getting the same commit as builds 31, 32 and 33 Nov 27 10:36:57 yes, i saw that.. i don't understand why it does it ;) Nov 27 11:30:29 Hello all, that's my second time in the IRC chat and hopefully somebody can help me solving my little Yocto issue. I want to rename and copy a dtb file to the boot partition. How do I add a file to the boot partition? Can I add a do_bootimg_append() in e.g. my layers recipe-kernel/linux/linux-raspberrypi_%.bbappend file? Would be really cool to get some suggestions on how to do something like this. Thanks, Florian Nov 27 11:31:11 I know that the KERNEL_DEVICETREE or KERNEL_DEVICETREE_append copies a file Nov 27 11:31:22 But I want to rename it as well Nov 27 11:31:57 And I cannot find any solution on how to RENAME the dtb when adding it to the boot partition Nov 27 11:37:09 FloRiAn_: You can deploy the new file to `DEPLOYDIR` and add it to `IMAGE_BOOT_FILES` Nov 27 11:37:40 FloRiAn_: Take a look at https://github.com/agherzan/meta-raspberrypi/blob/master/conf/machine/include/rpi-base.inc#L119 Nov 27 11:38:20 It's a space separated list, each element is either just filename or a `;` pair Nov 27 11:38:55 E.g. `u-boot.bin;${SDIMG_KERNELIMAGE}` copies over `u-boot.bin` and renames it to the filename that the RPi boot ROM looks for Nov 27 11:40:54 @paulbarker: Wow this is really helpfull! I didn't know, that renaming can be that easy. Thanks a lot for your explanation. Will now dig into the code example you sent. Thanks a lot! Nov 27 11:55:01 I just saw your conversation on ipk vs rpm for package management. I have used rpm without thinking about up until now, simply because that was the default. Would it make any difference to the final image if I were to switch to ipk? I am not using any package management on the target. Nov 27 11:59:06 iceaway: without runtime pm there should be no noticeable differences, except for corner cases maybe Nov 27 12:10:27 we should add QA to verify that the end images are binary identical Nov 27 12:33:01 I'm trying to build a recipe which depends of a python library to be in sysroot-native. is it enought to add the dependency to DEPENDS? Nov 27 12:34:28 DEPENDS=python3-foo-native, but you also need to inherit python3native to run the right python binary Nov 27 12:34:46 the host python won't look inside the sysroot, and any C modules won't link either Nov 27 12:40:48 aha, I was the -native part. thanks Nov 27 12:44:13 yeah you can't run target code on the host Nov 27 12:44:31 LetoThe2nd: I think ipk is slightly faster for building an image? Nov 27 12:44:48 qschulz: no idea. Nov 27 12:51:32 qschulz: would be an interesting benchmark to run Nov 27 12:54:22 rburton: pretty sure this was done by the person who wanted to add support for apk? Nov 27 12:55:31 found it, will link Nov 27 12:57:14 https://lists.openembedded.org/g/openembedded-core/message/140148 Nov 27 12:57:21 so, actually slower than rpm Nov 27 13:11:22 paulbarker, ndec: I reran the docs build and it seems to have done the right thing. Not sure why it did't previously Nov 27 13:19:39 RP: hmm.. yes, now it worked... Nov 27 13:47:59 LetoThe2nd: thanks! Nov 27 16:11:07 @qschulz: I still was'nt able to determinate why building the ADI kernel failes, but I found a workaround. apparently slapping "${WORKDIR}/" infront of the KERNEL_EXTRA_FEATURES did the trick (as you pointed out some of the paths were not absolute). I have no idea why it works in the case of the default poky kernel. maybe I'll figure it out but for now I'm happy to have found a workaround. Nov 27 16:29:10 have the ame recipe appears in two layers, trying to use BBFILE_PRIORITY to get it to select correct recipe, but it does not. any ideas? Nov 27 16:32:56 lxc: bitbake-layers show-recipes might give you some hints IIRC (not sure) Nov 27 16:32:56 lxc: it takes the layer priority into account Nov 27 16:33:43 lxc: highest BBFILE_PRIO means the recipe in that layer has prio, are you sure it's in the layer of the higher/highest prio? Nov 27 16:36:38 It sees two recipesbinutils: meta 2.32.0 meta-mylayer 2.34and meta-mylayer has prio 10 and meta layer has prio 5 Nov 27 16:46:32 lxc: look for a PREFERRED_VERSION_binutils ;) Nov 27 16:47:06 ndec: we talked about removing the trailing slash ;) Nov 27 16:47:33 trailing or leading? Nov 27 16:47:59 well... trailing in directive but leading in the one using the directive :) Nov 27 16:48:10 can't remember if it was via mail or IRC? Nov 27 16:50:04 @lxc: or you could BBMASK the unwanted recipe and try to rebuild the component. See if it then still builds with the recipe from the desired layer or if it throws warnings / errors Nov 27 16:51:47 qschulz: right.. i keep getting back at our discussions... we should use bugzilla more ;) Nov 27 16:52:58 ndec: agreed Nov 27 16:53:14 qschulz: i have 2 large series locally that I haven't sent yet. renaming of all the files, and removal of the backquotes in the section title. Nov 27 16:54:58 ndec: https://lists.yoctoproject.org/g/docs/message/393?p=,,,20,0,0,0::relevance,,yocto_git,20,2,0,76918954 Nov 27 16:56:13 ndec: AH! what about the link only? e.g. I want https://yoctoproject.org/, :yocto_home:`` this probably does not work Nov 27 16:56:29 right.. "so perhaps we should use extlinks for what it's supposed to be, and use variables otherwise, e.g. &YOCTO_GIT_URL; when I just need the link.". i still agree with what I said ;) Nov 27 16:56:31 absolutely not english but I think you understood :) Nov 27 16:57:37 ndec: all good then, "the link only" => &YOCTO_HOME_URL; and the rest without the leading slash Nov 27 16:57:46 (the absolutely not english was for me not you ;) ) Nov 27 16:58:02 heh. Nov 27 17:43:27 qschulz PREFERRED_VERSION_binutils it is. Many thanks! Nov 27 18:14:46 Is there ever a reason to have `IMAGE_INSTALL_append = "something" instead of " something" ? Nov 27 18:15:09 It seems like in most circumstances, this requirement just to have space is a burden on the brain, why is it this way? Nov 27 18:23:45 matthewcroughan_ I have bumped on to at least two cases where two packages were too close together Nov 27 18:37:18 What is the yocto jester's name? :D Nov 27 18:42:49 matthewcroughan_: LetoThe2nd when he's online **** ENDING LOGGING AT Sat Nov 28 02:59:56 2020