AKN_R has quit [Read error: Connection reset by peer]
valdemaras has quit [Quit: valdemaras]
valdemaras has joined #yocto
belgianguy has joined #yocto
starblue has quit [Ping timeout: 255 seconds]
Vonter has joined #yocto
Chaser has quit [Quit: Chaser]
belgianguy has quit [Quit: Leaving]
belgianguy has joined #yocto
Herrie has joined #yocto
<belgianguy>
I made a PR to the ST repo because the kirkstone builds were failing, PR got closed as it would "open undeterministic behavior they want to avoid for a generic delivery" https://github.com/STMicroelectronics/meta-st-stm32mp/pull/56
<belgianguy>
and then they say they have no solution themselves :/
<belgianguy>
Would hardcoding 11.4 have been a better solution, if the wildcard is the baddy here?
vvn has joined #yocto
valdemaras has quit [Quit: valdemaras]
Vonter has quit [Quit: WeeChat 4.0.4]
vvn has quit [Quit: WeeChat 4.0.3]
vvn has joined #yocto
Vonter has joined #yocto
<dario>
im not sure why the wildcard would be bad here
belgianguy has quit [Remote host closed the connection]
flom84 has quit [Remote host closed the connection]
Chaser has joined #yocto
kpo has joined #yocto
valdemaras has joined #yocto
<khem>
dario: thats also a valid approach. I think they test against a particular point releases on 4.0 LTS and want to support just those
<khem>
so if one wants to use their BSP they are expecting the given release of core layer match to what they have tested
<khem>
thats what they seem to imply with undeterministic behavior here.
<khem>
there is some substance to it, e.g. lets say if poky upgraded to a version of 11.x gcc which conflicts with their patch then it will be a problem
<khem>
so using wildcards is useful when the layer is keeping itself updated and testable across whole 11.x releases of gcc in this case