06:37 <alessioigor> Good morning

07:02 <mckoan> good morning alessioigor, all

07:21 <alessioigor> Does someone have the patch and/or the bbappend to fix CVE-2024-6387?

07:29 <mckoan> alessioigor: https://patchwork.yoctoproject.org/project/oe-core/patch/20240704105617.130735-1-jose.quaresma@foundries.io/

07:31 <alessioigor> mckoan: Thanks Marco!

14:37 <adrianp> hello, how can I add a .desktop shortcut (for eg wireshark) with yocto, on xfce user Desktop?

14:38 <adrianp> and also avoid `Untrusted application launcher` warning

14:59 <rburton> wireshark should be installing a .desktop file on its own

15:00 <adrianp> it is installing it in /usr/share/applications but not on Desktop

15:01 <rburton> actually on the desktop? no idea, ask the xfce channel

15:01 <adrianp> i was thinking about adding a bbappend for wireshark to copy .desktop to /etc/xdg/Desktop/

15:02 <adrianp> yes, to /home/<user>/Desktop to have it visible as a shortcut on the actual desktop :)

15:04 <marex> maybe some do_install:append() { ln -s ... } and FILES += ... ?

15:04 <rburton> yes

15:05 <rburton> assuming xfce reads /etc/xdg/Desktop

15:06 <marex> rburton: dunno, I disabled desktop icons on my xfce setups

15:34 <ldywicki> Out of curiosity, did anyone ever succeed to build bootable BSD image with yocto?

15:34 <ldywicki> [or rather bitbake]

15:48 <rburton> ldywicki: nobody has tried that i'm aware of

15:48 <rburton> is bsd happy to cross-build from a linux host?

15:49 <rburton> (i know a number of core linux pieces are very unhappy to build on a bsd host)

15:49 <rburton> if you're happy with mandating on-bsd then in theory its just a matter of writing all the recipes...

16:25 <vvn> hi there -- have you ever used --cache-from and --cache-to to build with docker and reuse DL_DIR/SSTATE_DIR?

16:32 <rburton> vvn: why not just bind-mount the cache into the container?

16:34 <rburton> are those options not for building docker _images_?

16:36 <vvn> I just realized that, I think they are options for layer caching, not volumes backend...

16:42 <rburton> you can just mount your sstate into the docker

16:44 <rburton> kas-container uses --volume on dldir and sstate dir, just works

16:44 <ldywicki> @rburton I have no clue about BSD, very little about linux. I've asked cause I've found that Beckgoff offers industrial PCs which can work with Windows or BSD. Since cross platform compilation is a nightmare to me, I wished to piggy back on someone else work. Turns out I'd be one doing it. With my knowledge of make etc. I will simply skip attempt and assume "no". If I will get a chance to play with such device I'll try to boot it with UEFI/linux and

16:44 <ldywicki> see what works and what not. :-)

16:45 <rburton> if its x86 then you probably just need to fiddle a kernel and you're good

16:54 <ldywicki> most of these devices are based on Intel, so I suppose its going to fly with uefi, its just "unsupported" configuration by them.

17:10 <vvn> rburton: I was worried about the performance while bind-mounting an S3 bucket for sstate into your build host

18:08 <vvn> e.g. s3fs

18:13 <vvn> I wouldn't be surprised that using a fuse-based fs for downloads or especially sstate isn't a good idea

20:05 <rburton> vvn: thats a terrible idea

20:06 <rburton> if you _have_ to use s3 then use that as a read only sstate mirror over http, and s3sync back to it on success

20:07 <rburton> our gitlab CI is all docker containers running the kas container in AWS, we use an EFS mount for sstate/dldir instead of messing around with S3

20:31 <RP> jonmason, rburton: https://autobuilder.yoctoproject.org/typhoon/#/builders/113/builds/5730/steps/23/logs/stdio - not sure what happened there? :/

20:35 <rburton> no idea why it decided to enter emergency mode, and the broken locking in qemu makes it even more fun!

20:37 <jonmason> let me try it locally and see if it'll break

20:40 <RP> jonmason: this was with current master-next, not sure what to blame :/

20:40 <jonmason> I was sort of excited to tell you we had a fix, but different problem. so now I'm just sad

20:41 <RP> https://autobuilder.yoctoproject.org/typhoon/#/builders/165/builds/583 in genericarm64 is also suboptimal :/

20:41 <rburton> sbsa-ref is mostly qemuarm64 so if qemu works sbsa-ref should work

20:41 <rburton> hm ok that's definitely not us

20:41 <rburton> did that include adrians series?

20:42 <jonmason> running sanity check now on sbsa-ref and poky altcfg

20:42 <rburton> i'll fire genericarm64 against master-next and verify if we found a bug in adrian's patches

20:49 <RP> rburton: it did, so it could be that

20:56 <RP> so, systemd patches - failures, util-linux patches - failures and probably issues with the fitimage series. I'll drop them all and retry

21:40 <jonmason> sbsa-ref and poky-altcfg on poky master passes my CI

21:41 <jonmason> pushing that to be part of our CI going forward shortly

22:09 <RP> jonmason: thanks, that confirms it was something in -next, probably Adrian's series but I guess I need to confirm that