aboutsummaryrefslogtreecommitdiffstats
path: root/meta/recipes-kernel/kmod/depmodwrapper-cross_1.0.bb
AgeCommit message (Collapse)Author
2016-02-28depmodwrapper-cross: nopackages to avoid QA [buildpaths] issueHongxu Jia
This depmodwrapper is a wrapper script to support install-corss, which is invoked at do_rootfs time. So the depmodwrapper-cross should not generate packages. The fix could avoids QA buildpaths issue. [YOCTO #7058] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-07-16depmodwrapper-cross: set S correctlyRoss Burton
This recipe doesn't unpack any source, so set S to ${WORKDIR}. Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-01-29kernel: Fix depmod for multilibRichard Purdie
Using populate_sysroot for this data was a nice idea but flawed as it doesn't work in multilib builds. Instead we can use PKGDATA_DIR since this is consistent over multilib builds. It also turns out to be slightly neater code too. Hopefully this resolves the problem once and for all. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-23kernel/image/depmodwrapper: Fixups for depmodRichard Purdie
With the rpm package backend enabled, running: bitbake <image> bitbake virtual/kernel -c clean bitbake <image> -c rootfs -f results in an image with incorrect kernel module dependency information. The problem is that the System.map and kernel-abiversion files are needed for depmod and after the recent kernel changes, these are no longer in sstate. Its reasonable to require the kernel to unpack/build if you're about to build a module against it. It is not reasonable to require this just to build a rootfs. Therefore stash the needed files specifically for depmod. Also fix some STAGING_KERNEL_DIR references which were incorrect, found whilst sorting through his change. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-17depmodwrapper-cross: Update to use STAGING_KERNEL_BUILDDIRRichard Purdie
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-01-02Replace one-line DESCRIPTION with SUMMARYPaul Eggleton
A lot of our recipes had short one-line DESCRIPTION values and no SUMMARY value set. In this case it's much better to just set SUMMARY since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY is at least useful. I also took the opportunity to fix up a lot of the new SUMMARY values, making them concisely explain the function of the recipe / package where possible. Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
2013-10-30recipes: Remove PR = r0 from all recipesRichard Purdie
Remove all PR = "r0" from all .bb files in oe-core. This was done with the command sed -e '/^PR.*=.*r0\"/d' recipes*/*/*.bb -i We've switching to the PR server, PR bumps are no longer needed and this saves people either accidentally bumping them or forgetting to remove the lines (r0 is the default anyway). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-03-02depmodwrapper-cross: Mark as machine specificRichard Purdie
The kernel and its staging directory are machine specific so the wrapper needs to be as well. Also take the opportunity to remove the default dependencies of the recipe since its a script and doesn't need the cross compiler. This gives the build a little more scheduing freedom. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2013-03-01module.bbclass: Create a new depmodwrapper to assist cross-installsMark Hatle
Previously the build path to STAGING_KERNEL_DIR was being embedded into the package post install scripts. We avoid this behavior by generating a special depmodwrapper script. This script contains that hard-coded path, ensuring that re-use of the sstate-cache (and/or packages) will always run through the wrapper generated by the current build with a checksum that includes STAGING_KERNEL_DIR. [ YOCTO #3962 ] Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>