Skip to content
  1. Jul 18, 2012
    • Bruce Ashfield's avatar
      kernel.bbclass: add non-santized kernel provides · 3f45ebc8
      Bruce Ashfield authored
      
      
      If the kernel version string uses characters or symbols that
      need to be santized for the package name, we can end up with a
      mismatch between module requirements and what the kernel
      provides.
      
      The kernel version is pulled from utsrelease.h, which contains
      the exact string that was passed to the kernel build, not
      one that is santized, this can result in:
      
       echo "CONFIG_LOCALVERSION="\"MYVER+snapshot_standard\" >> ${B}/.config
      
       <build>
      
       % rpm -qp kernel-module-uvesafb-3.4-r0.qemux86.rpm --requires
      update-modules
      kernel-3.4.3-MYVER+snapshot_standard
       % rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
      kernel-3.4.3-myver+snapshot-standard = 3.4-r0
      
      At rootfs assembly time, we'll have a dependency issue with the kernel
      providing the santizied string and the modules requiring the utsrelease.h
      string.
      
      To not break existing use cases, we can add a second provides to the
      kernel packaging with the unsantized version string, and allowing the
      kernel module packaging to be unchanged.
      
         RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"
      
       % rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
      kernel-3.4.3-MYVER+snapshot_standard
      kernel-3.4.3-myver+snapshot-standard = 3.4-r0
      
      Signed-off-by: default avatarBruce Ashfield <bruce.ashfield@windriver.com>
      Signed-off-by: default avatarMartin Jansa <Martin.Jansa@gmail.com>
      Signed-off-by: default avatarKoen Kooi <koen@dominion.thruhere.net>
      3f45ebc8
    • Darren Hart's avatar
      kernel: Add kernel headers to kernel-dev package · 8c724c4a
      Darren Hart authored
      
      
      [YOCTO #1614]
      
      Add the kernel headers to the kernel-dev package. This packages what was
      already built and kept in sysroots for building modules with bitbake.
      Making this available on the target requires removing some additional
      host binaries.
      
      Move the location to /usr/src/kernel
      
      Before use on the target, the user will need to:
      
          # cd /usr/src/kernel
          # make scripts
      
      This renders the kernel-misc recipe empty, so remove it.
      
      As we use /usr/src/kernel in several places (and I missed one in the
      previous version), add a KERNEL_SRC_DIR variable and use that throughout
      the class to avoid update errors in the future.
      
      Now that we package the kernel headers, drop the
      kernel_package_preprocess function which removed them from PKGD.
      
      All *-sdk image recipes include dev-pkgs, so the kernel-dev package will
      be installed by default on all such images.
      
      Signed-off-by: default avatarDarren Hart <dvhart@linux.intel.com>
      CC: Bruce Ashfield <bruce.ashfield@windriver.com>
      CC: Tom Zanussi <tom.zanussi@intel.com>
      CC: Khem Raj <raj.khem@gmail.com>
      Signed-off-by: default avatarMartin Jansa <Martin.Jansa@gmail.com>
      Signed-off-by: default avatarKoen Kooi <koen@dominion.thruhere.net>
      8c724c4a
    • Liang Li's avatar
      recipes-kernel: make perf a standalone package · 9ab875fb
      Liang Li authored
      
      
      perf has been coupled to the kernel packages via kernel.bbclass.
      While maintaining the build of perf out of the kernel source tree
      is desired the package coupling has proved to be awkward in
      several situations such as:
      
        - when a kernel recipe doesn't want to build/provide perf
        - when licensing of dependencies would prohibit perf and hence
          the kernel from being built.
      
      To solve some of these problems, this recipe is the extraction of
      the linux-tools.inc provided perf compilation into a standalone
      perf recipe that builds out of the kernel source, but is otherwise
      independent.
      
      No new functionality is provided above what the linux-tools.inc
      variant provided, but the separate recipe provides baseline for
      adding new functionality.
      
      Signed-off-by: default avatarLiang Li <liang.li@windriver.com>
      Signed-off-by: default avatarBruce Ashfield <bruce.ashfield@windriver.com>
      Signed-off-by: default avatarRichard Purdie <richard.purdie@linuxfoundation.org>
      Signed-off-by: default avatarMartin Jansa <Martin.Jansa@gmail.com>
      Signed-off-by: default avatarKoen Kooi <koen@dominion.thruhere.net>
      9ab875fb
    • Bruce Ashfield's avatar
      kernel: save $kerndir/tools and $kerndir/lib from pruning · 72c4d30d
      Bruce Ashfield authored
      
      
      The kernel source tree in the sysroot has all unecessary source
      code removed. The existing use case is to support module building
      out of the sysroot, but as more toolsa are moved into the kernel
      tree itself there are new use cases for the kernel sysroot source.
      
      To avoid putting dependencies on the kernel, and to be able to
      individually build and package these tools out of the source tree,
      we can save $kerndir/tools and $kernddir/lib from being removed.
      This enables tools like perf to be built our of the kernel source
      in the sysroot, without significantly increasing the amount of
      source in the sysroot.
      
      Signed-off-by: default avatarBruce Ashfield <bruce.ashfield@windriver.com>
      Signed-off-by: default avatarRichard Purdie <richard.purdie@linuxfoundation.org>
      Signed-off-by: default avatarMartin Jansa <Martin.Jansa@gmail.com>
      Signed-off-by: default avatarKoen Kooi <koen@dominion.thruhere.net>
      72c4d30d
    • Otavio Salvador's avatar
      cpuburn-neon: fix packaging to use a date as version and valid sources · a17cda6e
      Otavio Salvador authored
      
      
      * The package were not versioning the sources as the files had no
         version on its name. We workaround it mangling the DL_DIR;
      
       * We now dynamically check if the machine has or not neon feature and
         set COMPATIBLE_MACHINE.
      
      Signed-off-by: default avatarOtavio Salvador <otavio@ossystems.com.br>
      Signed-off-by: default avatarKoen Kooi <koen@dominion.thruhere.net>
      a17cda6e
  2. Jul 17, 2012
  3. Jul 16, 2012