00:20 <rfs613> vmeson: thanks for the suggestion (of commenting out patches), indeed that is workable solution for me

05:34 <mcfrisk> RP: qemu boot did not happen with KVM? qemu-system-aarch64 was given -enable-kvm but kernel did not detect KVM hypervisor services. Could this build machine have issues with KVM setup? Or it's a race condition in the running kernel inside qemu

07:44 <Tyaku> I found what was the problem with my U-boot receipe, insalling /usr/share/u-boot.dtb that was not acessible from recipes-sysroot of another recipe (linux-renesas) that depends on it. The variable SYSROOT_DIRS was good in linux-renesas receipe but not on U-Boot ! for some unknown reason, it was only set to "/boot" on U-Boot receipe. If I do 'SYSROOT_DIRS:append = " ${datadir}"' -> it's OK, if I do

07:44 <Tyaku> 'SYSROOT_DIRS += " ${datadir}" -> it's nok

07:45 <Tyaku> with bitbake -e it seems that the original SYSROOT_DIRS are overrite by u-boot.inc. What they do in u-boot.inc is : SYSROOT_DIRS_rzg2l += "/boot"

07:51 <RP> mcfrisk: That is what appeared to happen to me. I guess we need to work out if it can use KVM or not...

08:15 <mcfrisk> RP: I can disable that test. The boot under KVM was setup and working correctly. Something in SMCCC thing did not work, kernel logs are partial. Which kernel is this machine running, Ubuntu 20.04 it OS at least? Are there different kernels and/or HW on the aarch64 build machines?

08:22 <mcfrisk> RP: we think it's an issue between the host and guest kernels. would be nice to know the build host kernel version. I will send a patch asap

08:45 <mckoan> Anyone has experience with Azure CLI with Yocto? In particular, is there any layer providing the 'az' command?

08:46 <mckoan> Looks like meta-iot-cloud nor meta-iotedge are providing 'az' CLI

09:28 <RP> mcfrisk: it is running "Linux version 5.4.0-216-generic (buildd@bos03-arm64-091) (gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.2)) #236-Ubuntu SMP Fri Apr 11 19:55:34 UTC 2025"

09:28 <RP> PRETTY_NAME="Ubuntu 20.04.6 LTS" from os-release

09:40 <mcfrisk> RP: thanks, I suspected that an older kernel. that could be the reason for the failure. Do all of the aarch64 build machines run this distro and kernel version?

09:47 <RP> mcfrisk: no, we have four different setups. https://autobuilder.yoctoproject.org/valkyrie/#/workers and grep for arm - 2x 20.04, 2x 22.04 and 2x 2404 and 1x 2410

09:47 <RP> mcfrisk: we will probably drop the 20.04 soon

09:48 <RP> mcfrisk: in fact it looks like that are paused pending rebuilding with something newer

09:51 <mcfrisk> RP: I presume my u-boot KVM test was passing on newer machines but failing only on 20.04 then

10:00 <RP> mcfrisk: Hopefully. I just saw the failure last night and wanted to flag it for investigation. If we think it is just 20.04, we can monitor things and check everything else is ok

10:00 <RP> mcfrisk: this is one failure amongst many and I can only work on so many at a time :/

10:11 <RP> mcfrisk: thanks for looking into it. I'm relieved that we understand the probably cause and by luck, we're decommissioning those workers anyway

10:17 <mcfrisk> RP: yes, I see your pain with so many different failures and will help where ever I can, especially if my changes trigger these. understandint autobuilder infra and limitations with tests is a bit harder, getting there I hope.

10:18 <RP> mcfrisk: definitely, I try and help with that info! Thanks

10:18 <mcfrisk> patch to disable this SMCCC KVM check is on the list since this is just an extra validation check that boot happened with KVM. I don't know how else to check if qemu guest runs with KVM on aarch64 :/

11:03 <RP> mcfrisk: if that works everywhere else, I'm tempted to leave it as it is a nice check

11:23 <qschulz> something's messed up with the new kernel-fit-image class I believe?

11:23 <qschulz> https://paste.debian.net/1378470/

11:24 <qschulz> meta-rockchip master + sed -i s/kernel-fitimage/kernel-fit-image/ conf/machine/**/*.inc

11:24 <qschulz> poky master

11:27 <qschulz> mmmm the sed is probably NOT what I should be doing anyway, will read a bit more

11:29 <qschulz> would be nice to have an entry in the migration manual for that :)

14:15 <RP> khem: I've put some toolchain selection patches in master-next. Curious to see what you think. They've their own challenges

15:50 <qschulz> tlwoerner: I'm wondering if we shouldn't move panfrost to the gallium-llvm drivers like asahi...

15:50 <qschulz> it does bring A LOT more dependencies, but it seems to be the right thing to do according to mesa's docs

15:50 <qschulz> so we would need panfrost libclc gallium-llvm in PACKAGECONFIG for example

15:58 <khem> RP:yeah saw it with rebase this morning. Looks you will run into inherit last race as well

15:59 <RP> khem: not in the same way you did originally

16:04 <khem> yes this looks improvement

16:07 <khem> we will need to change inherit native to deferred inheirt and same for nativesk etc. wholesale, which is perhaps not a bad deal

16:07 <RP> we could make that "magic" with something like BB_DEFER_BBCLASSES = "native nativesdk"

16:08 <RP> what that event handler is doing is horrible too

16:28 <khem> yeah I think BB_DEFER_CLASSES would make it more implicit

16:28 <khem> would there be a reason to use them without deferred inherit

16:38 <RP> khem: they won't work without it

16:54 <RP> khem: I added BB_DEFER_BBCLASSES on master-next

17:05 <RP> khem: https://autobuilder.yoctoproject.org/valkyrie/#/builders/14/builds/1649 is fun :)

23:17 <khem> RP: master-next with BB_DEFER_BBCLASSES seems better, I will give it a spin with my CI