**** BEGIN LOGGING AT Tue Mar 02 02:59:58 2021 Mar 02 07:34:30 Still stuck with this issue, anyone an idea: Mar 02 07:34:31 (19:41:52) eFfeM: Hmm, I added resolvconf to my image but now when building I get: Mar 02 07:34:31 (19:41:52) eFfeM: packagegroup-core-boot : Depends: systemd but it is not going to be installed Mar 02 07:34:31 (19:41:52) eFfeM: If I remove resolvconf from the image recipe it builds. Mar 02 07:34:31 (19:42:05) eFfeM: anyone an idea what is wrong? Mar 02 09:59:17 Hello  guys, how to add tensorFlow lite to Dunfell version ? thanks Mar 02 10:00:22 My ARCH: TARGET_SYS = "arm-tdx-linux-gnueabi" Mar 02 10:00:23 MACHINE = "colibri-imx7" Mar 02 10:00:23 DISTRO = "tdx-x11" Mar 02 10:00:24 DISTRO_VERSION = "5.2.0-devel-20210302095939+build.0" Mar 02 10:00:24 TUNE_FEATURES = "arm armv7a vfp thumb neon callconvention-hard" Mar 02 10:20:54 hb: this may help https://koansoftware.com/yocto-project-with-artificial-intelligence-ml-on-nxp-i-mx/ Mar 02 13:14:01 RP: heh, my first attempt at making my reproducible test reuse my sstate failed. 170m for the test run. Mar 02 13:25:42 zeddii: :/ Mar 02 13:28:07 I noticed in the setup for the build-st dir (the new one in my runs), it copies the local.conf, etc from the currnet build dir. Is it that I don't have sstate set to anything in it ? i get a sstate directory underneath the new build-st dir and even with my hack to not remove build-st, it didn't seem to use it. I'm adding some debug prints today, as soon as I figure out how to make them not get eaten :P Mar 02 13:29:20 zeddii: yes, that will likely be it Mar 02 13:30:14 * zeddii nods. I'll set it to something and look for improvement. Mar 02 13:31:21 yay, ltp reproduced Mar 02 13:31:41 little ltp's everywhere! Mar 02 13:34:20 zeddii: that is a scary thought Mar 02 13:49:13 zeddii: Ya the test only disables our sstate when instructed not to use it, it doesn't "set" it if you haven't already Mar 02 13:49:49 zeddii: Confusingly, the way it "disables" sstate is to override it to an empty directory with no mirror :) Mar 02 13:54:45 ahah. Mar 02 13:55:45 RP: Thanks for covering the meta-mingw patches. I had a busy weekend Mar 02 14:04:03 JPEW: np, I figured that one should be straightforward Mar 02 14:28:11 What is the current relationshop between versioned restricted RDEPENDS and PREFERRED_VERSION? If a have a package that requires a specific dependency version, RDEPENDS will not end up having bitabake pick the right dependency at build time - it will only be taken into consideration at rootfs generation time. Is the only solution in that case local.conf and/or distro conf with PREFERRED_VERSION? Mar 02 14:30:26 One could also do it from local.conf but it would be a unnecessary restriction for other packages. Mar 02 14:30:42 I meant `layer.conf` ^ Mar 02 14:32:47 alephan: RDEPENDS is for runtime dependencies Mar 02 14:33:15 I know. But those as I said are taken in consideration at rootfs generation time by the package mamager. Mar 02 14:33:26 alephan: AFAIR, there's no support for requiring a specific dependency version at build time except PREFERRED_VERSION Mar 02 14:33:33 So setting a version restriction on RDEPENDS doesn't mean bitbake will actually take that into consideration Mar 02 14:33:33 which cannot be set in recipes Mar 02 14:33:46 Yes you can - through versioned RDEPENDS Mar 02 14:34:04 But again, that needs to be paired with a PREFERRED_VERSION. Mar 02 14:34:08 no Mar 02 14:34:22 RDEPENDS is resolved at rootfs time Mar 02 14:34:29 That's what I said. Mar 02 14:34:58 RDEPENDS alone doesn't work because it's only used for packaging hence used by the package mamager at rootfs time. Mar 02 14:35:20 So A restriction on RDEPENDS needs to be paired in a configuration with PREFERRED_VERSION Mar 02 14:35:43 The question is how do people handle that. With a separate distro? Manually in local.conf? Mar 02 14:35:55 alephan: that seems wrong. Mar 02 14:36:00 If that is the case, it should be documented Mar 02 14:36:04 or fixed Mar 02 14:36:48 What seems wrong? Mar 02 14:37:06 restricted rdepends requires PREFFERRED_VERSION Mar 02 14:37:29 I'm not sure I follow. Mar 02 14:37:59 https://docs.yoctoproject.org/ref-manual/variables.html#term-RDEPENDS Mar 02 14:38:18 no mention of a required PREFERRED_VERSION needed for RDEPENDS on a specific version to work Mar 02 14:39:50 aaaaaah. I think I understand, you have multiple versions of the same recipe and want to use RDEPENDS package (=x.y.z) to select the correct version? Mar 02 14:39:55 I think there is a misunderstanding here. Mar 02 14:40:10 When I say version restricted RDEPENDS I mean Mar 02 14:40:10 RDEPENDS_${PN} = "package (operator version)" Mar 02 14:40:24 Cool. We are on the same page now. Mar 02 14:40:58 So how do people make sure this stays consistent while not having to enfoce the version at the level of the layer? Mar 02 14:41:03 enforce Mar 02 14:43:56 alephan: since recipes cannot impact other recipes, and only one version of a recipe can be used at build time, RDEPENDS_${PN} = "package (operator version)" is just the way to basically say "i'm compatible with those versions of the API" Mar 02 14:44:09 That is true. Mar 02 14:45:54 so,... :) what's the actual use case? As you said, PREFERRED_VERSION needs to be put into a configuration file. I highly recommend NOT putting it in layer.conf, there's nothing worse than including a layer and not understanding why the behavior has suddenly changed Mar 02 14:48:17 I know. Mar 02 14:48:17 I also said above that it Mar 02 14:48:18 it's ugly and just bad Mar 02 14:48:25 local.conf isn't really supposed to be versioned, so your next options are either machine configuration files or distro :/ Mar 02 14:48:48 machine... probably irrelevant to your use case, so you're left with distro conf file. Mar 02 14:49:05 My question still stands, how do people handle this kind of usecases? Mar 02 14:49:07 In my case is about homeassistant (which is very fussy in terms of required python modules). Mar 02 14:49:10 So I basically have a recipe that requires specific versions of some dependencies. Mar 02 14:49:22 That's what I thought Mar 02 14:49:38 It's not in any way machine specific Mar 02 14:50:44 creating your own distro conf file is fine (and recommended over the "demo" poky distro), it just is pretty painful if you need multiple ones for very small changes, because it induces a complete rebuild :/ Mar 02 14:51:00 Exactly Mar 02 14:51:35 Also, the usecase should be distro-agnostic. So I can provide a distro sample but users will create their own Mar 02 14:52:19 So I reckon the best option at this point is an include file (with version selection) + a distro sample that includes the respective file + documentation for custom distros to include the version selection inc. Mar 02 14:52:44 alephan: that seems like the right approach to me Mar 02 14:53:05 Cheers Mar 02 14:53:14 alephan: I would even go as far as putting a PREFERRED_VERSION for your homeassistant too so it's very explicit Mar 02 14:53:27 How do you mean? Mar 02 14:53:28 or put it in the name of the include file Mar 02 14:53:46 I guess different versions of homeassistant will have different requireement for its dependencies Mar 02 14:53:55 * alephan sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/DHWhYSrvcZfmxdmhIiQKZyVJ/message.txt > Mar 02 14:54:06 I'll only keep one at any time. Mar 02 14:54:08 it all depends if you want to support multiple versions of homeassistant at once Mar 02 14:54:12 then all good :) Mar 02 14:54:19 So the inc file will always match the only supported version at one time Mar 02 14:54:28 Otherwise it gets madness Mar 02 14:54:41 I mean not really - I can have versioned includes. Mar 02 14:54:46 But not today Mar 02 14:55:26 step by step :) Mar 02 14:55:52 I never thought about the restricted version RDEPENDS impact in a build so thanks for asking the question :) Mar 02 15:04:17 Cheers for a short validation qschulz Mar 02 15:36:39 Hi. How should I determine BSP version? Mar 02 15:39:23 nacknick: Hello. You have to be more explicit. What exactly are you looking for or trying to do? Mar 02 15:43:08 qschulz: https://docs.huihoo.com/automotivelinux/docs/getting_started/en/dev/reference/machines/R-Car-Starter-Kit-gen3.html#prepare-the-sd-card-on-the-host - here it says that for *BSP>=2.19* I need a different boot image than *BSP<2.19* Mar 02 15:43:26 So I need to know what BSP version I have Mar 02 15:45:18 nacknick: this needs to be asked to AGL people Mar 02 15:45:31 i think they have an irc channel Mar 02 15:52:58 hello guys.. I've a question. I want to build the drivers/net/ethernet/xilinx/xilinx_emac driver as an external module. To do so, I've generated the Yocto SDK, Mar 02 15:53:16 then I've run ARCH=arm64 CROSS_COMPILE=aarch64-poky-linux- make scripts Mar 02 15:53:29 from /sysroots/aarch64-xilinx-linux/usr/src/kernel Mar 02 15:54:02 the given device driver relies upon some CONFIG_XXX. How can I manage to set them as I want to ? Mar 02 15:55:12 thekappe: that isn't the correct procedure Mar 02 15:56:01 thekappe: I'd rather extract/copy the kernel used by YP (see S variable) and build it externally Mar 02 15:56:21 mckoan, whoa Mar 02 15:56:21 thekappe: definirely do not use the stuff in sysroots Mar 02 15:56:26 can you be more specific ? Mar 02 16:00:15 thekappe: also, do you mean out-of-tree module or just module? Because if just module, there's no need for an SDK, just compile the driver as module (you can do so in your defconfig, which you can modify with menuconfig). If out-of-tree, why? especially if you have the whole kernel sources? Mar 02 16:01:15 thekappe: in case of "just module", you need to add kernel-module- to your image one way or the other Mar 02 16:02:50 qschulz, out-of-tree module Mar 02 16:03:21 due to some boot dependency I need to run the xilinx_emac driver after the boot process Mar 02 16:03:37 since I've to configure some devices before from userspace Mar 02 16:04:30 If I build the module with "y" I can't stop it from being run automatically, so I want to build it with "m" and blacklist it Mar 02 16:06:06 I'm looking to force kas to regenerate artifacts. I'm found instructions to use bitbake to rerun the step that generates the image which seems a little opaque as I was previously relying on kas to execute the entire process. Bitbake isn't in my path. Removing the /build/tmp/images dir and rerunning kas didn't seem to trigger a rebuild. Mar 02 16:06:57 the point is that since I also need to debug the module quickly, I've copied the drivers/net/ethernet/xilinx folder from the built kernel, Hence I'm compiling it with the SDK with kernel support Mar 02 16:06:58 thekappe: you don't need all this stuff, just menuconfig and select m for your driver. Mar 02 16:07:13 thekappe: ah, here's the real reason behind it :) Mar 02 16:07:14 /msg #overc Mar 02 16:07:19 oops lol Mar 02 16:07:48 qschulz, if I leave it in the kernel every time I do a modification I need to patch and rebuild the old kernel Mar 02 16:08:29 thekappe: or... just compile the kernel yourself without Yocto Mar 02 16:08:33 by the way the driver source code as sem ifdef/ifndef entries regarding some CONFIG_XXX Mar 02 16:08:34 much faster for debugging IMO Mar 02 16:08:49 mmm Mar 02 16:08:59 (that's what I do) Mar 02 16:09:16 sounds like what mckoan also suggested Mar 02 16:09:29 thekappe: exactly like mckoan suggested :) Mar 02 16:09:50 I need to compile the module with the sdk btw right ? Mar 02 16:10:28 I've copied out the kernel-source directory, added the .config generated in the build folder Mar 02 16:10:48 and make modules Mar 02 16:11:00 with the SDK being sourced Mar 02 16:13:41 thekappe: the only thing you'd need from the SDK would be toolchain, but you can get one from your Ubuntu/Fedora/whatever host distro Mar 02 16:15:33 qschulz, ok, btw I've it already Mar 02 16:15:43 thanks for the hints Mar 02 16:21:48 qschulz: I knew you will say that:)  but it should be a general yocto (as far as I know BSP) Mar 02 16:22:49 nacknick: no, Yocto only has two versions: poky layer (1.x, 2.x, 3.x for now) and bitbake versions (1.xx) Mar 02 16:22:54 2.19 does not exist in Yocto Mar 02 16:23:44 (upstream Yocto) Mar 02 16:25:34 OK. thank you qschulz Mar 02 16:31:23 Does anybody know why of_address_to_resource() fails ? Mar 02 16:31:49 I Have a node with its "reg" property Mar 02 16:31:57 but I always get -22 Mar 02 16:32:12 CONFIG_OF=y Mar 02 16:36:15 thekappe: -22 is -EINVAL, so you probably do it the wrong way or your device tree is incorrect Mar 02 16:36:31 thekappe: you'll have much better help in linux IRC channels though ;) Mar 02 16:37:52 qschulz, yeah, you are right. Thing is I'm digging all day long Mar 02 16:38:08 and I just tried it Mar 02 16:44:41 Hi, I am new to this channel. Pls redirect me if this is the wrong place for the question. I am trying to enable native builds for unit testing my project (without using the simulator). However, I dont see a toolchain file being produced for native Mar 02 16:50:06 is there an easy way to find out which package is responsible for dragging in another package? Mar 02 16:50:07 Somehow I'm getting dhclient in my package adjacent to dhcpcd (I want to use the latter) Mar 02 16:52:00 Using bitbake, you can dump the entire dependency graph... but it's a little verbose and may not help you get closer to the answer Mar 02 16:52:38 spooster: good idea, I can at least try that Mar 02 16:52:47 are you using kas? Mar 02 16:53:33 no, would it help if I do ? Mar 02 16:53:43 eFfeM1: bitbake -g yourimage; oe-depends-dot -k dhclient:do_configure -w task-depends.dot Mar 02 16:53:46 nah, just changes how you invoke bitbake Mar 02 16:53:51 or something along those lines, that's untested Mar 02 16:54:02 from a quick check based on existing entries in my shell history Mar 02 16:54:10 oe-depends-dot gives info from the graphs Mar 02 16:54:20 I was just going to recommend `bitbake -g ` Mar 02 16:54:43 Saur, JPEW: Bitbake rev: 5f7fdf7b2d8c59805c8ef4dae84f536baa5e172b looks suspect for the performance regression - the event changes Mar 02 16:54:57 kergoth: I was looking at the output from bitbake -g Mar 02 16:55:05 RP: are you applying patches from the mailing list with git-am or something else? Mar 02 16:55:15 vdl: git am, why? Mar 02 16:57:14 RP: because the author ends up being my personal address instead of my work address, so I wanted to make sure you were not use a custom script or something (TL;DR: the problem is on my side) Mar 02 16:57:28 s/use/using/ Mar 02 16:57:58 RP: That was going to be my guess Mar 02 16:58:23 RP: Not sure why or how to fix it Mar 02 16:58:24 vdl: I can tweak the ones in -next which haven;t merged yet if that helps. Mar 02 16:58:45 vdl: You can add a From: to the start of the emails to ensure it gets set correctly if that helps too Mar 02 16:59:26 JPEW: right, I've not looked at why it might be yet. I'd guess event handlers getting run multiple times (or registered multiple times?) Mar 02 16:59:53 I naively deleted build/tmp/deploy/images trying to get kas/bitbake to realize they're missing, and regenerate them... and I simply broke most of my recipes, as the images that compose further recipes are missing. Is there a way to lightly clean things so it reuses most of the cache here? Mar 02 17:00:00 RP: indeed, for some reason this line gets removed, I'm double checking my conf ;) Mar 02 17:00:03 I'm trying to avoid re-compiling everything for a couple hours Mar 02 17:00:24 RP: Seems likely... is whoever reported the problem using multiconfig? Mar 02 17:00:53 Hmm, I guess the AB perf test probably isn't using mc... it should aleast have no impact in the non-mc case Mar 02 18:45:33 Hi, I am working on building WPE via meta-webkit and have run into an issue with the ruby dependency. When building ruby-native I get an error "fatal error: sanitizer/asan_interface.h: No such file or directory". I've tried adding gcc-sanitizers to the DEPENDS of the ruby recipe (2.7.0) without luck. I've also tried the 3.0 recipe with the same Mar 02 18:45:34 result. Can anyone point me in the right direction here? Mar 02 19:01:17 how can I name the link to my wic image "sdcard.img" and not "sdcard.img.wic"? Mar 02 19:10:46 alimon: around? Mar 02 19:13:56 alimon: can you check --cross-file value in the sstate signature before that glib-2.0 change? I think it was wrong already because FILESPATH is constructed form THISDIR and your THISDIR constructed from OEROOT doesn't include COREBASE, so maybe you didn't notice but the glib-2.0 sstate (and everything depending on glib-2.0) wasn't reused from sstate whenever your OEROOT value was different (because of full Mar 02 19:14:02 absolute paths to cross-files in glib-2.0 sstate signature) Mar 02 19:15:05 alimon: adding normpath in https://github.com/96boards/oe-rpb-manifest/blob/master/conf/bblayers.conf#L4 should cleanup THISDIR paths everywhere (not just in find_meson_cross_files function) Mar 02 19:24:28 alimon: sorry, I was reading it wrong now, it might have work for you, because find_meson_cross_files calls normpath on FILESPATH entries in filename = os.path.normpath(os.path.join(path, "meson.cross.d", element)) and it was comparing with already normpath COREBASE as set in layer.conf, so adding normpath(THISDIR) would should work better in this case as well, will send a patch in a minute Mar 02 19:43:11 JPEW: It was Saur, not sure about config but I think they do have a number of layers Mar 02 19:43:39 vdl: do you want me to change the author on those patches? Mar 02 19:56:51 RP: I tried moving my sstate to a different directory structure, built, and am now rebuilding .. over an hour and still running. I'll look again tomorrow, but clearly, I'll never sort it out with rebuild times like this. So I'll look at the test case and see if I Can see why it is rebuilding so much on the next run. Mar 02 19:59:29 zeddii: something really odd is going on. Other trick is to stop it deleting the build directories and forcing it to reuse them Mar 02 20:00:21 I hacked out the removes (and the subsequent git init, git add) earlier. I took that out for these runs since sstate is no longer under that build-st directory. Mar 02 20:00:32 i'll revisit that tomorrow. Mar 02 20:00:49 watching the process list, I'm seeing a lot being built, but need to expose more output to know why Mar 02 20:01:23 zeddii: did you catch http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oeqa/selftest/cases/reproducible.py#n221 Mar 02 20:01:34 * zeddii see's a zillion Parser- right now. Mar 02 20:02:14 yah. that's what I had hacked out. Mar 02 20:02:34 combined with -K you should be good then :/ Mar 02 20:03:09 that's what I thought. But I did take it out for this run. I'll start another with it back in again later, I want this to coplete (I see it just went to reproducibleB) Mar 02 20:03:28 zeddii: sorry its being a pain :( Mar 02 20:03:40 it's ok. it's good for me to understand this better Mar 02 20:04:07 I see lots of -native and patching running on dependencies right now. so clearly, lots is going on. Mar 02 20:04:28 zeddii: perf will be easy when you get the environment setup right? :) Mar 02 20:04:50 I have an idea of what to do, It's pretty clear where it is grabbing some paths. as a start anyway. Mar 02 20:05:00 zeddii: for now, grep on the binaries and seeing build paths will give you a pretty good indication there is a problem FWIW Mar 02 20:05:02 I can of course just do some builds and check it msyelf Mar 02 20:05:30 yah. that's my plan for tomorrow, assuming I can't get the full test to behave. Mar 02 20:05:49 zeddii: we can throw a single reproducible build at it on the autobuilder too FWIW Mar 02 20:06:12 zeddii: I did that to confirm/deny my work in a few cases Mar 02 20:06:42 takes about four hours Mar 02 20:07:10 yah. I'll switch to something a bit more manual tomorrow, and then loop back to the oeselftest Mar 02 20:08:50 I didn't read the beginning of your discussion, but few minutes ago I've compared all signatures of core-image-minimal (with openembedded-core/scripts/sstate-diff-machines.sh --machines="qemux86 qemux86copy qemuarm" --targets="core-image-minimal" --tmpdir=tmp-glibc) and the TOPDIR path is only affecting do_rootfs_wicenv and up (for qemux86*) for me, so it shouldn't rebuild much after changing build directory Mar 02 20:15:07 and from world only meta-ide-support.do_populate_ide_support depends on TOPDIR: Mar 02 20:15:09 bitbake-diffsigs tmp-glibc/sstate-diff/1614715808/qemux86/core2-32-oe-linux/meta-ide-support/1.0-r3.do_populate_ide_support.sigdata.b1071cd89a5d590abdfdf0f05da4e2a111fe68ee3f49966dd96c7b53ffa281d1 ../oe-core/tmp-glibc/sstate-diff/1 Mar 02 20:15:13 614715799/qemux86/core2-32-oe-linux/meta-ide-support/1.0-r3.do_populate_ide_support.sigdata.69e874f2ac4b78223cb9ac3f045a6306cb3dd828e92bd48437d70b4c3f7674c2 Mar 02 20:15:16 NOTE: Starting bitbake server... Mar 02 20:15:18 basehash changed from c4758c5f5a5b2ef469082a5dcb60969a4ad4ac29a634836312d770882fdf9f6c to fc3c2d8c4c7e455fe3df56dc56913daadbc4ffe6aa97e49c5d473c2ecb1094ad Mar 02 20:15:21 Variable TOPDIR value changed from '/OE/build/oe-core2' to '/OE/build/oe-core' Mar 02 20:18:38 and do_rootfs_wicenv difference is caused by WICVARS depending on BBLAYERS Mar 02 20:22:11 JaMa: it really shouldn't be depending on that :( Mar 02 20:22:31 JaMa: we should perhaps poison it in the selftests to test that Mar 02 20:26:37 some more grub fun: https://www.debian.org/security/2021-GRUB-UEFI-SecureBoot/ Mar 02 20:30:40 JaMa: ok sounds good, i just see the patch in the ML Mar 02 20:32:45 * RP notes that ltp did pass the repro tests this time, yay Mar 02 21:54:28 RP: whats the debug flag for pseudo again ? Mar 02 21:57:57 @dl9pf: should I get worried when I see pseudo and debug flags in one sentence from you ? :) Mar 02 21:58:13 "export PSEUDO_DEBUG = "nfoPcvdDyerpswikVx" to the recipe" Mar 02 21:58:36 RobertBerger: depends on the level of booze Mar 02 21:59:30 @dl9pf: mine is still in the "green" range :) Mar 02 22:00:30 i'm still trying to get my mind firmly wrapped around what a BSP provides. Mar 02 22:00:56 vdl informed me a few days ago: "14:07 yates: a BSP usually provides all necessary low level Mar 02 22:00:56 software to boot a device. In the Yocto world, a BSP Mar 02 22:00:56 layer usually contains the machine definition including Mar 02 22:00:56 its architecture, the preferred bootloader and kernel, Mar 02 22:00:56 eventually kernel patches, etc. Then with the BSP layer Mar 02 22:00:56 for your board (e.g. meta-raspberrypi), you should be Mar 02 22:00:57 able to have a working environment by building a Mar 02 22:00:57 combination of e.g. the "raspberrypi" machine, the "core-image-minimal" image and any distro (e.g. "poky"). Mar 02 22:01:01 oh sorry Mar 02 22:01:22 vdl informed me a few days ago: "14:07 yates: a BSP usually provides all necessary low level software to boot a device. In the Yocto world, a BSP layer usually contains the machine definition including its architecture, the preferred bootloader and kernel, eventually kernel patches, etc. Then with the BSP layer for your board (e.g. meta-raspberrypi), you should be able to have a working environment by building Mar 02 22:01:22 a combination of e.g. the "raspberrypi" machine, the "core-image-minimal" image and any distro (e.g. "poky"). Mar 02 22:01:32 but... Mar 02 22:01:51 where does binutils fit in? does the BSP include the binutils port? Mar 02 22:02:33 and doesn't yocto provide both native- and cross-sdk (assembler, linker, compilers, etc)? Mar 02 22:02:46 how is this accomplished? Mar 02 22:04:10 what is a good reference bsp layer i can copy over and modify for my specific board? Mar 02 22:14:23 yates: i like meta-freescale a lot Mar 02 22:15:38 * alimon starting to do some swating for today builds ... abelloni RP Mar 02 22:23:24 yates: there can be some exceptions to what goes into a machine definition, distro configuration or image recipe. It can depend on your use case. But there are best practices though. Mar 02 22:23:53 JPEW: would you believe I've found a really really stupid bug in the logging code :/ Mar 02 22:24:10 alimon: I'm kind of around atm Mar 02 22:26:47 JPEW, sakoman: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=a8f95a3b6128d0fd0f3a2401fcd4c770f5a8d511 Mar 02 22:41:58 RP: Bah, ha, ha Mar 02 22:45:19 JPEW: I did have to sit with a piece of paper to check I had that right but I think I do... Mar 02 22:49:42 RP: (for receipt) That code will make it drop any message with a lower logging level (severity) than bb.msg.loggerDefaultLogLevel. Mar 02 22:50:03 RP: FWIW, I always have to look up if severity is ascending or descending Mar 02 22:54:20 Will 'do_compile[nostamp] = "1"' in a recipe be enough to invalidate the sstate cache? Or how will setscene task react when using the nostamp on for example do_compile? Mar 02 23:51:38 it will never fetch from sstate Mar 02 23:51:41 it will always rebuild Mar 02 23:51:45 every time you build Mar 02 23:51:51 you most likely don't want that Mar 03 00:55:58 hi all! may I ask a platform-specific (iMX8MM) question here? Mar 03 01:00:23 Just ask, don't ask if you can ask :) Mar 03 01:00:40 I have trouble building linux-fslc-imx_5.4 (yocto) to use imx8mm's IPU to capture stream from adv7280 video converter Mar 03 01:00:58 there are errors like: Mar 03 01:01:00 kernel-source/drivers/mxc/ipu3/ipu_device.c:47:10: fatal error: asm/outercache.h: No such file or directory Mar 03 01:01:33 I wonder if that part is maintained Mar 03 02:13:11 doesn't yocto provide both native- and cross-sdk (assembler, linker, compilers, etc)? Mar 03 02:13:22 the (e)SDK? Mar 03 02:13:40 derRichard: thanks for the recommendation! Mar 03 02:21:36 what does this have to do with yocto? http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/log/arch Mar 03 02:22:35 rburton: do you have any thoughts on the native/cross sdk? Mar 03 02:23:49 it seems logical that these actions must build the binutils and also pull in the necessary libraries (glibc e.g.) depending on the target architecture. true> Mar 03 02:23:52 ? Mar 03 02:28:21 RP? Mar 03 02:31:00 what does this have to do with yocto? http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-dev/log/arch Mar 03 02:31:21 is it merely a "view" into the linux kernel repo? **** ENDING LOGGING AT Wed Mar 03 03:00:25 2021