3217 2012-10-03 15:53:08 +0000 meta-cedartrail and meta-crownbay discard SRC_URI additions 2012-10-08 08:36:51 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-meta-intel unspecified x86 Multiple VERIFIED FIXED Low normal 1.3 1 mihai.lindner tom.zanussi dvhart tom.zanussi --- --- --- oldest_to_newest 26150 0 mihai.lindner 2012-10-03 15:53:08 +0000 meta-intel: 2c1e927fa99abe47865a03cf661d4757ff3147c6 BBLAYERS ?= " \ /home/mihai/poky/meta \ /home/mihai/poky/meta-yocto \ /home/mihai/poky/meta-yocto-bsp \ /home/mihai/meta-intel \ /home/mihai/meta-intel/meta-cedartrail \ /home/mihai/meta-intel/meta-tlk \ " Using meta-tlk, SRC_URI should have file://time-limited-kernel.cfg included, but it's not there. $ bitbake -e linux-yocto | grep SRC_URI= # SRC_URI=git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=${KBRANCH},meta,yocto/pvr;name=machine,meta,pvr SRC_URI="git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=yocto/standard/cedartrail,meta,yocto/pvr;name=machine,meta,pvr" The result is a TLK image without time limit config in the kernel. # CONFIG_UPTIME_LIMITED_KERNEL is not set Common for meta-cedartrail and meta-crownbay only (and not used in other BSPs), both have SRC_URI_machine in linux-yocto_*.bbappend recipes. 26152 1 dvhart 2012-10-03 16:01:20 +0000 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? 26155 2 dvhart 2012-10-03 16:05:46 +0000 In my opinion this would be resolved with a fix to Bug 2268. 26159 3 tom.zanussi 2012-10-03 16:11:02 +0000 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... 26168 4 mihai.lindner 2012-10-03 16:46:50 +0000 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. 26169 5 dvhart 2012-10-03 16:54:26 +0000 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? 26170 6 dvhart 2012-10-03 17:12:02 +0000 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? 26196 7 mihai.lindner 2012-10-04 09:31:17 +0000 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? 26228 8 tom.zanussi 2012-10-04 13:57:57 +0000 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. 26241 9 mihai.lindner 2012-10-04 15:05:02 +0000 Okay, change it meta-tlk it is. 26303 10 mihai.lindner 2012-10-06 11:22:31 +0000 Merged in meta-intel/master http://git.yoctoproject.org/cgit.cgi/meta-intel/commit/?id=7228f6b0c81817c8a8455ea78271abfd5d66fed8 26317 11 mihai.lindner 2012-10-08 08:36:51 +0000 Also merged http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/commit/?id=f76c3a98c8f19501b66e2827f20b395b03e5aefc Now it works fine.