02:46 <Axman6> I've asked in #oe too, but things seems a little more active here:

02:46 <Axman6> I've been going around and around in circles trying to find an answer to this but can't seem to find the right terms to search for. I'm trying to compile jemalloc with a specific configure flag (--enable-prof) but can't find where I can set that for aone off build. I'm trying to debug a memory leak on our system, so don't need this to be park of our normal build, I'm just trying to produce an ipk i can scp over and use. I am able to build jemalloc with bitbake j

02:46 <Axman6> emalloc, but it doesn't have that flag enabled. I've seen mention of OVERRIDES, but I have no idea where that's supposed to go

03:03 <sunkist> Axman6: have you use devtool modify a temporary copy of the recipe?

04:02 <sunkist> Axman6: once your recipe is checked out, you can make temporary changes to the Makefile (or the source) to get the debugging you need, then reset the recipe to eliminate the changes (or even generate a patch that you can add to your recipe.)

04:57 <Axman6> sunkist: I haven't tried that (or even really seen references to that while searching), I'll see what I can find

05:24 <Axman6> For anyone interested, khem gave the exact answer I was looking for in #oe: "in local.conf add EXTRA_OECONF:append:pn-jemalloc = " --enable-prof""

06:11 <sunkist> Axman6: devtool modify is lifechanging, recommend trying it and writing it down in your notebook. I used yocto for years without it and wish I hadn't

06:18 <Axman6> yeah it looks pretty useful, reminds me of nix develop, which drops you into an encironment which matches how nix builds your package, so you can run its build phases one by one and see the results

09:44 <vjh> Hi!

09:44 <vjh> Are you aware if there are any methods to avoid leaking the native sysroot used when building SDKs/toolchains?

09:44 <vjh> For example (sourced the SDK and grepped for secrets):

09:44 <vjh> ```

09:44 <vjh> -march=x86-64

09:44 <vjh> --sysroot=/home/runner/<secret_codewords>/work/x86_64-nativesdk-codexsdk-linux/nativesdk-libtool/2.4.7/recipe-sysroot"

09:44 <vjh> ```

09:44 <vjh> Here --sysroot contains sensitive information. I guess configuring cache per-product is one solution,

11:33 <mcfrisk> still seeing this dependency loop error when building core-image-base https://pastebin.com/raw/22kV5qmX . built core-image-initramfs-boot separately without errors and now can also build core-image-base. I find this very odd. Can't pinpoint what exactly is causing this..

15:14 <rburton> tlwoerner: was the fix you tested passing --auto-features=disabled to systemd-native's configure?

18:26 <khem> RP: I have removed the toolchain selection bits for now, I will do that in phase2 if inherit_defer works please take a look at kraj/clang-merge-2 branch and see if you have any outright comments

18:27 <khem> I have few tweaks that I will merge and perhaps post it for review soon

19:00 <rburton> mcfrisk: if you get a moment, reviewing and testing poky-contrib:ross/getty would be great. restores behaviour, improves kv260. we can make genericarm64 support finding the console under sysv post-release.

19:02 <rburton> RP: posted getty patches. tested _locally_ only right now, fired https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/1438 now with what i hope is the right branch matrix! (there's no walnascar selector yet)

19:02 <tlwoerner> rburton: passing --auto-features=disabled to systemd-systemctl-native's configure fixed the issue for me

19:02 <rburton> tlwoerner: excellent. thats the correct fix, imho.

19:03 <tlwoerner> rburton: i.e. it didn't need the "sufficiently big hammer"

19:03 <tlwoerner> okay, i'll send a patch asap

19:04 <rburton> RP: i got the branches wrong maybe https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/1439

20:39 <RP> rburton: that does look like the wrong helper branch

22:16 <khem> Has anyone noticed problem when building binutils for target on systems with same version of binutils where it installed libbfd-2.44.soT into target and not libbfd-2.44.so

22:17 <khem> these libs are different in ELF header and it becomes clear when building it for musl because .soT have glibc ldso encoded in its ELF header