08:19 <d-fens_> hi guys, i want to set BUILDHISTORY_PUSH_REPO only if my environment has a BH_URL env set. in my conf/distro/include/buildhistory-ci.inc the is this : INHERIT += "buildhistory" python () { import os, bb \ url = os.getenv("BH_URL") \ if url: \ d.setVar("BUILDHISTORY_PUSH_REPO", url) but this has no effect i guess, any hint?

13:03 <tgamblin> I'm working on a project where I'm incorporating a layer that does PACKAGECONFIG:remove = "networkd" for the systemd recipe, but I am interested in adding it back with my own layer which has a higher priority. What is the most appropriate way to do that? Another .bbappend?

13:04 <rburton> tgamblin: you can't add back a remove

13:04 <rburton> tgamblin: tell that layer to stop being so dumb

13:04 <tgamblin> rburton: I thought so :(

13:06 <mcfrisk> tgamblin: BBMASK the bbappend away

13:07 <mcfrisk> (or BBMASK the whole layer and only enable what is really needed)

13:07 <rburton> assuming the append doesn't do anything else important, yeah

13:09 <tgamblin> mcfrisk: rburton: that should work - if needed I could always pluck some of what the masked bbappend does into ours

13:09 <tgamblin> thanks!

13:16 <litb> Hello folks!

19:09 <rburton> RP: khem: i can't build compiler-rt-native with master

19:09 <rburton> | -- Check for working CXX compiler: /work/ross/build/tmp/work/aarch64-linux/compiler-rt-native/20.1.7/recipe-sysroot-native/usr/bin/clang++ - broken

19:09 <rburton> | /work/ross/build/tmp/hosttools/ld: cannot find -lstdc++: No such file or directory

19:21 <khem> rburton:whats your host ?

19:21 <khem> I wonder if you have same problem that we had on ubu24.04 builder on AB

19:22 <khem> where libgcc-devel from gcc15 is installed

19:22 <khem> but libstdc++-devel is not

19:22 <khem> or gcc-14 perhaps instead of gcc-15, its non-default version that is

19:31 <rburton> khem: ubuntu 24.04 :)

19:32 <rburton> khem i appear to have gcc 11 13 14 installed

19:37 <khem> having them is not a problem, having half installation of devel packages for runtime is

19:38 <khem> I hope you do not use emacs :) since thats the one caused the newer devel package to be installed for libgcc-devel

19:38 <khem> fix is to install both c/c++ devel packages for all the versions

19:38 <khem> if you need them

19:49 <rburton> i have libgcc-dev for 11 13 14 installed

19:50 <rburton> (i blame my debian colleague for this toolchain madness)

19:50 <rburton> ah but only libstdc++-dev for 13, which is the default

20:40 <RP> rburton: why didn't the new sanity test work?

21:17 <JaMa> khem: there is small issue with rust (and rust-llvm) when building with meta-clang, the bbappend there sets TOOLCHAIN_NATIVE to clang, so clang-native is inheritted (even for target builds) and target builds with gcc fail, because they don't recognize --rtlib=libgcc --unwindlib=libgcc when target CC is gcc-cross, I guess you're not seeing this because most builds with meta-clang will use clang also for target

21:17 <JaMa> builds

21:17 <JaMa> not sure what's the correct fix, should clang-native append LDFLAGS only for class-native?

21:19 <rburton> RP: i did a build in clean tree and libgcc-14-dev is installed and not libstdc++-14-dev which will break clang native compiles. Please remove one or install the other.

21:19 <RP> rburton: awesome, so the check does work :)

21:20 <RP> rburton: now you can hunt down who installed emacs :)

21:21 <JaMa> can we do the same check in clang-native build as well? for those people who install emacs after the TMPDIR was created and sanity checked?

21:22 <RP> JaMa: well, we could do the check on every build but I assumed most people would build on a clean TMPDIR periodically

21:22 <JaMa> I was thinking at compiler-rt-native:do_compile:prepend to show a meaningful error early when it happens

21:23 <JaMa> looks like rburton's build was dirty :)

21:24 <RP> If someone wants to add more checks/tests I'll probably not object...

21:24 <JaMa> FWIW I don't delete TMPDIRs very often

21:25 <JaMa> in local builds, on jenkins they always start from clean TMPDIR

21:25 <RP> JaMa: neither do I but we're relatively unusual. We could just bump the version on the sanity tests

21:25 <RP> (i.e. force a rerun)