<eduter>
Hi community. I have been away for a while, hope you all are doing well.
<eduter>
I have a question, I am trying to figure out why the parallel jobs that bitbake is starting are not finishing if one job already showed a failure.
<eduter>
I am not using -k argument and I have not configured any recipe etc. to continue building ignoring errors. Does someone have a hint on where should I look at?
Xagen has joined #yocto
alessio has joined #yocto
alessio has quit [Client Quit]
labestia has joined #yocto
labestia has quit [Quit: Going offline, see ya! (www.adiirc.com)]
labestia has joined #yocto
labestia has quit [Quit: Going offline, see ya! (www.adiirc.com)]
savolla has quit [Quit: WeeChat 4.4.3]
savolla has joined #yocto
<vmeson>
eduter: welcome back. you might introduce a failure in a standard recipe build for poky only and compare what happens there with the problem you are seeing. It is an unexpected behaviour.
<vmeson>
eduter: is the failing job from a recipe in a public layer?
<Habbie>
yocto-based apparently
<eduter>
vmeson Thanks a lot for answering. The recipe failing is not yocto-based, but the other recipe that is taking its time to finish so bitbake can stop building due to the already detected failure, is part of the meta-rust layer and it is building the RUST compiler. This second task takes long time, and it would be great if it could just failed and
<eduter>
stopped if another task has already failed.
<eduter>
@vms
<eduter>
vmeson ... as I understood bitbake should behave if not instructed to continue running on detected errors. If I am not mistaken of course!
<smurray>
eduter: that's expected behavior AFAIK, if a task fails, bitbake doesn't just kill all other running tasks, it waits for them to finish. On the command-line this is why it takes 2x ctrl-c's, the second overrides the behavior and immediately kills everything
<eduter>
smurray thanks smurray! Then my bad, I have missunderstood the expected behaviour in my head.
<eduter>
smurray I am actually running the Yocto build on a CD/CI pipeline and of course I can manually cancel the job if I am following up on its progress...
<eduter>
smurray but I just thought if I could provoke it to fail faster after one parallel job, spawned by BitBake, has failed :-)
<eduter>
smurray Lesson learned! Thanks for the input guys.
<smurray>
eduter: looking at bitbake help, I don't see a flag to do that, i.e. the opposite of -k
<smurray>
eduter: probably the closest you can get is a log watcher that kills things if it sees ERROR
<eduter>
smurray I was searching for that as well in the help from command line, chat gpt, and asking a few colleagues. I think you are correct, there is no such a "inmediate termination" flag on detecting one single parallel job failure
<eduter>
smurray thought about it! to implement it in my YAML file for the pipeline
<eduter>
smurray I was afraid of doing that if it felt overkilling... but if I can convince my teammates I may do it hehe
<eduter>
smurray thanks!
zeemate has joined #yocto
<smurray>
eduter: if you could probably reduce impact with a shared sstate set up for your CI if you don't have it, as those long running tasks would end up cached when they do finish, and the next CI run shouldn't get stuck on them even if something else fails
<smurray>
oops, s/^if //
<eduter>
smurray like some sort mirror folder where to have the sstate directory caching the state, yes, I think we are missing to implement this... it will come, it has to happen. Thanks for pointing this out.,
jbo_ is now known as jbo
sakman has joined #yocto
<vmeson>
eduter as smurray may have already stated, some build tools (make, ninja, etc) can leave a project in an undefined state so RP said that he would NOT consider a patch even to make immediate termination optional.
<vmeson>
Having to wait for rust, or node, or chromium to finish building is painful though.
<RP>
we'd just get the bug reports for make/ninja/whatever leaving things in a bad state :(
<eduter>
Understood :-)
<eduter>
thanks for the answers guys, I am still kinda new to Yocto. I am learning everytime I come to the chat
RP has quit [Quit: Exiting]
RP has joined #yocto
eduter has quit [Quit: Client closed]
tr4gic_3rr0r has quit [Read error: Connection reset by peer]
paulg has joined #yocto
zkrx has quit [Ping timeout: 244 seconds]
zkrx has joined #yocto
sakoman has quit [Ping timeout: 276 seconds]
frgo has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
zeemate has quit [Ping timeout: 260 seconds]
sakoman has joined #yocto
zkrx has quit [Ping timeout: 244 seconds]
zkrx has joined #yocto
ptsneves has joined #yocto
ptsneves has quit [Ping timeout: 252 seconds]
tlwoerner has quit [Quit: Leaving]
cyxae has quit [Remote host closed the connection]
Chaser has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
CWiz has joined #yocto
Xagen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<CWiz>
How are package managers like 'go mod' supposed to work with the do_fetch step?
enok has quit [Ping timeout: 260 seconds]
savolla has quit [Quit: WeeChat 4.4.3]
<RP>
CWiz: there has been a lot of discussion about the different ways that could be done. There isn't a full solution merged yet
<CWiz>
That is what I was afraid of. I also have some colleges who are wanting to add in some node packages as well and I am assuming that will have the same issues
<RP>
Both are not where we'd ideally like them to be