<vnd>
Not sure if I'm doing something wrong, or FetchContent just doesn't play well with Yocto SDK
<mcfrisk>
vnd: sounds like a bug in nativesdk-cmake config. Though dowloading in build scripts is evil and causes lots of integration and build reproducibility issues
* mcfrisk
managed to leak Cooker, qemu-system-aarch etc processes again with "bitbake -c testimage core-image-base; 3 times ctrl-c interupts; bitbake -c testimage core-image-base".
<mcfrisk>
also a rootfs got zapped to empty. I wonder if I'm doing things wrong if no-one else sees these..
<mcfrisk>
after ctr-c SIGINT, the background Cooker process takes 30 seconds to exit. It is too easy to call bitbake again during that time and then everything goes wrong after that
<RP>
mcfrisk: I have seen qemu leak but not been able to pin down where/why
<RP>
mcfrisk: the server refused shutdown is pseudo, not bitbake
<RP>
mcfrisk: I wonder where the 30s timeout is...
<mcfrisk>
RP: 30 seconds is a rough estimate, I'm checking pstree -upln how the processes terminate after ctrl-c to bitbake which exists quite fast. if new bitbake command line is called it connects automatically to the yet-to-be-killed background process, then things go south and hang even more. I should disable the connect to background Cooker..
<RP>
mcfrisk: it would be good to get to the bottom of what is going on...
<mcfrisk>
trying that
<RP>
mcfrisk: right, I'm just agreeing :)
mbulut has quit [Ping timeout: 248 seconds]
rfuentess has quit [Remote host closed the connection]
<RP>
mcfrisk: that is good data. I wonder what it is doing
<RP>
mcfrisk: that is effectively the task execution context so it makes sense, just not sure why it would hang in there
mbulut has joined #yocto
<mcfrisk>
testimage forking qemu and running until SIGKILL?
<RP>
mcfrisk: possible, yes
<RP>
mcfrisk: which would imply the SIGINT isn't doing the cleanup we think it is/should be
<mcfrisk>
RP: running "bitbake -c testimage core-image-base" and monkey testing with ctrl-c, https://pastebin.com/raw/jJD0i2dQ and thus the need for patch "testimage.bbclass: capture RuntimeError too"
<RP>
mcfrisk: I don't understand what extra codepath adding that RuntimeError exception adds into the system which makes things work though
<RP>
mcfrisk: if that patch really does work, it means that we'll have this issue for any other exception
<RP>
mcfrisk: this is why I want to understand it, else we need to add every other possible python exception to that list
<mcfrisk>
I think "testimage.bbclass: change test failure logging from bb.fatal() to bb.error()" fixed the worst leaks
<RP>
mcfrisk: if that is the case, it means there is a exception clause somewhere which could do with catching SystemExit
<RP>
(fatal raises a SystemExit exception)
<mcfrisk>
yep, that could b eit
<mcfrisk>
and some bug in testimage not working well with SIGINT once qemu machine has been started
mbulut has quit [Ping timeout: 265 seconds]
<RP>
mcfrisk: yes, that seems quite likely
<mcfrisk>
ah there are more bb.fatal() calls in testimage.bbclass which could end up exiting without cleanup/stopping qemu process
<RP>
mcfrisk: that would do it :/
<RP>
How upset are people going to be if bitbake's parser stops accepting X="1" (instead of X = "1")
florian_kc has joined #yocto
Guest64 has joined #yocto
Guest64 has quit [Client Quit]
Guest94 has joined #yocto
<mcfrisk>
I thought X="1" already fails in the parser..
<RP>
mcfrisk: sadly not
Guest94 has quit [Client Quit]
Guest64 has joined #yocto
Guest64 has quit [Quit: Client closed]
Chaser_ has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
<RP>
I'm going to quickly get bored fixing these :/
goliath has joined #yocto
Chaser has joined #yocto
vnd has quit [Quit: Client closed]
<Saur>
RP: While I understand your frustration, isn't that a job for a linter and/or patchtest rather than the parser?
<RP>
Saur: have a look at the last patch on the bitbake-devel list and the potential bugs this lets in :/
<RP>
Saur: I'm starting to think it might be better to make the parser a bit stricter
<RP>
I was under the impression the lax parser didn't cause problems but I'm rethinking that viewpoint
Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
<Saur>
RP: Wow, had not even considered that kind of problem. My suggestion would be to change the regular expression for variables to only allow the first and last character of the name to be one of [a-zA-Z0-9_].
rob_w has quit [Remote host closed the connection]
Kubu_work has quit [Quit: Leaving.]
<RP>
Saur: we have some cases where we need + in there :/
<qschulz>
and I had some idea too, since we have patchtest running on patches sent by mail, maybe we could run those checks locally too with b4 prep --check?
<RP>
qschulz: sorry, just replied
<RP>
qschulz: that sounds like a neat idea
<qschulz>
I don't think we should make it necessary for the first version though, something we could add later on
<qschulz>
I haven't fully gotten the setup of this patchtest thingy and how difficult it'd be to adapt it to stdin input instead of a hash for example
<qschulz>
RP: np :)
<qschulz>
RP: just to be sure, "I'm find with two different files and
<qschulz>
combo-layer can handle that easily.
<qschulz>
"
<RP>
I'm fine
<qschulz>
you meant the same filename just in different repos right?
<RP>
yes
<qschulz>
ack
Chaser has quit [Quit: My Unrecognized Mac has gone to sleep. ZZZzzz…]
ehussain has quit [Read error: Connection reset by peer]
ahussain is now known as ehussain
florian has quit [Quit: Ex-Chat]
tec4 has quit [Quit: bye!]
<sakoman>
qschulz: since it is adding a feature it isn't something I can backport without TSC approval. I was hoping to see some discussion as a result of your RFC, but just silence!
tec4 has joined #yocto
florian_kc has quit [Ping timeout: 244 seconds]
jmiehe has joined #yocto
<qschulz>
sakoman: ok thanks for the info. Is there some desire to bring this to TSC or is it just not worth to bother? It's not a revolutionary patch so I understand if this is too much process for what it brings :)
jmiehe has quit [Client Quit]
<sakoman>
qschulz: since there wasn't support expressed on the RFC it doesn't seem to be something worth taking to the TSC
<qschulz>
sakoman: do you mind if I answer to myself providing this context and saying if anyone wants this backported they need to manifest themselves but for now this is abandoned?
<RP>
qschulz: I think that is a reasonable position. We can't really backport it without others saying they would like it