8777 2015-12-07 10:59:56 +0000 The layer priorities are not obeyed properly 2015-12-08 13:32:59 +0000 1 1 7 Build System, Metadata & Runtime Toaster toaster 2.0 x86 ppc RESOLVED NOTABUG Undecided normal --- 1 sujith.h toaster belen.barros.pena bluelightning jessica.zhang stanciux.mihail stanciux.mihail --- --- Don't know oldest_to_newest 57070 0 sujith.h 2015-12-07 10:59:56 +0000 While triggering an image at Mentor, it was observed that recipe talloc was breaking at do_configure phase. After a bit of investigation it was figured out that 2 bbclass-es are not taken: a) qemu.bbclass b) waf-samba.bbclass These bbclasses fall under meta-mentor-staging layer ((Reference: http://git.yoctoproject.org/cgit/cgit.cgi/meta-mentor/tree/meta-mentor-staging/classes?h=cedar). Instead the build was taking waf-samba.bbclass from meta-oe layer and qemu.bbclass from poky/meta layer. When ran the below in a django shell ( thanks to Michael Wood for the helping hand which helped me understand the problem ): ------------- (venv)sujith@kdekidd0:~/myproject$ ~/mgc/embedded/mel/2015.12.119/poky/bitbake/lib/toaster/manage.py shell Python 2.7.6 (default, Jun 22 2015, 17:58:13) [GCC 4.8.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> from orm.models import * >>> from bldcontrol.models import BuildRequest >>> Layer_Version.objects.filter(layer__name="meta-mentor-staging").last().priority 0 >>> Layer_Version.objects.filter(layer__name="meta-python").last().priority 0 >>> Layer_Version.objects.filter(layer__name="meta-mentor-staging").first().priority 10 >>> Layer_Version.objects.filter(layer__name="meta-oe").last().priority 0 >>> Layer_Version.objects.filter(layer__name="meta-oe").first().priority 6 >>> ------------- I am not sure why the priority is reset to 0 ( zero ). I assume this could be reproducible, if we create multiple layers let's say: meta-a, meta-b, meta-c etc and then copy a bbclass to one of the newly created layers. Update the do_configure as follows do_configure () { echo " I am here... " > /tmp/test.log #Rest of the code should be kept as it is ... } So when user tries to run the recipe's configure from toaster, he/she should be able to see /tmp/test.log file. Else we are hit with a crucial bug. 57104 1 bluelightning 2015-12-07 19:36:13 +0000 So there may well be a bug relating to layer priorities; but do note that when a bbclass is found in multiple layers, layer priority *does not* control which one is picked up - that's controlled solely through BBPATH. Since it's each layers' layer.conf that sets BBPATH, it can be influenced by the order in which the layer appears in bblayers.conf; additionally the layer.conf may choose to append or prepend to BBPATH which will also affect the overall order of paths in the final BBPATH value. 57116 2 sujith.h 2015-12-08 02:54:54 +0000 Paul Eggleton, thanks a ton for pointing out about BBPATH. What I have observed is that command line builds are successfully creating images. I will update/share BBPATH values accordingly here ( once I reach office ) 57126 3 sujith.h 2015-12-08 13:30:24 +0000 I have verified today by looking into the bblayers.conf file. So lets say if there are layers in the order ( after sourcing of meta-mentor/setup-environment script) a , b , c. The toasterconf.json file is having layer information in the reverse order: c, b , a. And as a result when toaster is executed from the terminal, the layer order remains as: c, b , a. And hence as Paul Eggleton suggested, the issue lies in the BBPATH. So I tried to rectify it in my custom script which creates toasterconf.json file. And which resolved the issue. 57127 4 sujith.h 2015-12-08 13:32:59 +0000 Marking this issue as Resolved->Notabug.