01:07 <jwinarsk> Using: `SRC_URI = "git://github.com/toyota-connected/tcna-packages.git;lfs=1;branch=main;protocol=https"`. It should just work. I also tried replacing the use of the filter "lfs" in the three .gitattributes files; no impact. Running `git lfs track` on sandbox of repo on build host produces the correct output.

01:07 <jwinarsk> JaMa: not sure what's going on. If I pass `GIT_LFS_SKIP_SMUDGE=1`, it ends up with the git placeholder contents for each file; does not implicitly fetch the LFS objects. This is with the lfs filter definition removed from global or local removed. Locally it fetches all the LFS objects with a clone. The git fetcher seems to be skipping LFS, and then trying to resolve the LFS objects in do_patch; fails due to network disabled.

06:16 <JJalling> Hello, does anybody have experience with building Zephyr projects in Yocto?

08:18 <Guest82> Would i able to use Toaster? Is it up to date?

08:57 <michaelo_> \

08:57 <michaelo_> oops, sorry for the noise

15:13 <khem> jonmason: I sent the patch while you were sleeping :). I have tested them together, it seems to solve the problem at hand

15:14 <khem> no random SIGILLs seen while running qtwenengine

15:15 <khem> built with clang running on rpi4-64

15:16 <jonmason> khem: I saw the patches this morning, thanks

15:16 <jonmason> now we wait for it to be pulled in ;-)

15:17 <khem> I solved the issues we know, one could argue that all armv8a cores should have this option but we should add when there is some SOC using OE and requiring it

15:18 <jonmason> I agree with RP's point from yesterday that we should wait for people to want it, instead of going through combination hell unnecessarily

15:19 <khem> SOC in Pi5 has h/w AES so we are good with that

15:19 <khem> BCM2712

15:20 <jonmason> I have a few ARMv8 and ARMv9 tunes in meta-arm that I'm in the process of testing out, and trying to decide what is the best way to do some things

15:20 <jonmason> like, should we have tune features in the tunes for if people want to detect that those are there

15:21 <jonmason> my problem is that fvp base doesn't enable sve, and I could detect that as a tune feature to turn it on

15:21 <khem> we should try to stick to a define -mcpu option perhaps and call out exceptions if needed

15:22 <khem> isn;t SVE optional on ARMv8.2+ ?

15:22 <khem> and perhaps present in ARMv8.4-A+

15:24 <khem> Cortex-A76 is the CPU in pi5 hmm so it does not have SVE

15:28 <khem> as I can see, SVE/SVE2 is always optional feature

15:29 <khem> I was thinking that it might have become part of 'required' list in ARMv9 but seems no

15:48 <jonmason> gcc was saying that it is a default option for armv9

15:48 <jonmason> i didn't check to see if it is enabled as part of the arch, as I got preempted for something else

15:56 <khem> jonmason:Cortex-A510, A710, A715, theya re armv9 but seems to not have SVE

15:58 <khem> Cortex‑X series and Neoverse seems to have it

15:59 <jonmason> khem: thanks

16:00 <khem> oh and some have just SVE2 and some have both SVE/SVE2

16:01 <khem> I am hoping that using correct -mcpu should have taken care of it

16:01 <jonmason> I was changing fvp-base machine to allow for any supported arch version through setting the version major/minor

16:02 <khem> thats aspirational :)

16:02 <jonmason> since that is the generic, mcpu won't work for me

16:02 <jonmason> actually, it's working

16:03 <jonmason> 8.9 has a package not building, and everything through 9.4 is happy (with SVE and SVE2 enabled in the machine)

16:03 <khem> sounds cool. Do you use -march=blah+sve ?

16:04 <jonmason> I was not specifying sve, just taking what gcc has as the default

16:04 <jonmason> thus the rabbit hole

16:06 <jonmason> I was looking at gcc/config/aarch64/aarch64-arches.def for what is enabled by default

16:07 <jonmason> AARCH64_ARCH("armv9-a", generic_armv9_a, V9A , 9, (V8_5A, SVE2))

16:10 <jonmason> this is my ugly hack to get it working https://gitlab.com/jonmason00/meta-arm/-/commit/d2c5826017cb145e3c3933f5af88421261861ebc

16:27 <jwinarsk> any reason why Wayland backend has not been added to the glfw recipe? It'

16:27 <jwinarsk> It's been available for a couple of years

16:33 <fray> most likely because nobody has requested it

16:33 <fray> there is a ton of wayland stuff that hasn't been enabled because nobody has asked for it or submitted patched _AND_ test cases

17:34 <jwinarsk> fray: copy that. I'll submit a patch. Test cases beyond on device smoke tests? What's the criteria there, and is Wayland (mutter/weston/wlr) available in CI for testing? What's the bar we are trying to establish?

17:35 <fray> we need to know how to enable it, test it and expected results. Even better if the test case is automated as a ptest or something that works with the qemu that is already run

17:43 <jwinarsk> fray: copy that. I think a baseline Wayland build would be to remove x11 from `DISTRO_FEATURES`, build `core-image-weston`. If that boots and shows the weston desktop, then confirm `WAYLAND_DISPLAY` and `XDG_RUNTIME_DIR` are set as expected; seen some strangeness recently here in `master` using meta-rockchip. Once this is correct, it should work as expected. I'd be happy to contribute a baseline setup/test for

17:43 <jwinarsk> core-image-weston.

20:35 <derRichard> are you aware of the hidden ref in git.openembedded.org/meta-openembedded? cloning it with --mirror includes the ref "refs/remotes/rw/HEAD"

20:35 <derRichard> this makes it impossible to mirror it with e.g. gitlab since it refuses hidden refs

20:55 <derRichard> hm, the more i think about it, git clone --bare should also do it