5427 2013-10-30 17:38:04 +0000 Extend and tidy up layer sanity checking 2017-02-06 22:59:06 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.6 All Multiple RESOLVED DUPLICATE 10596 Medium enhancement 2.3 M3 10596 1 bluelightning anibal.limon chong.lu kergoth liezhi.yang meta.mr.watcher meta.watcher Qi.Chen richard.purdie sgw srifenbark --- --- Yes (doc changes required) oldest_to_newest 38319 0 bluelightning 2013-10-30 17:38:04 +0000 Provide a script or inheritable class that will check if a layer is doing things it shouldn't; these would be more stringent checks than we could enable by default in sanity.bbclass/insane.bbclass. Suggested checks: * Check that a BSP layer isn't making any changes when the layer is included but MACHINE is not set to point to one of the conf/machine/*.conf that the layer provides * Similarly for DISTRO? * Check that conf/distro and conf/machine don't appear in the same layer * Check for ${PN} or ${P} usage in SRC_URI or S (should use ${BPN} or ${BP} instead to avoid breaking multilib) * Check that BSP/distro layers don't provide their own linux-libc-headers * Check that distro variables such as DISTRO_FEATURES are not being set in machine conf files * Check that all patches have Signed-off-by and Upstream-Status ? We do have recipe_sanity.bbclass and oelint.bbclass - these should be tidied up in the process. 44123 1 chong.lu 2014-06-20 09:30:41 +0000 Hi Paul, I will fix oelint.bbclass and make it work. And I will remove three checks there are LICENSE, MAINTAINER and PRIORITY. LICENSE check is included in license.bbclass. MAINTAINER and PRIORITY checks are unneeded. I add two checks in this oelint.bbclass: * Check for ${PN} or ${P} usage in SRC_URI or S (should use ${BPN} or ${BP} instead to avoid breaking multilib) * Check that all patches have Signed-off-by and Upstream-Status I don't understand what do you mean about three checks. Can you describe in details? * Check that a BSP layer isn't making any changes when the layer is included but MACHINE is not set to point to one of the conf/machine/*.conf that the layer provides * Similarly for DISTRO? * Check that conf/distro and conf/machine don't appear in the same layer Best Regards Chong 47461 2 bluelightning 2014-12-09 14:30:03 +0000 So to update the status of this bug, some of the changes have now been made: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7c85585bf6d436ee874e63cf375d4262ebe204a9 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=207e94d4e1ffb7cae5310c16efc6224a7f0ce056 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=268688a489add5ac3f378cf69d39f6c8c769549a Chong and I have discussed the outstanding checks via email, here is an excerpt of one of my earlier messages answering the questions above: ----------- snip ----------- > * Check that a BSP layer isn't making any changes when the layer is > included but MACHINE is not set to point to one of the > conf/machine/*.conf that the layer provides If a layer providing a machine is included but the machine is not selected in MACHINE, there should be no changes to the configuration of the system; i.e. any bbappends should have: VARIABLENAME_machine = "value" not: VARIABLENAME = "value" How you check this is a good question. You could examine it at a file level, but it might be better to look through the available recipes and check the variable history to see if anything within the layer is making a change to the values. Here is an example of using tinfoil to look at variable values per recipe: https://gist.github.com/bluelightning/6138980 You'd need to look elsewhere for examples on how to look at the variable history, perhaps in the layer index: http://git.yoctoproject.org/cgit/cgit.cgi/layerindex-web/tree/layerindex/recipeparse.py > * Similarly for DISTRO? Same thing as above but for distro layers. > * Check that conf/distro and conf/machine don't appear in the same layer A layer shouldn't be providing both a distro and a machine, those should be in separate layers. > * Check that BSP/distro layers don't provide their own linux-libc-headers Probably the check here would be to look for a recipe that has linux-libc-headers in its PROVIDES. ----------- snip ----------- 51428 3 srifenbark 2015-06-02 15:39:42 +0000 Note about the docs - Not quite implemented but the likelihood is it'll be an additional class and then we would add something to the section where we talk about creating layers on how to validate them using this functionality - From Paul Scott 54688 4 kergoth 2015-09-25 17:17:12 +0000 There've been a couple of creations of standalone scripts to check the machine / distro aspect of this, though I'm not sure if a standalone script is the ideal method or not. I can't seem to find a link to the one I didn't write, but I had a simple one at https://github.com/kergoth/oe-test-scripts, see 'leaky-layer-tests' -- it just gathers a list of the appends from a layer, does a -S none on those with the layer not included, then does a -S printdiff on each (with empty SSTATE_DIR, to ensure it uses the sigdata in STAMPS_DIR) with the layer included. Previously, it did a bitbake-whatchanged. I only mention this for reference or possible inspiration, I doubt it'd be worth including as is. 54693 5 kergoth 2015-09-25 17:49:56 +0000 (In reply to comment #4) > There've been a couple of creations of standalone scripts to check the > machine / distro aspect of this, though I'm not sure if a standalone script > is the ideal method or not. > > I can't seem to find a link to the one I didn't write, but I had a simple > one at https://github.com/kergoth/oe-test-scripts, see 'leaky-layer-tests' > -- it just gathers a list of the appends from a layer, does a -S none on > those with the layer not included, then does a -S printdiff on each (with > empty SSTATE_DIR, to ensure it uses the sigdata in STAMPS_DIR) with the > layer included. Previously, it did a bitbake-whatchanged. I only mention > this for reference or possible inspiration, I doubt it'd be worth including > as is. Found it. For reference, Chong Lu submitted a 'check-layers.py' script to do some of this, I had some concerns with it. Also Chen Qi submitted layer_extra_sanity.bbclass as a version which wasn't as separate script, which I think probably wasn't ideal, but is worth mentioning for reference and posterity in this issue. 54699 6 srifenbark 2015-09-25 20:04:07 +0000 For the documentation component of this bug, is it sufficient to document the layer_extra_sanity.bbclass in the reference manual? Scott 54700 7 kergoth 2015-09-25 20:39:31 +0000 (In reply to comment #6) > For the documentation component of this bug, is it sufficient to document > the layer_extra_sanity.bbclass in the reference manual? I don't think any of those mechanisms (the checks of the BSP and DISTRO layers) have been merged, so it wouldn't be appropriate to document them, but once an official mechanism makes it into oe-core, yes, we should definitely document how to use it. I wouldn't know which document would be most appropriate, I expect that depends on the final implementation selected, I only mentioned thme here for reference. 54701 8 srifenbark 2015-09-25 20:45:33 +0000 Christopher, Thanks for the clarification and the heads up. I will monitor. Scott 70380 9 richard.purdie 2017-02-02 16:21:11 +0000 Anibal: I think this is related to another bug you're now working on. Could you look through this one and see if there are useful pieces to combine into that work, then make this one depend on that one and/or close it as appropriate please? 70387 10 anibal.limon 2017-02-02 16:32:43 +0000 (In reply to comment #9) > Anibal: I think this is related to another bug you're now working on. Could > you look through this one and see if there are useful pieces to combine into > that work, then make this one depend on that one and/or close it as > appropriate please? Sure, i'll take into account this bug. 70391 11 anibal.limon 2017-02-02 17:14:53 +0000 Currently i'm working on standalone script (#10596) to make compatibility checking of layers, this will include the rules described in the Yocto Project Compabile page [1]. The unique difference with this bug is about the implementation as a bbclass instead of standalone script, but for the use case is better to have a standalone script because the checking needs to be made only at time of the process to be Yocto Project Compatible. I'm open to add some layer checking into insane class but needs to be discuss. I will close this bug as duplicated, objections? [1] https://www.yoctoproject.org/webform/yocto-project-compatible-registration 70397 12 srifenbark 2017-02-02 18:34:44 +0000 Hi Anibal, Can you make sure that I am on the CC list for the bug that you are going to use as this issue? I am assuming that it still could affect documentation. thanks, Scott 70398 13 anibal.limon 2017-02-02 18:36:39 +0000 (In reply to comment #12) > Hi Anibal, > > Can you make sure that I am on the CC list for the bug that you are going to > use as this issue? I am assuming that it still could affect documentation. > > thanks, > Scott Yes Scott, np. 70402 14 bluelightning 2017-02-02 20:24:14 +0000 Standalone script is fine - but one thing I do want the script to be able to do is check more than just what's in YP compatible - i.e. there's a standard mode and "YP compatible mode" where what goes into the YP compatible checks is more strictly defined (and documented), and the standard mode is a superset of that. That way the script can live in OE-core and it will be easier to accept patches to add additional checks that are outside the scope of the YP compatible programme. 70458 15 anibal.limon 2017-02-06 22:59:06 +0000 Resolve as duplicated in working on #10596. *** This bug has been marked as a duplicate of bug 10596 ***