I gather this is so that they can specify the emgd branch. However, the meta data should manage this internally by the machine scc file:

$ cat crownbay-standard.scc 
define KMACHINE crownbay
define KTYPE standard
define KARCH i386

include ktypes/standard
branch crownbay

git merge emgd-1.14

include crownbay.scc

# default policy for standard kernels
include cfg/usb-mass-storage.scc
include cfg/boot-live.scc
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc


It merges emgd-1.14, so I don't see any value in specifying the emgd branch in the recipe. I believe the right approach would be to include emgd.scc in KERNEL_FEATURES_crownbay and not in KERNEL_FEATURES_crownbay-noemgd and remove the git merge from the crownbay-standard.scc.

Same for cedartrail.

Tom, thoughts?

In my opinion this would be resolved with a fix to Bug 2268.

The build system needs to be able to figure out when to rebuild when SRCREVs change, and so all branches that contribute to the built tree need an entry in the SRCREV.

There isn't currently a way to append a new branch to the base set from the kernel recipe (maybe an enhancement bug needs to be filed for this), so the SRC_URI needs to be overridden in the bbappend.  A BSP should be able do to that and the layering priorities and .bbappend ordering of application should allow other appends to behave as expected.

The fact that it's not suggests a deeper problem (or some other misconfiguration).  From the original thread:

---

It shouldn't though, since the application of the meta-tlk SRC_URI
bbappend should follow the SRC_URI assignment in the cedartrail
bbappend.  On the other hand, the layer priorities don't seem to be
right - meta-cedartrail is supposed to have a priority of 6, but it
doesn't actually seem to:

BBFILE_PRIORITY_cedartrail = "6" 

[trz@empanada build]$ bitbake-layers show_layers
layer                 path                                      priority
==========================================================================
meta                  /home/trz/yocto/crownbay-test/meta        5
meta-yocto            /home/trz/yocto/crownbay-test/meta-yocto  5
meta-yocto-bsp        /home/trz/yocto/crownbay-test/meta-yocto-bsp  5
meta-intel            /home/trz/yocto/crownbay-test/meta-intel  5
meta-cedartrail       /home/trz/yocto/crownbay-test/meta-intel/meta-cedartrail  5
meta-tlk              /home/trz/yocto/crownbay-test/meta-intel/meta-tlk  5

On the other hand, meta-tlk does follow meta-cedatrail in the parse
order so should append to the SRC_URI...

Maybe the layer priority issue should be treated separately.
After a few tryouts, I've noticed that priority doesn't solve this issue.
With meta-intel/meta-cedartrail placed above meta-intel, in BBLAYERS, the correct priority is listed, but the SRC_URI append is still ignored.

mihai@localhost:~/cedartrail$ bitbake-layers show_layers
layer                 path                                      priority
==========================================================================
meta                  /home/mihai/poky/meta                     5
meta-yocto            /home/mihai/poky/meta-yocto               5
meta-yocto-bsp        /home/mihai/poky/meta-yocto-bsp           5
meta-cedartrail       /home/mihai/meta-intel/meta-cedartrail    6
meta-intel            /home/mihai/meta-intel                    5
meta-tlk              /home/mihai/meta-intel/meta-tlk           5

I was thinking that SRC_URI_machine simply becomes SRC_URI, disregarding its previous value that had file://time-limited-kernel.cfg already appended, instead of just replacing the actual URI.

Good point Tom.

I wonder, could this be resolved by adding the TLK to SRC_URI_append instead of to the SRC_URI directly? Then it could be added to whatever SRC_URI was during eval?

So using SRC_URI_append in meta-tlk results in:

ERROR: ExpansionError during parsing /home/dvhart/source/poky/meta/recipes-kernel/linux/linux-yocto_3.4.bb: Failure expanding variable do_patch: ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure for URL: 'git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=standard/crownbay,meta,emgd-1.14;name=machine,meta,emgdfile://time-limited-kernel.cfg'. Please set SRCREV to a valid value


Which shows it is getting appended, but without a new line. Using a newline results in:

ERROR: ExpansionError during parsing /home/dvhart/source/poky/meta/recipes-kernel/linux/linux-yocto-rt_3.4.bb: Failure expanding variable do_patch: ExpansionError: Failure expanding variable SRCPV, expression was ${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError: Fetcher failure: Fetch command failed with exit code 128, output:
fatal: No path specified. See 'man git-pull' for valid url syntax

It isn't clear to me why this fails. Some subtlety with the way the _append operator works?

Indeed a solution for this, on the meta-tlk side, would be to use either of the following:
SRC_URI_append += "file://time-limited-kernel.cfg"
SRC_URI_append = " file://time-limited-kernel.cfg "

But is this ok?
I see this more as a workaround, than a solution.

Darren, you said that SRC_URI of the BSPs should be handled internally, and there's no need for adding emgd / pvr branches to the URI. So can a fix be managed on the BSP side, to drop using SRC_URI_machine?

The branches need to be in the SRC_URI - the fetcher checks the branch SRCREVs to see whether it needs to re-fetch the kernel.  If it doesn't, the build system has no idea it needs to update and won't, and the kernel build will try to build against old sources and at some point will fail.

So because we need the additional branch in the SRC_URI and there's no way to append it, we need to change the whole SRC_URI.  While not normally done, it should be possible to do that if necessary.

Okay, change it meta-tlk it is.

Merged in meta-intel/master

http://git.yoctoproject.org/cgit.cgi/meta-intel/commit/?id=7228f6b0c81817c8a8455ea78271abfd5d66fed8

Also merged http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=f76c3a98c8f19501b66e2827f20b395b03e5aefc

Now it works fine.