<dvergatal>
LetoThe2nd: ok on docker it is working but not on podman :/
<LetoThe2nd>
dvergatal: well then you know where to go digging
<dvergatal>
for sure but i dunno what can cause it in podman :|
vthor has joined #yocto
vthor has quit [Changing host]
vthor has joined #yocto
paulg has joined #yocto
RyanEatmon has quit [Remote host closed the connection]
RyanEatmon has joined #yocto
jmiehe has joined #yocto
florian has quit [Quit: Ex-Chat]
florian_kc has quit [Ping timeout: 255 seconds]
jmiehe has quit [Remote host closed the connection]
pidge_ has joined #yocto
pidge has quit [Ping timeout: 252 seconds]
Xagen has quit [Ping timeout: 248 seconds]
Xagen has joined #yocto
goliath has quit [Quit: SIGSEGV]
frieder has quit [Remote host closed the connection]
<jwinarsk>
question about using core vs meta-clang. Prior I was using `dynamic-layers/clang-layer`. How do I switch between gcc, core clang, and meta-clang? I haven't seen this documented anywhere; likely just missed it.
<mrc3>
hey, sakoman! do we have tags for kirkstone 4.0.29?
<sakoman>
mrc3: No, not until QA is complete and 4.0.29 is released
<mrc3>
sakoman, cool! thanks for confirming
savolla has quit [Ping timeout: 255 seconds]
savolla has joined #yocto
florian has quit [Ping timeout: 255 seconds]
Jones42 has quit [Ping timeout: 255 seconds]
florian has joined #yocto
chep has joined #yocto
leon-anavi has quit [Quit: Leaving]
<khem>
jwinarsk: yes, send a patch for libcxx recipe
<jwinarsk>
khem: copy that
<khem>
core to meta-clang migration is _almost_ there, there are few patches needed which are floating on mls
<khem>
hopefully in soon
jmiehe has joined #yocto
jmiehe has quit [Client Quit]
<khem>
one big wrench is for rpi4 where tunes need nocrypto otherwise meta-clang is just a simple addon now with zero recipes, only few classes to add clang-scan and some bbappends
<khem>
you might not need to put things in clang specific dynamic layers anymore
jwinarsk has quit [Server closed connection]
jwinarsk has joined #yocto
<jwinarsk>
that's great!
<jwinarsk>
I'm seeing `spirv-tools` get implicitly pulled in. I don't want the default version (old), as my stack has a custom version integrated (new). Looks like it's being included by default via `LLVM_TARGETS_TO_BUILD="AArch64;BPF;AMDGPU;NVPTX;SPIRV"`
<fullstop>
I have one build tree which I build for different machines with the same image / recipe. Let's say hwrev1 and hwrev2 -- this is mostly for kernel config differences, but usually device tree. If I change a resource for hwrev1 whenever I build for hwrev2 yocto rebuilds the kernel, even though none of the files for that variant have not changed.
<fullstop>
Is there a way to avoid this?
alperak has quit [Quit: Connection closed for inactivity]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jmd has quit [Remote host closed the connection]
Xagen has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
goliath has quit [Quit: SIGSEGV]
Xagen has joined #yocto
pita has joined #yocto
bq has quit [Server closed connection]
bq has joined #yocto
Kubu_work has quit [Ping timeout: 252 seconds]
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
druppy has joined #yocto
Wouter0100 has quit [Ping timeout: 248 seconds]
Wouter0100 has joined #yocto
druppy has quit [Ping timeout: 252 seconds]
Xagen has joined #yocto
<jwinarsk>
khem: What do I need to enable lld in core? `| aarch64-poky-linux-clang++: error: invalid linker name in argument '-fuse-ld=lld'`
<jwinarsk>
Adding `lld-native` as a build dependency resolved it.