summaryrefslogtreecommitdiffstats
path: root/meta/classes-recipe/kernelsrc.bbclass
Commit message (Collapse)AuthorAgeFilesLines
* The poky repository master branch is no longer being updated.Richard Purdie2025-11-071-21/+0
| | | | | | | | | | | | | | | | | | | | | You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernelsrc/perf: clean up package version while using kernel sourceHongxu Jia2025-07-031-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If recipe inherits bbclass kernelsrc to use kernel sources, the recipe should explicitly set ${KERNEL_VERSION} to ${PKGV} in task do_package, otherwise package version (${PV} is usually default 1.0) is not consistent with kernel source. For example, there are 5 recipes in meta-openembedded to inherit kernelsrc, but 4 recipes explicitly set PKGV. meta-openembedded$ grep -e "setVar(.*PKGV.*KERNEL_VERSION" -e kernelsrc -rn * meta-oe/recipes-kernel/intel-speed-select/intel-speed-select.bb:9:inherit kernelsrc meta-oe/recipes-kernel/bpftool/bpftool.bb:8:inherit bash-completion kernelsrc kernel-arch meta-oe/recipes-kernel/bpftool/bpftool.bb:44: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/cpupower/cpupower.bb:8:inherit kernelsrc kernel-arch bash-completion meta-oe/recipes-kernel/cpupower/cpupower.bb:32: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/turbostat/turbostat.bb:98: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/usbip-tools/usbip-tools.bb:25:inherit kernelsrc autotools-brokensep meta-oe/recipes-kernel/usbip-tools/usbip-tools.bb:68: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) meta-oe/recipes-kernel/spidev-test/spidev-test.bb:7:inherit bash-completion kernelsrc kernel-arch meta-oe/recipes-kernel/spidev-test/spidev-test.bb:26: d.setVar('PKGV', d.getVar("KERNEL_VERSION").split("-")[0]) This commit clean up the setting of PKGV, move it to kernelsrc.bbclass for common use, the recipe (such as intel-speed-select) that inherited kernelsrc will not be required to explicitly set ${PKGV} with ${KERNEL_VERSION} (From OE-Core rev: 77a93e8cf1da4231341c56f64f9d4d474f9f2bb7) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel: make LOCALVERSION consistent between recipesBruce Ashfield2023-07-251-0/+1
| | | | | | | | | | | | | | | | | | | | | The initial fix for localversion setting in 6.3+ broke older recipes and also broke recipes setting localversion in a kernel recipe, as make-mod-scripts (and other locations) can trigger a regeneration of files and don't have access to the variable. Moving the setting of this variable to the global namespace doesn't make sense, so we follow the example of the kernel-abiversion and save a kernel-localversion to the build artifacts. Recipes that may regenerate scripts/dynamic files, must depend on the do_shared_workedir of the kernel and use the helper function to read the file storing the localversion. (From OE-Core rev: b378eec156998eea55ba61e59103cb34fab0d07c) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes: Update classes to match new bitbake class scope functionalityRichard Purdie2022-08-121-0/+16
Move classes to classes-global or classes-recipe as appropriate to take advantage of new bitbake functionality to check class scope/usage. (From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>