| Message ID | 20220401235906.652-1-pkj@axis.com |
|---|---|
| State | Accepted, archived |
| Commit | 19a88df166862eb04fe6bee487796ef460d08771 |
| Headers | show |
| Series | [1/3] insane.bbclass: Make do_qa_patch() depend on if patch-fuzz is in ERROR_QA | expand |
On Sat, 2022-04-02 at 01:59 +0200, Peter Kjellerstedt wrote: > Adding "patch-fuzz" to ERROR_QA should trigger the patch tasks to > rerun to make sure any already existing fuzz is caught. This is > achieved by using bb.utils.filter() to see if "patch-fuzz" is in > ERROR_QA/WARN_QA as it adds whether the filtered strings are set or > not to the task hash. > > Since the mechanism used above ignores that a variable is excluded > (which WARN_QA is), the value for whether "patch-fuzz" is in WARN_QA > or not has to be explicitly excluded so that adding/removing > "patch-fuzz" to/from WARN_QA does not trigger the patch tasks to > rerun. > > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> > --- > meta/classes/insane.bbclass | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass > index 0deebdb148..873706952b 100644 > --- a/meta/classes/insane.bbclass > +++ b/meta/classes/insane.bbclass > @@ -1142,6 +1142,8 @@ python do_qa_staging() { > oe.qa.exit_with_message_if_errors("QA staging was broken by the package built above", d) > } > > +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Set" > +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Unset" I'd never seen that syntax before, it certainly wasn't intentional. Looking at the code, I can see how it happens to work though. It does assume a bit more internal implementation knowledge than I'd prefer... Cheers, Richard
On Sat, 2022-04-02 at 07:52 +0100, Richard Purdie via lists.openembedded.org wrote: > On Sat, 2022-04-02 at 01:59 +0200, Peter Kjellerstedt wrote: > > Adding "patch-fuzz" to ERROR_QA should trigger the patch tasks to > > rerun to make sure any already existing fuzz is caught. This is > > achieved by using bb.utils.filter() to see if "patch-fuzz" is in > > ERROR_QA/WARN_QA as it adds whether the filtered strings are set or > > not to the task hash. > > > > Since the mechanism used above ignores that a variable is excluded > > (which WARN_QA is), the value for whether "patch-fuzz" is in WARN_QA > > or not has to be explicitly excluded so that adding/removing > > "patch-fuzz" to/from WARN_QA does not trigger the patch tasks to > > rerun. > > > > Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> > > --- > > meta/classes/insane.bbclass | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass > > index 0deebdb148..873706952b 100644 > > --- a/meta/classes/insane.bbclass > > +++ b/meta/classes/insane.bbclass > > @@ -1142,6 +1142,8 @@ python do_qa_staging() { > > oe.qa.exit_with_message_if_errors("QA staging was broken by the package built above", d) > > } > > > > +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Set" > > +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Unset" > > I'd never seen that syntax before, it certainly wasn't intentional. Looking at > the code, I can see how it happens to work though. It does assume a bit more > internal implementation knowledge than I'd prefer... I've a patch I'm testing in master-next to try and address this and remove the need for this piece of patch. I need to be a little careful as the loop in question is one of the most time sensitive we have in the parsing code being iterated millions of times, so changes need to be mindful of that. Cheers, Richard
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index 0deebdb148..873706952b 100644 --- a/meta/classes/insane.bbclass +++ b/meta/classes/insane.bbclass @@ -1142,6 +1142,8 @@ python do_qa_staging() { oe.qa.exit_with_message_if_errors("QA staging was broken by the package built above", d) } +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Set" +do_qa_patch[vardepvalueexclude] .= "|WARN_QA{patch-fuzz} = Unset" python do_qa_patch() { import subprocess @@ -1182,9 +1184,9 @@ python do_qa_patch() { msg += " devtool modify %s\n" % d.getVar('PN') msg += " devtool finish --force-patch-refresh %s <layer_path>\n\n" % d.getVar('PN') msg += "Don't forget to review changes done by devtool!\n" - if 'patch-fuzz' in d.getVar('ERROR_QA'): + if bb.utils.filter('ERROR_QA', 'patch-fuzz', d): bb.error(msg) - elif 'patch-fuzz' in d.getVar('WARN_QA'): + elif bb.utils.filter('WARN_QA', 'patch-fuzz', d): bb.warn(msg) msg = "Patch log indicates that patches do not apply cleanly." oe.qa.handle_error("patch-fuzz", msg, d)
Adding "patch-fuzz" to ERROR_QA should trigger the patch tasks to rerun to make sure any already existing fuzz is caught. This is achieved by using bb.utils.filter() to see if "patch-fuzz" is in ERROR_QA/WARN_QA as it adds whether the filtered strings are set or not to the task hash. Since the mechanism used above ignores that a variable is excluded (which WARN_QA is), the value for whether "patch-fuzz" is in WARN_QA or not has to be explicitly excluded so that adding/removing "patch-fuzz" to/from WARN_QA does not trigger the patch tasks to rerun. Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com> --- meta/classes/insane.bbclass | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)