07:41 <RP> hushmoney: "none" was what we had before INIT_MANAGER existed and poky was setup to work with that. We could switch it to sysvinit these days

07:41 <RP> hushmoney: the difference is some DISTRO_FEATUREs changes that poky has already

10:46 <Guest14> ERROR: Task (/home/bsh/poky/meta/recipes-devtools/gcc/gcc_11.2.bb:do_compile) failed with exit code '1'

10:47 <Guest14> any reccomendation? i got same error for mesa

10:47 <Guest14> for core-image-sato

10:50 <qrsBRWNanyall[m]> Got anymore output

10:50 <qrsBRWNanyall[m]> ?

10:50 <qrsBRWNanyall[m]> That basically just says it failed to compile

10:51 <Guest14> yeah i can paste all output, it is really long, thousands of line

10:52 <qrsBRWNanyall[m]> Well either use a paste in service or pick out the relevant parts

10:52 <qrsBRWNanyall[m]> Pastebin not "paste in" :)

10:59 <Guest14> i find a log but it doesnt look new. i run bitbake again and writing logs to a file, i ll paste output in 10 mins to some paste site:)

11:13 <Guest14> https://paste.ofcode.org/327VPGiKe6T2Uqd5f8YjufC

11:26 <Guest14> any idea?

11:48 <Saur[m]> Guest14: That looks odd. Worth noting is that both `mesa-native` and `gcc` are built using the host compiler. What is its version, i.e., what does `gcc --version` return?

11:51 <Guest14> Saur[m] gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

11:51 <Guest14> Copyright (C) 2019 Free Software Foundation, Inc.

11:51 <Guest14> This is free software; see the source for copying conditions. There is NO

11:51 <Guest14> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

12:01 <Saur[m]> Guest14: Nothing odd there. Unfortunately that's about my extent of compiler/linker related knowledge. You will probably have to wait for a better answer until someone who's knows more about that part comes online (which may be later today, given that it is still very early in the US, or tomorrow, given that it is Sunday today).

12:03 <RP> Guest14: that is looking a bit like gcc 9 from your host can't handle the code in mesa 22 :/

12:04 <Saur[m]> Well, mesa-native is one thing, but it not being able to build gcc.

12:05 <Guest14> okay guys thanks:(

12:06 <RP> Saur is right, gcc target shouldn't fail like that. There is something odd going on there

12:06 <RP> Guest14: which host OS/Distro is that with?

12:07 <Guest14> @RP Ubuntu 20.04.4 LTS

12:08 <RP> Guest14: which is odd as I build on that myself

12:09 <Guest14> i exactly followed https://docs.yoctoproject.org/brief-yoctoprojectqs/index.html the quick start guide

12:09 <Guest14> want to go deeper but dont able to got my first image:(

12:10 <Saur[m]> Is it a new Ubuntu installation, or have you used it for other thing before?

12:10 <RP> Guest14: have you made changes to that OS in some way?

12:11 <RP> Guest14: we have a 20.04 instance in our autobuilder running builds similar to the quickstart so this is something we test

12:13 <Guest14> its not new installation, im using that distro for months and i didnt change any system files.

12:14 <Guest14> and i tried lowering thread numbers. when i did it i just got error for gcc, not for mesa

12:14 <Guest14> #BB_NUMBER_THREADS = "1"

12:14 <Guest14> #PARALLEL_MAKE = "-j 1"

12:14 <Guest14> in local.conf

12:15 <Guest14> but without these lines, i got mesa and gcc error. i tried it because i read something maybe issue is the bootleneck of ram

13:58 <RP> Guest14: how much memory has your system got?

13:58 <Guest14> 8gb

13:59 <RP> Guest14: That is probably on the low side so you will have to limit the parallelism

13:59 <Guest14> i limited but still failed

14:00 <Saur[m]> Even if it is on the low side, it shouldn't cause link errors like those though.

14:05 <Guest14> and i got 0% match for sstate, what can be cause that? im thinking to delete all files and start freshly but it is taking too much time and it cant use sstate

17:37 <amahnui[m]> <Guest14> "and i got 0% match for sstate..." <- Hello @guest14 please which command did you run if I may ask?

19:34 <hushmoney> my hw vendor provided a bsp layer which requires me to set MACHINE="foo" and BOARD="bar" in my local.conf to build for their eval board. i'd like to write my own baz-image.bb, and i would like to include some recipes only when building for the eval board (when BOARD == "foo"). what is the right way to go about this?

19:36 <hushmoney> put eval-board-only recipes in their own package group and conditionally require the packagegroup from the image, or have the conditional logic in the packagegroup that contains the rest of my software? also what is the syntax for this condition? i'm confused by bitbake's XYZ_SUCH_AND_SO_append stuff