08:41 <Tyaku> Hello, We have some issue with the new RZG2UL BSP from renesas (not officialy out). I come here to see if there is an easy way to bypass the problem without modifing their sources.

08:41 <Tyaku> What happens:

08:42 <Tyaku> - In their new BSP, they change how they treat the machines specific customisation.

08:42 <Tyaku> - Now they have things like this in many receipe: "include xxxx/xxx-${MACHINE}-xxx.yyy"

08:42 <Tyaku> The problem:

08:42 <Tyaku> - In our side the MACHINE names are not the same and there is no "xxx-${MACHINE}-xxx.yyy" files that match our machine in their directories

08:42 <Tyaku> - If we put the file "xxx-${MACHINE}-xxx.yyy" in our layer, during the build it's not going to check for the file in our layer. It only check if the file exist in their layers

08:43 <Tyaku> Do you have any ideas ?

08:43 <Tyaku> -> My first idea was: Add a BBMASK in local.conf to "mask" their "linux-renesas.bbappend" that only do "include xxx-${MACHINE}-xxx.yyy". But as they use this mecanism in many .bbappend now, it's not viable.

13:40 <fullstop> If I have a package which relies on yaml-cpp, is there any reason why yaml-cpp-dev wouldn't be included in the generated sdk?

13:52 <rburton> fullstop: if its actually in your image that the sdk is generated from, and the -dev package actually exists, no

13:53 <fullstop> Is it super-duper smart and can tell that I am not actually linking to yaml-cpp yet?

15:02 <vmeson> khem: RP thinks that this issue has been resolved, do you agree? https://bugzilla.yoctoproject.org/show_bug.cgi?id=15831

16:22 <rfs613> i'm trying to debug the do_configure step of kernel build. Locally it behaves as I expect, but in CI am getting a different result. Would like to see log.do_configure from the CI build, but unfortuantely it gets wiped out immediately. Is there a way to get bitbake to write log.do_configure to stdout (for a specific recipe) so that it gets captured in the CI build log?

16:25 <rburton> rfs613: why don't you get CI to preserve the logs?

16:25 <rfs613> rburton: because i have no idea how to make changes to the CI ... ;-)

16:26 <rburton> lol

16:26 <rburton> use bbplain to debug and you'll get output on the console instead of buried in the logs

16:27 <rburton> eg bbplain HELLO will appear in the terminal (or CI log) where bitbake was running

16:27 <rburton> (see also, bbwarn bbdebug bberror bbfatal)

16:29 <rfs613> yep, i guess i'll have to cook somethign up

17:12 <agodard> I'm unclear about the PREFERRED_TOOLCHAIN* variables. For now, only PREFERRED_TOOLCHAIN_TARGET can be changed to 'clang', right?

17:42 <rfs613> rburton: this seems to do the trick, thanks.... do_configure:append() { cat ../temp/log.do_configure | while read line ; do bbplain "$line"; done }

17:53 <rfs613> and I found the configuration problem. Yay!

18:32 <khem> vmeson: I think yes,I have not seen this failures on CI systems for some weeks now

18:33 <khem> agodard: only TOOLCHAIN and TOOLCHAIN_NATIVE should be tweaked by user ideally

18:34 <khem> distro folks can tweak PREFERRED_TOOLCHAIN_TARGET PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK

18:34 <khem> defaults are all set to 'gcc'

18:49 <vmeson> khem: super. resolved -> works for me.