**** BEGIN LOGGING AT Fri Jan 22 02:59:58 2021 Jan 22 08:23:13 I wonder how long distros want to continue CVE patching qemu, endless stream of things to fix... Jan 22 09:38:27 mcfrisk: and some of the patches are sitting unmerged for two years :/ Jan 22 09:40:52 hello guys ! I need a tip.. I've "created" a recipe (myfitimage.bb) that inherit myfitiamge.bbclass and install the compiled itb in the deploydir. In order to build the fitimage correctly I need 4 things: dtb,fpga,kernel,ramdisk. So basically the fitimage dependencies are virtual/dtb, virtual/hdf,virtual/kernel, core-image-minimal (IMAGE_FSTYPES += Jan 22 09:40:52 cpio.gz). Jan 22 09:41:42 How can I manage the fitimage.bb recipe being called automatically when I want to compile core-image-minimal ? Jan 22 09:42:08 (without breaking the compile process due to dependency) Jan 22 09:50:45 hello guys ! I need a tip.. I've "created" a recipe (myfitimage.bb) that inherit myfitiamge.bbclass and install the compiled itb in the deploydir. In order to build the fitimage correctly I need 4 things: dtb,fpga,kernel,ramdisk. So basically the fitimage dependencies are virtual/dtb, virtual/hdf,virtual/kernel, core-image-minimal (IMAGE_FSTYPES += Jan 22 09:50:46 cpio.gz). Jan 22 09:50:46 How can I manage the fitimage.bb recipe being called automatically when I want to compile core-image-minimal (without breaking the compile process due to dependency) ? Jan 22 10:35:07 After updating from zeus to Gatesgarth I found some patches don't find the target file. Have the way yocto handled patches changed between those releases? The recipes and files that I was patching didn't changed (at least "git diff zeus..gatesgarth ." didn't show any results) Jan 22 10:36:27 rburton: does vulkan-samples contain git-lfs and was this part of the reproducibility issue?! :( Jan 22 10:38:54 * rburton looks Jan 22 10:39:11 man its a large repo Jan 22 10:40:47 assuming the recipe does a gitsm clone yes it has LFS Jan 22 10:41:22 actually my detection was a bit keen Jan 22 10:44:06 it does have LFS Jan 22 10:44:14 but i think the lfs detection in the fetcher is broken Jan 22 10:45:04 yes, it is Jan 22 10:45:49 the problem is submodules and lfs Jan 22 10:45:59 the lfs detection assumes the parent repo uses it Jan 22 10:51:05 rburton: I'm not sure I follow, if one of the submodules uses it, surely we need it period? Jan 22 10:55:07 yes Jan 22 10:56:19 The Yocto man sais Yocto build is not compatible with wsl. Why is that? Jan 22 10:56:20 but git.py just looks in the top level Jan 22 10:56:29 sveinse: because wsl1 is lame. use wsl2. Jan 22 10:56:37 I am using wsl2 Jan 22 10:56:41 works fine then Jan 22 10:56:55 thanks Jan 22 10:57:00 the docs should be clear that its wsl1 that isn't supported Jan 22 10:57:48 Ah, I didn't have the latest version of the manual. Its mentioned there. Sorry and thanks Jan 22 12:05:53 Are there any of the older Yocto releases which are more actively maintained than others with respect to security updates? Jan 22 12:07:10 I'm stuck in a situation where I cannot update a product to Dunfell, because isn't graphics drivers isn't updated by the SoC vendor Jan 22 12:14:54 sveinse: what do you mean by "graphics drivers"? Jan 22 12:15:04 kernel drivers? Jan 22 12:19:47 greetings all, hopefully a simple question, the sstate-cache directory, does it need to be on a case sensitive filesystem? Jan 22 12:45:42 rb_: i wouldn't be surprised if something failed if it wasnt. Jan 22 12:45:50 worth a try though Jan 22 12:46:06 sveinse: no Jan 22 13:13:26 qschulz: yeah, kernel drivers and the corresponding user space libraries. More specifically imx6 graphics, where the open source etnaviv driver doesn't support dithering, creating ugly banding in output. Jan 22 13:14:20 rb_: I've been using NTFS as store for sstate cache, and it has worked well. Jan 22 13:14:54 Explorer will croak over some of the filenames, but that's explorer and not about NTFSs capabilities Jan 22 13:23:21 Has more recent bitbake capabilities that allows building packages incrementally without the building the fullblown system? What I would like to acheive the ability to build and distrbute a Yocto built base system and then allow for application teams to build and deploy packages on top of that without having to build the entire system from scratch. E.g. the ability to make ipkgs from a SDK Jan 22 13:23:23 sveinse: have you tried with latest mesa and kernel for etnaviv by any chance? Jan 22 13:24:00 sveinse: you can always host a sstate cache mirror for starters Jan 22 13:24:04 qschulz: yes, gatesgath. and it has banding Jan 22 13:24:11 qschulz: I do that too Jan 22 13:24:28 sveinse: back to the first question, just take the old kernel drivers and userspace libraries and update all the rest Jan 22 13:24:36 you just need BSP stuff from you vendor Jan 22 13:25:11 qschulz: I thought so too, but our HW vendor (which delivers BSP) sais that this isn't possible in this case Jan 22 13:27:31 sveinse: have they given a reason for this? Jan 22 13:28:48 sveinse: they probably don't want to support you if you go for this Jan 22 13:29:00 qschulz: yes, but none that is technically detailed, hence my investigation Jan 22 13:29:48 qschulz: Running 4.1.15 from freescale on rocko today Jan 22 13:30:12 sveinse: have you tried meta-imx? Jan 22 13:30:59 gsalazar: no. on which version? Jan 22 13:31:40 I'm also trying to determine if it would be best for us to stick with Dunfell vs Gatesgarth, given the former is LTS Jan 22 13:33:31 qschulz: whats the relationship between meta-freescale and meta-imx? Jan 22 13:33:33 investigate if meta-imx has support for the gpu or not and then try, maybe you'll be happy with it who knows Jan 22 13:33:57 sveinse: meta-freescale is maintained by the community, meta-imx by NXP? Jan 22 13:34:31 sveinse: https://source.codeaurora.org/external/imx/meta-imx/ Jan 22 13:34:52 In all cases I need custom kernel due to custom HW, so I need my vendor on board Jan 22 13:35:18 But I'll certainly investigate this. Thanks. Jan 22 13:35:29 sveinse: custom BSP does not mean fixed Yocto version Jan 22 13:35:37 they should be decoupled, it's just that vendors don't care doing it Jan 22 13:36:35 sveinse: thanks :) Jan 22 13:37:02 Is it completely disconnected? I remember an older product (made by someone else) that we had to stop on Ubuntu 14.04, becasue the kernel couldn't be updated and Ubuntu 16.04 requred new kernel features. Jan 22 13:37:29 So is the Yocto version completely idempotent to the kernel version? Jan 22 13:39:12 you could still patch, downgrade the packages that need new features from the kernel Jan 22 13:39:28 you compile the distro yourself now, so you're not bound to whatever Ubuntu decides Jan 22 13:39:58 qschulz: hmm, meta-imx is targetting zeus, which isn't new either Jan 22 13:40:00 although... upgrading the kernel is always a possibility too ;) Jan 22 13:40:23 sveinse: zeus > rocko though :p Jan 22 13:41:01 and you can always try to make it work on dunfell too if you want, small version jumps are usually not too hardbut famous last words Jan 22 13:43:11 True and true. We're already running Dunfell, but etnaviv doesn't support dithering. AFAIK this is due to that the HW dithering module is closed source and the etnaviv doesn't (know how to) use it. Jan 22 13:43:29 Other that that Dunfell would be good Jan 22 13:49:40 does it always work out of the box, if i have recipe_5.4.bb that files are looked in recipe-5.4.bb ? Jan 22 13:50:02 i am always getting "entry defconfig: file could not be found" Jan 22 13:50:45 ops, files looked in recipe-5.4 directory Jan 22 13:51:57 ad__: yes Jan 22 13:52:22 ad__: https://docs.yoctoproject.org/ref-manual/variables.html#term-FILESPATH Jan 22 13:53:08 ad__: do you have file://defconfig in SRC_URI? Jan 22 13:53:31 i have created a bb, linux-imx-rt_5.4.70.bb Jan 22 13:53:40 and defocnfig is inside linux-imx-rt-5.4.70 Jan 22 13:53:51 so was expecting to be found Jan 22 13:54:09 ad__: have you added file://defconfig to SRC_URI? Jan 22 13:54:23 yes Jan 22 13:54:32 i get Jan 22 13:54:32 linux-imx-rt_5.4.70.bb: Unable to get checksum for linux-imx-rt SRC_URI entry defconfig: file could not be found Jan 22 13:55:13 ad__: bitbake -e linux-imx-rt | grep -e "^BP=" Jan 22 13:55:15 it's strange, seems i don't get the warning if i bitbake linux-imx-rt, but i get the wanring bitbaking the image Jan 22 13:55:26 ad__: bitbake -e linux-imx-rt | grep -e "^BPN=" Jan 22 13:55:31 (both) Jan 22 13:55:47 bitbake -e linux-imx-rt | grep -e "^BP=" Jan 22 13:55:47 BP="linux-imx-rt-5.4.70+gitAUTOINC+4f2631b022" Jan 22 13:56:29 bitbake -e linux-imx-rt | grep -e "^BPN=" Jan 22 13:56:29 BPN="linux-imx-rt" Jan 22 13:57:49 ad__: do you modify PV in your recipe or use SRCREV = AUTOREV by any chance? Jan 22 13:58:16 none of the both, i used SRCREV as a git hash Jan 22 14:08:07 qschulz, thanks, i see the issue Jan 22 14:14:54 so i fixed with setting PV = "5.4.70" but maybe, i can use AUTOREV and branch ? Jan 22 14:15:31 Is there tools in the SDK that can build ipks like bitbake does? Jan 22 14:19:38 some sort of tool which takes a description of a recipe and builds packages? Jan 22 14:19:41 sounds like bitbake Jan 22 14:21:44 hello guys ! I need a tip.. I've "created" a recipe (myfitimage.bb) that inherit myfitiamge.bbclass and install the compiled itb in the deploydir. In order to build the fitimage correctly I need 4 things: dtb,fpga,kernel,ramdisk. So basically the fitimage dependencies are virtual/dtb, virtual/hdf,virtual/kernel, core-image-minimal (IMAGE_FSTYPES += Jan 22 14:21:44 cpio.gz). Jan 22 14:21:45 How can I manage the fitimage.bb recipe being called automatically when I want to compile core-image-minimal (without breaking the compile process due to dependency) ? Jan 22 14:23:31 The use case is that our development consists of many teams, and each team delivers a component that ultimately is built into the final image. Today the team's build flow is centered around a bitbake flow, which builds systems not only application software. And the collective computing load for all this becomes significant. So I'm searching for a way to let each team have their CI/CD flow without involving Jan 22 14:23:37 the full weight of bitbake. Jan 22 14:25:12 where CI/CD is a target deployable piece of software, e.g. ipk. Jan 22 14:27:16 One way of solving it would be to have the application builds use the tools from a SDK and produce their own ipks for deployment, but that is dangerously close to competing with the functionality of bitbake when doing full image builds. Jan 22 14:28:38 Are any of these considerations familiar to any of you? Or are you only and always building off a bitbake run? Jan 22 14:28:40 doesn't the eSDK just come with bitbake? Jan 22 14:41:34 ad__: AUTOREV only for development, once you release, stop using it Jan 22 14:42:05 ad__: technically, you could add any path to FILESEXTRAPATHS in your original bb Jan 22 14:50:33 qschulz, thanks a lot Jan 22 16:59:11 I have an image recipe B.bb which DEPENDS = "A.bb". When building image B, A is correctly built, but statements like IMAGE_BOOT_FILES += "foo" in A.bb aren't applied. Any idea? Jan 22 18:26:00 I have an image recipe B.bb which DEPENDS = "A.bb". When building image B, A is correctly built, but IMAGE_BOOT_FILES += "a.img" doesn't work from within A.bb, but does work from within B.bb. Any idea? Jan 22 19:41:38 in other words, bitbake A.bb -e contains a.img in IMAGE_BOOT_FILES, but bitbake B.bb -e does not. Jan 22 20:24:45 sveinse: We have a similar problem. We solved it by building an SDK for each platform that we make accessible to the app developers, and the implementing a sideload mechansim Jan 22 20:25:22 It's not perfect since deveopers have a harder time getting resources and such on the filesystem, but it's better than nothing Jan 22 21:09:41 sveinse: it soundsl ike the esdk would be your best bet.. Jan 22 22:09:38 * jonesv[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/mEDYpmzMsFFBEJHxFvnYQMKl/message.txt > Jan 22 22:14:53 I fear that I may have messed up my machine configuration. I copied things from here because I also have an apq8009: https://github.com/mcharleb/meta-qti-bsp/blob/yocto.lnx.1.0.r10-rel/conf/machine/apq8009.conf Jan 22 22:14:53 Could the machine be the reason for such an error? Jan 22 22:36:22 jonesv[m]: you've broken your kernel sources somehow and it sounds like functions and headers aren't matching. I guess bad configuration could do it too at a puch Jan 22 22:36:24 push Jan 22 22:53:37 funny because machines, images and distros are orthogonal in yocto, and we have notion of BSP layers for machines, Distro layers for distros, but no Image layers. Jan 22 22:54:23 Maybe because image recipes are what are expected to be found in non bsp or distro layers? Jan 22 23:55:36 Hmm those are the open sources for that device of mine, on the manufacturer's repo 🤨 Jan 22 23:56:48 They are supposed to publish the sources they build for the device, aren't they? Jan 22 23:57:13 I mean I don't have their toolchain, I'm trying to build in yocto Jan 23 01:09:26 I don't believe the sources have an issue. They published 12 releases over a year, if something like `cpu_suspend` had been wrong in the sources, they would have seen it. `drivers/Kconfig` has a small issue (lack of a closing "), but that's more believable I think Jan 23 01:11:18 * jonesv[m] sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/KbxKPmgPRgbZHxZkXZcHLSJL/message.txt > Jan 23 01:11:54 If `tune-cortexa7.inc` is incorrect, could it be the reason for my `error: too many arguments to function ' cpu_suspend'`? **** ENDING LOGGING AT Sat Jan 23 02:59:57 2021