<JaMa>
there is still something wrong with latest pressure regulation, I see very high cpu pressure fluctuation and often only a few bitbake tasks running when the load isn't so bad
<JaMa>
NOTE: Pressure status changed to CPU: False, IO: None, Mem: None (CPU: 0.0/1000.0, IO: 0.0/None, Mem: 0.0/None)
<JaMa>
NOTE: Running task 207 of 1315 (/OE/build/oe-core/openembedded-core/meta/recipes-devtools/gcc/gcc-source_13.2.bb:do_unpack)
<JaMa>
NOTE: Pressure status changed to CPU: True, IO: None, Mem: None (CPU: 152474.1/1000.0, IO: 0.0/None, Mem: 0.0/None)
<JaMa>
this is with Load average: 7.40 8.32 11.41 on 32c 64t CPU
<RP>
JaMa: I'm not sure what to do with the pressure stuff. Something doesn't quite seem right but what...
Kubu_work has joined #yocto
<JaMa>
I've sent small change to show the pressure numbers in the NOTE and will look at rust build with just oe-core, but the regulation kicks in like every second
<JaMa>
I've started to use it when it was introduced, because it was preventing OOMKs, but now I'm doubting the build time increase is worth it (or adequate)
<JaMa>
before "Pressure status changed" notes I was in sweet ignorance that something is wrong :)
<RP>
JaMa: it was unclear if there was an issue!
<RP>
JaMa: FWIW the numbers on the autobuilder don't look too bad. We see changes but only when they might make sense
<JaMa>
maybe something else triggers these spikes as it's on my regular desktop with chrome and other stuff running on background, will be interesting to see the pressure fluctuations from our jenkins or from AB builds
<JaMa>
and it's much more conventient than pressure graphs from buildstats as it shows the exact values bitbake was using
Guest62 has joined #yocto
lamm has joined #yocto
<Guest62>
is there a set way to add actual docker containers to an image as our device uses docker containers to perform certain tasks
Bardon_ has joined #yocto
Bardon has quit [Ping timeout: 248 seconds]
AKN has joined #yocto
dodoradio has quit [Quit: dodoradio]
kpo has joined #yocto
dodoradio has joined #yocto
Chaser has joined #yocto
dodoradio has quit [Quit: dodoradio]
Chaser has quit [Quit: Chaser]
Chaser has joined #yocto
lexano has joined #yocto
ptsneves has joined #yocto
amitk_ has joined #yocto
ptsneves has quit [Ping timeout: 246 seconds]
<adrianf>
Guest62: I think with docker or podman the best answer is docker pull. Pre-loading containers (which is probably what you are asking for) is more tricky. We did that with a multiconfig build (host + container distro) and systemd-nspawn. It's possible by extracting the container image tar file with a fakeroot task in the image recipe. If you have
<adrianf>
containers with layers and Docker which is supposed to update the containers with docker pull later on, it's much more tricky. When I thought about all the possible corner cases (build-time and run-time), I decided not to implement something like this for our use cases.
AKN has quit [Read error: Connection reset by peer]
goliath has quit [Quit: SIGSEGV]
sakoman has joined #yocto
florian_kc has quit [Ping timeout: 248 seconds]
dodoradio has joined #yocto
tepperson has joined #yocto
<tepperson>
I am using devtool modify to do development of a package for my target. I am noticing that when i run bitbake on my recipe, the source files timestamps get modified (presumably by the bitbake process). is there a way to prevent this?
zpfvo has quit [Ping timeout: 250 seconds]
<RP>
tepperson: it shouldn't be doing that unless it is changing them
<tepperson>
hmm, i've compared the source before and after a run and the only difference is the modified time on the file. I've noted the behaviour on both an autotools project and a cmake project
<RP>
tepperson: all files, one file, some files with a common extension?
amitk_ has joined #yocto
dodoradio has quit [Quit: dodoradio]
<tepperson>
RP: it appears to be just the source files that get modified
<dvergatal>
RP: generally i need that file build/sstate-cache/ae/af/sstate:flac:core2-64-poky-linux:1.4.3:r0:core2-64:11:aeafd17808e42128668acce4c8ec443b2b34aede595f980243c246fac905d2b2_package.tar.zst to verify in what format the tar in it is - the hash is wrong because it is from my local machine
<dvergatal>
RP: abelloni: If it is not possible to retrive it from the previous one, than is it possible for you to recreate the issue?
Chaser has joined #yocto
Chaser has quit [Remote host closed the connection]
<yates_work>
i've taken a two-year hiatus from yocto and forgotten everything i knew :(
<yates_work>
this is a great document to refresh the memory cells
<yates_work>
i was pointed to the meta-qt5 layer. is this layer capable of generating qt as a single, static library? if not, is there a layer that does so?
<khem>
yates_work: glad you are back tinkering with yocto again, a lot has changes in 2 years and hopefully you will find it helpful. meta-qt5 generates all kind qt5 base support libraries, I have not heard of single static library for qt maybe you are talking about qtbase ?
<dvergatal>
RP: OK so what can we do now? Because I'm unable to reproduce it... the best option for me would be to start a run again but question is if you or abelloni can do this for me?
dodoradio has joined #yocto
<RP>
dvergatal: I'm burning out with too many directions. I can't debug everyone's patches. The autobuilder is also struggling under the patch test load so this isn't a trivial thing to do
<RP>
dvergatal: abelloni is on holiday atm so we just have me
<RP>
dvergatal: I don't know what to recommend, I'm doing my best to help with pointers
<RP>
dvergatal: for context your patches trigger full rebuilds and we likely need to run with them for a while to introduce the kinds of corruption we saw :/
dodoradio has quit [Quit: dodoradio]
<dvergatal>
RP: sure thing, I feel your pain:D and I can wait so it's not a problem