The current task has to be in BB_TASKDEPDATA so I think you're right, we should filter out "ourselves". I'll send a patch. Cheers, Richard

That definitely wasn't clear! I now understand better what you mean and yes, we're supposed to be optimising that scenario. No, they are hash equiv resolved hashes which would have a one to one mappin

That is probably unfortunately inevitable. If the output has changed (i.e. the headers are different), it shouldn't be matching a previous build as we can't know what has changed. The dependent resolv

FYI I did notice some docs here: https://git.yoctoproject.org/patchtest/tree/usage.adoc Cheers, Richard

We have the project autobuilder: https://autobuilder.yoctoproject.org/typhoon/#/console which runs many of the other tests I mentioned in my email. We did also used to have a VM which ran patchtest, i

Hi, Thanks for looping back to this. I've wondered if we do need to re-invent it but for different reasons. It currently integrates with patchwork but for example it may be better to have it work off

My personal thoughts are that whilst the pep8 changes are laudable, the real issues lie elsewhere with patchtest and it may be better to look at getting it going again first with improvements to the l

For many months a small group of people have tried to get our automated testing to the point where we can make builds with reliable test results. We hold the project to a high standard and the TSC (ri

I'm not sure we need to tag that repository, I think it was mainly there to allow transfer of the results over to the release artefacts? Cheers, Richard

Hi All, There are a few different discussions I'd like to pull together and talk about some QA and release process changes. Firstly, we've just made some changes to the docs build process. This is now

Hi All, I wanted to update people on some of the results of the "5 year plan" discussions that have been going on. A lot of the discussion was summarised into this wiki page: https://wiki.yoctoproject

That bitbake change did go back as it was straight forward to do, helped people and saved us from a ton of "eek, how do I fix this" support emails. It was simple enough that we could be reasonably cer

Against my better judgement, warrior has: https://git.yoctoproject.org/poky/commit/?h=warrior&id=d4b57c68b22027c2bedff335dee06af963e4f8a8 Morty does not. Cheers, Richard

[Just to be clear, this related to github dropping git protocol support] We've tried to be. Dunfell has: https://git.yoctoproject.org/poky/commit/?h=dunfell&id=0810ac6b926cd901f0619e95f367efc79d4c3159

I think you want TARGET_CFLAGS:append Cheers, Richard

Hi All, Feature freeze time in upon us for 3.5/Kirkstone, technically tomorrow (Mon 21st). I think I have a reasonably clear idea of what I intend to do now. I'm intending the inclusive language chang

Thanks Saul, from my perspective I think this is a good balance between cleaning up the syntax and other issues whilst being practical to implement and test in the time frames available. Cheers, Richa

I'm not sure I agree with that. I get the feeling some people want to allow these packages as long as they're with license X. Licenses can change over time and this allows a safety net that if it chan

In simple terms releases are time based or feature based, you do one or the other. We're leaning towards getting this in as the objective, which means the timing has to be flexible. We were in a reall

wrote: Just as a warning, the code is actually confused. The base.bbclass code assumes it is a recipe name, the license_image code assumes it is a package name. All the more reason to come up with a s