Bug 8777

Summary: The layer priorities are not obeyed properly
Product: [Build System, Metadata & Runtime] Toaster Reporter: Sujith H <sujith.h>
Component: toasterAssignee: Toaster default assignee <toaster>
Status: RESOLVED NOTABUG QA Contact: Mihail Stanciu <stanciux.mihail>
Severity: normal    
Priority: Undecided CC: belen.barros.pena, bluelightning, jessica.zhang, stanciux.mihail
Version: 2.0   
Target Milestone: ---   
Hardware: x86   
OS: ppc   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: Don't know

Description Sujith H 2015-12-07 10:59:56 UTC
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.
Comment 1 Paul Eggleton 2015-12-07 19:36:13 UTC
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.
Comment 2 Sujith H 2015-12-08 02:54:54 UTC
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 )
Comment 3 Sujith H 2015-12-08 13:30:24 UTC
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.
Comment 4 Sujith H 2015-12-08 13:32:59 UTC
Marking this issue as Resolved->Notabug.