Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On 05/08/2017 08:36 AM, Patrick Ohly wrote: > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: >> +try: >> +ldata = bb.parse.handle(lconf, ldata, include=True) >> +except BaseException as exc: >> +raise LayerError(exc) > > Anibal, where is this LayerError class in compatlayer/__init__.py > supposed to come from? It doesn't get imported, leading to: > > File > "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/compatlayer/__init__.py", > line 45, in _get_layer_collections > raise LayerError(exc) > NameError: name 'LayerError' is not defined This code is based on kergoth ones from oe-tests-scripts [1], i forget to include the definition sorry for that but only extends exception to determine if there is a problem on parsing the layer conf. Anibal [1] https://github.com/kergoth/oe-test-scripts/blob/726fef692c7464932c2ded0fab22a875df78a31f/bb-determine-layers#L111 > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > +try: > +ldata = bb.parse.handle(lconf, ldata, include=True) > +except BaseException as exc: > +raise LayerError(exc) Anibal, where is this LayerError class in compatlayer/__init__.py supposed to come from? It doesn't get imported, leading to: File "/fast/work/intel-iot-refkit/openembedded-core/scripts/lib/compatlayer/__init__.py", line 45, in _get_layer_collections raise LayerError(exc) NameError: name 'LayerError' is not defined -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 16:01 +, Richard Purdie wrote: > On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote: > > On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote: > > > > > > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > > > > > > > > Is the "build single distro for different machines" scenario that > > > > I > > > > described part of the Yocto Compliance 2.0? Should there be tests > > > > for > > > > it? > > > Right now its not > > Okay, so the goal is a bit less ambitious than I had thought. I > > wonder > > whether that's useful, because at least the problems Ostro and AGL > > (at > > least as far as I understood it from lurking on their mailing list) > > had > > only happened when trying to combine multiple BSP layers *and* > > actually > > using the different machines in the same distro. > > > > > > > > but I'd consider it. > > At least I'd find that useful - not sure about others ;-} > > I do like the idea, I'm also mindful of walking before running... But bumping the requirements in the Yocto Compliance often will irritate people, because they will have to redo the compliance testing more often. > > > The question is can we write an > > > easy generic test for it, > > It's a bit more complicated than the existing tests, but I think it > > is > > doable. > > > > > > > > and also clearly phrase the criteria in the > > > list of compliance questions with a binary yes/no answer? > > Does the BSP layer only modify machine-specific packages and only > > when > > the MACHINE(s) defined by the BSP layer are selected? [yes/no] > > > > The "only when" part is covered by the existing tests (because they > > keep > > MACHINE constant). The missing part is comparing different MACHINE > > sstamps. > > That seems reasonable, unless the layer in question applying for > compatibility is not a BSP layer but thats a minor detail. > > I'm open to more details on what the test would look like. I guess I now have the AR to write such a test? ;-} -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 16:51 +0100, Patrick Ohly wrote: > On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote: > > > > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > > > > > > Is the "build single distro for different machines" scenario that > > > I > > > described part of the Yocto Compliance 2.0? Should there be tests > > > for > > > it? > > Right now its not > Okay, so the goal is a bit less ambitious than I had thought. I > wonder > whether that's useful, because at least the problems Ostro and AGL > (at > least as far as I understood it from lurking on their mailing list) > had > only happened when trying to combine multiple BSP layers *and* > actually > using the different machines in the same distro. > > > > > but I'd consider it. > At least I'd find that useful - not sure about others ;-} I do like the idea, I'm also mindful of walking before running... > > > > The question is can we write an > > easy generic test for it, > It's a bit more complicated than the existing tests, but I think it > is > doable. > > > > > and also clearly phrase the criteria in the > > list of compliance questions with a binary yes/no answer? > Does the BSP layer only modify machine-specific packages and only > when > the MACHINE(s) defined by the BSP layer are selected? [yes/no] > > The "only when" part is covered by the existing tests (because they > keep > MACHINE constant). The missing part is comparing different MACHINE > sstamps. That seems reasonable, unless the layer in question applying for compatibility is not a BSP layer but thats a minor detail. I'm open to more details on what the test would look like. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 15:12 +, Richard Purdie wrote: > On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > > Is the "build single distro for different machines" scenario that I > > described part of the Yocto Compliance 2.0? Should there be tests for > > it? > > Right now its not Okay, so the goal is a bit less ambitious than I had thought. I wonder whether that's useful, because at least the problems Ostro and AGL (at least as far as I understood it from lurking on their mailing list) had only happened when trying to combine multiple BSP layers *and* actually using the different machines in the same distro. > but I'd consider it. At least I'd find that useful - not sure about others ;-} > The question is can we write an > easy generic test for it, It's a bit more complicated than the existing tests, but I think it is doable. > and also clearly phrase the criteria in the > list of compliance questions with a binary yes/no answer? Does the BSP layer only modify machine-specific packages and only when the MACHINE(s) defined by the BSP layer are selected? [yes/no] The "only when" part is covered by the existing tests (because they keep MACHINE constant). The missing part is comparing different MACHINE sstamps. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 08:10 +0100, Patrick Ohly wrote: > On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote: > > > > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > > > > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers > > > > to > > > > review > > > > doesn't comes with recipes that changes the signatures. > > > I have a question about the goal for this test: is it meant to > > > detect > > > layers which incorrectly change the signatures of allarch recipes > > > or > > > recipes which share the same tune flags with other machines? > > > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures > > for > > something different compared to those other tests. > > > > The idea is that if you have a set of layers and generate the > > signatures for world, then you add say a BSP layer but do not > > select > > that MACHINE, the signatures should remain unchanged. > That's useful too, of course. > > Is the "build single distro for different machines" scenario that I > described part of the Yocto Compliance 2.0? Should there be tests for > it? Right now its not but I'd consider it. The question is can we write an easy generic test for it, and also clearly phrase the criteria in the list of compliance questions with a binary yes/no answer? Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Wed, 2017-03-01 at 04:00 +, Richard Purdie wrote: > On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > > > common.test_signatures: Test executed in BSP and DISTRO layers to > > > review > > > doesn't comes with recipes that changes the signatures. > > I have a question about the goal for this test: is it meant to detect > > layers which incorrectly change the signatures of allarch recipes or > > recipes which share the same tune flags with other machines? > > > > Let's take MACHINE=edison as an example. > > The test is not for these things. Its using the sstate signatures for > something different compared to those other tests. > > The idea is that if you have a set of layers and generate the > signatures for world, then you add say a BSP layer but do not select > that MACHINE, the signatures should remain unchanged. That's useful too, of course. Is the "build single distro for different machines" scenario that I described part of the Yocto Compliance 2.0? Should there be tests for it? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Tue, 2017-02-28 at 21:09 +0100, Patrick Ohly wrote: > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > > > > common.test_signatures: Test executed in BSP and DISTRO layers to > > review > > doesn't comes with recipes that changes the signatures. > I have a question about the goal for this test: is it meant to detect > layers which incorrectly change the signatures of allarch recipes or > recipes which share the same tune flags with other machines? > > Let's take MACHINE=edison as an example. The test is not for these things. Its using the sstate signatures for something different compared to those other tests. The idea is that if you have a set of layers and generate the signatures for world, then you add say a BSP layer but do not select that MACHINE, the signatures should remain unchanged. Cheers, Richard -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Tue, 2017-02-28 at 14:33 -0600, Aníbal Limón wrote: > > On 02/28/2017 02:09 PM, Patrick Ohly wrote: > > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > >> common.test_signatures: Test executed in BSP and DISTRO layers to review > >> doesn't comes with recipes that changes the signatures. > > > > I have a question about the goal for this test: is it meant to detect > > layers which incorrectly change the signatures of allarch recipes or > > recipes which share the same tune flags with other machines? > > The requirement is DISTRO and BSP layers aren't allowed to automatically > change the MACHINE or DISTRO variable that causes the signatures to change. I do not fully understand this explanation. Can you give an example for the kind of misbehavior what the test is meant to catch? > > Let's take MACHINE=edison as an example. > > > > Modifying allarch creates a conflict with basically all other machines > > in a distro. Example for something not allowed: > > VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo > > /var/foo \n" > > > > This can be detected by comparing against OE-core, but only when testing > > with MACHINE=edison. > > > > More difficult to detect is modifying recipes with the same tune flags, > > which is the majority of the recipes. MACHINE=edison and > > MACHINE=intel-core2-32 both compile for the same target architecture, so > > something like this is incorrect: > > do_install_append_pn-base-files_edison () { > > echo "Built for Edison" >>${D}${sysconfdir}/motd > > } > > > > This can only be detected when testing with both MACHINE=edison and > > MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different > > tune flags (haven't checked). > > > > My point is, the test probably needs to be extended to run with a set of > > machines, and that set of machines must be broad enough to cover a > > variety of common tune flags. > > It is expected to change recipe signatures when the machine change, this > leaves me other question. what signatures are expected to change when > set a different MACHINE? Everything that is machine-specific may change, for example image recipes and kernel (although even that is a slight simplification, as meta-intel intentionally shares kernels between different MACHINE configs). The real-world test is: can two BSP layers be combined in a single distro so that one can build first for one MACHINE, then the other (or, when using multiconfig, even in a single build)? If any shared package changes as result of changing the MACHINE, then that won't work. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On 02/28/2017 02:09 PM, Patrick Ohly wrote: > On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: >> common.test_signatures: Test executed in BSP and DISTRO layers to review >> doesn't comes with recipes that changes the signatures. > > I have a question about the goal for this test: is it meant to detect > layers which incorrectly change the signatures of allarch recipes or > recipes which share the same tune flags with other machines? The requirement is DISTRO and BSP layers aren't allowed to automatically change the MACHINE or DISTRO variable that causes the signatures to change. > > Let's take MACHINE=edison as an example. > > Modifying allarch creates a conflict with basically all other machines > in a distro. Example for something not allowed: > VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo > \n" > > This can be detected by comparing against OE-core, but only when testing > with MACHINE=edison. > > More difficult to detect is modifying recipes with the same tune flags, > which is the majority of the recipes. MACHINE=edison and > MACHINE=intel-core2-32 both compile for the same target architecture, so > something like this is incorrect: > do_install_append_pn-base-files_edison () { > echo "Built for Edison" >>${D}${sysconfdir}/motd > } > > This can only be detected when testing with both MACHINE=edison and > MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different > tune flags (haven't checked). > > My point is, the test probably needs to be extended to run with a set of > machines, and that set of machines must be broad enough to cover a > variety of common tune flags. It is expected to change recipe signatures when the machine change, this leaves me other question. what signatures are expected to change when set a different MACHINE? Anibal > > The corresponding selftest, test_sstate_sametune_samesigs in > sstatetests.py, has the same limitation of its scope, i.e. doesn't > actually test with real machine definitions. > signature.asc Description: OpenPGP digital signature -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] [PATCHv2] yocto-compat-layer.py: Add script to YP Compatible Layer validation
On Mon, 2017-02-20 at 15:12 -0600, Aníbal Limón wrote: > common.test_signatures: Test executed in BSP and DISTRO layers to review > doesn't comes with recipes that changes the signatures. I have a question about the goal for this test: is it meant to detect layers which incorrectly change the signatures of allarch recipes or recipes which share the same tune flags with other machines? Let's take MACHINE=edison as an example. Modifying allarch creates a conflict with basically all other machines in a distro. Example for something not allowed: VOLATILE_BINDS_append_pn-volatile-binds_edison = " /var/volatile/foo /var/foo \n" This can be detected by comparing against OE-core, but only when testing with MACHINE=edison. More difficult to detect is modifying recipes with the same tune flags, which is the majority of the recipes. MACHINE=edison and MACHINE=intel-core2-32 both compile for the same target architecture, so something like this is incorrect: do_install_append_pn-base-files_edison () { echo "Built for Edison" >>${D}${sysconfdir}/motd } This can only be detected when testing with both MACHINE=edison and MACHINE=intel-core2-32 - at least I think MACHINE=qemux86 uses different tune flags (haven't checked). My point is, the test probably needs to be extended to run with a set of machines, and that set of machines must be broad enough to cover a variety of common tune flags. The corresponding selftest, test_sstate_sametune_samesigs in sstatetests.py, has the same limitation of its scope, i.e. doesn't actually test with real machine definitions. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto