| Summary: | FRI2: do_kernel_checkout failes for linux-libc-headers-yocto | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Saul Wold <sgw> |
| Component: | bsps-configuration | Assignee: | Bruce Ashfield <bruce.ashfield> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | High | CC: | dvhart, yp.bsp.watcher, yp.watcher |
| Version: | 1.2 | ||
| Target Milestone: | 1.2 M3 | ||
| Hardware: | Other | ||
| OS: | x86_64 | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | --- | |
|
Description
Saul Wold
2012-02-27 17:00:18 UTC
patch sent to the mailing list. There is more to it that what the patch addresses. Once we get past do_kernel_checkout, if the KBRANCH doesn't exist in the repository, then do_validate_branches craps out. This means new BSPs on newer kernels will cause the older linux-libc-headers-yocto to fail. We can use the tarball PREFERRED_VERSION workaround in these cases - but it seems to be we would be better off just PROVIDING linux-libc-headers in the linux-yocto* recipes. Then we have a guaranteed 1:1 mapping and don't have to jump through the checkout/validate hoops multiple times. No there shouldn't be more to this than my patch addresses. There is supposed to always be a default KBRANCH. I built and deployed this 10 or 11 times today alone, with the BSP in question. So there must be something different in the configurations. Maybe that I am now building for 3.2 which has a different branching hierarchy than 3.0 ? I could be. The recipe needs a bump regardless. So your comment stands (it shouldn't be PV of 2.6.37). I'll address that and see if I can reproduce the problem. We may be able to unify the libc-headers and the kernel recipe, but it does break the separation between the two that has traditionally been enforced Just logging the last run; NOTE: package linux-libc-headers-yocto-2.6.37+git-1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3_1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3-r4: task do_validate_branches: StartedNOTE: package linux-libc-headers-yocto-2.6.37+git-1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3_1+69cfbdf9f1ff461a75e5b77d6d7ba35e97db4cc3-r4: task do_validate_branches: SucceededNOTE: Running task 497 of 510 (ID: 3, /home/bruce/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb, do_patch) Can someone else confirm that my contrib branch (zedd/kernel) fixes the libc-header build ? Since clearly, my testing alone isn't sufficient. You want this change in particular: commit da4b543dc2f74f5172f1d7b3500d76f0ba81c8dd Author: Bruce Ashfield <bruce.ashfield@windriver.com> Date: Wed Feb 29 20:46:13 2012 -0500 linux-libc-headers-yocto: bump to v3.2.8 Making two changes for BSPs that prefer linux-libc-headers-yocto: - bumping to v3.2.8 headers - stubbing out unecessary linux-yocto functions when headers are being built Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> :100644 100644 734170f... 10b6b83... M meta/recipes-kernel/linux-libc-headers/linux-libc-headers-yocto_git.bb This is mostly what I did to fix it locally. The other change I made was to set the "bareclone=1" in the SRC_URI. This change makes it use "master" if the BSP doesn't exist. It seems like "standard/default/base" would be a better default. However, I tried that and couldn't find a way to change KBRANCH in the libc-headers recipe if the specified KBRANCH didn't exist in the git tree. I'll be doing a mass bareclone=1 change to all the linux-yocto* recipes, so for now, I kept it out of this fix. It'll be a complete switchover shortly. We actually do want standard/base, since standard/default/base gets us configuration fragments, which aren't used as part of the headers. So to keep it safe, sticking with standard/base to get any changes is what we want. My change should be setting it to standard/base, did you see something different ? Ah yes, it is standard/base, and this patch builds fri2 using a 3.2 kernel just fine. Acked-by: Darren Hart <dvhart@linux.intel.com> Sending patch to the list. bareclone to follow later. Marking as resolved. |