| Summary: | cedartrail: fails to merge yocto/pvr branch for linux-yocto-3.0 | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Darren Hart <dvhart> |
| Component: | bsps-configuration | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | Medium | CC: | dvhart, kishore.k.bodke, mihai.lindner, richard.purdie, song.liu, tom.zanussi, yp.bsp.watcher, yp.watcher |
| Version: | 1.2 | ||
| Target Milestone: | 1.2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Darren Hart
2012-04-13 21:24:11 UTC
Since there is no 1.2_M4 for meta-intel, I assume this is for 1.2_M3.rcx. Even then, Cedartrail will not build for 1.2_M3.rcx, as it does not have the correct patches for the pvr updates. This is available in meta-intel/master. Thanks Kishore. updating the bug with my email comments: No branches in the 3.2 tree have yocto/ as a base in their branch hierarchy. The branch is simply 'pvr' .. and in my 3.2 tree, the cedartrail doesn't attempt to merge it at all. We merged a prep feature for pvr merging, and yocto/pvr exists in 3.0. http://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto-3.0/log/?h=yocto/pvr But it looks like this is under control, but has anyone looked at the downloaded kernel tree for that build .. did the yocto/pvr branch even show up ? Since whether or not it was ready, that branch should be in the tree. I don't think I should be the assignee for this one .. who should it be ? or should this just be put on hold for now ? Here's a patch that might work, seems like it should but I haven't verified that it actually does... commit b1fe099459ed96ef116b7be560459538f8566e2c Author: Tom Zanussi <tom.zanussi@intel.com> Date: Sun Apr 15 22:26:38 2012 -0500 meta-cedartrail: add yocto/pvr branch to SRC_URI meta-cedartrail merges yocto/pvr via the back-end kernel tooling, but there's nothing to tell it when it needs to be re-fetched. Add pvr to the SRC_URI along with its current SRCREV, so the git fetcher can determine whether or not it needs to refetch the repo. Signed-off-by: Tom Zanussi <tom.zanussi@intel.com> diff --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend index dc15a5e..0a4095d 100644 --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend @@ -1,5 +1,7 @@ FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" +SRC_URI = "git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=${KBRANCH},meta,yocto/pvr;name=machine,meta,pvr" + COMPATIBLE_MACHINE_cedartrail = "cedartrail" KMACHINE_cedartrail = "yocto/standard/cedartrail" KERNEL_FEATURES_append_cedartrail += " cfg/smp.scc" @@ -13,6 +15,7 @@ KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc" SRCREV_machine_pn-linux-yocto_cedartrail ?= "81fd8c307997aff37916828dc8b4ef72f5d35a94" SRCREV_meta_pn-linux-yocto_cedartrail ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" +SRCREV_pvr_pn-linux-yocto_cedartrail ?= "9d0264753e869d21ec4d9a6dd5558de73d64f94d" SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= "81fd8c307997aff37916828dc8b4ef72f5d35a94" SRCREV_meta_pn-linux-yocto_cedartrail-nopvr ?= "a4ac64fe873f08ef718e2849b88914725dc99c1c" This is a single BSP failure, not a broad release blocking issue, reset priority accordingly. Just one thing to note - I don't have access to ab07 so can't show actual output: When I did the git clone command that you see in the temp/unpack_log exactly as entered, the resulting clone did not have the yocto/pvr branch, although the source clearly did. I'm either missing something or that shouldn't happen. My guess is that a from-scratch build would fix this, but then of course the underlying problem wouldn't get fixed. The patch in another comment didn't seem to do anything when tested locally in any case. Just a clarification, not a from-scratch build, but a from-scratch build, including removal of the git2_ tarball and the 3.0 kernel from the git2 dir. Basically, as I understand from Kishore et al, there's not a build problem outside of autobuilder, and I successfully built it before pulling it in in any case. But I will try to reproduce the problem locally regardless. I just gave a build from scratch and booted successfully today. I don't see any build failures. Not sure why Autobuild is giving build failures. Thanks Kishore. This turned out to be some "corrupted" data on the autobuilder where there were two copies of the git reprository, one with a ".git" extension and one without. We've fixed the fetcher and git to avoid this problem previously, this is a leftover artifact from that. cedartrail is now building green on the autobuilder. Seems ok now. |