| Message ID | 20211208215947.1979470-2-alex@linutronix.de |
|---|---|
| State | New |
| Headers | show |
| Series | [01/29] fetch: add a test for version check where compression changes | expand |
On Wed, 2021-12-08 at 22:59 +0100, Alexander Kanavin wrote: > Signed-off-by: Alexander Kanavin <alex@linutronix.de> > --- > meta/classes/insane.bbclass | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass > index 240f3aad62..8a47da5a09 100644 > --- a/meta/classes/insane.bbclass > +++ b/meta/classes/insane.bbclass > @@ -1176,7 +1176,9 @@ python do_qa_patch() { > (_, _, fullpath, _, _, _) = bb.fetch.decodeurl(url) > > # skip patches not in oe-core > - if '/meta/' not in fullpath: > + oecore_re = re.compile(d.getVar('BBFILE_PATTERN_core')) > + match_oecore = oecore_re.search(fullpath) > + if not match_oecore: > continue > > content = open(fullpath, encoding='utf-8', errors='ignore').read() Sorry about the miscommunication on this. I believed this patch would break things and that the sstate tests should have spotted it. They didn't as the test case doesn't quite cover this issue but there is a real problem here even though they pass. You can see the problem if you run: $ bitbake bash -c patch then $ bitbake-dumpsig tmp/stamps/XXX-poky-linux/bash/5.1.8-r0.do_patch.sigdata.XXX* | grep BBFILE_PATTERN and you see your build path to the metadata exposed: Variable BBFILE_PATTERN_core value is ^/media/build1/poky/meta/ which means the hashes just became metadata path specific. We can't do that. I've realised the sstate tests don't pick this up since the metadata is in a fixed location for the tests so it doesn't change. As well as fixing this patch, we should revise the sstate sigs tests to test for changes in metadata path changing the sigs. Cheers, Richard
On Thu, 9 Dec 2021 at 13:12, Richard Purdie < richard.purdie@linuxfoundation.org> wrote: > > # skip patches not in oe-core > > - if '/meta/' not in fullpath: > > + oecore_re = re.compile(d.getVar('BBFILE_PATTERN_core')) > > + match_oecore = oecore_re.search(fullpath) > > + if not match_oecore: > > continue > ... > I've realised the sstate tests don't pick this up since the metadata is in > a > fixed location for the tests so it doesn't change. As well as fixing this > patch, > we should revise the sstate sigs tests to test for changes in metadata path > changing the sigs. > I've sent a patch that adds the test that fails with this change and passes without it. The next step would be to fix the above snippet. Taking the path variable out of the signature is possible, but it would be better to do away with file paths altogether, and start giving layers unique layer ids that can be used in recipe context to detect which layer we're in. I can't quite figure out how to do this - presumably, such id would be set in layer.conf, but its scope would be limited only to recipes from that layer. Alex
diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass index 240f3aad62..8a47da5a09 100644 --- a/meta/classes/insane.bbclass +++ b/meta/classes/insane.bbclass @@ -1176,7 +1176,9 @@ python do_qa_patch() { (_, _, fullpath, _, _, _) = bb.fetch.decodeurl(url) # skip patches not in oe-core - if '/meta/' not in fullpath: + oecore_re = re.compile(d.getVar('BBFILE_PATTERN_core')) + match_oecore = oecore_re.search(fullpath) + if not match_oecore: continue content = open(fullpath, encoding='utf-8', errors='ignore').read()
Signed-off-by: Alexander Kanavin <alex@linutronix.de> --- meta/classes/insane.bbclass | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)