CODEWITHSUNDEEP
yoctobitbake
Kees Trommel
Kees Trommel

Reputation: 53

Yocto linux module recipe do_package_qa error

A Linux kernel module recipe that worked fine in the Yocto version of the Freescale/NXP SDK v1.8 causes an error in do_package_qa when using the Yocto version of the Freescale/NXP SDK v2.0. As follows the error:

ERROR: QA Issue: FILES in kernel-module-r8168 recipe should not contain the ${D} variable as it references the local build directory not the target filesystem, best solution is to remove the ${D} reference [expanded-d]
ERROR: QA run found fatal errors. Please consider fixing them.
ERROR: Function failed: do_package_qa

The kernel module recipe itself does not contain ${D} but it is used in the module.bbclass from which my module recipe inherits

As follows my module recipe:

SUMMARY = "Realtek r8168 family driver Linux kernel module" 
LICENSE = "GPLv2" 
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"

inherit module

PN = "r8168" 
PV = "8.041.01"

SRC_URI = "file://r8168-8.041.01.tgz \
           file://COPYING \
          "

SRC_URI[md5sum] = "f3fd1530132ed1b64345698f89beea0f"

S = "${WORKDIR}"

KERNEL_MODULE_AUTOLOAD += "r8168"

I found that the ${D} variable check has been added in the SDK 2.0 Yocto version of insane.bbclass compared with the SDK 1.8 Yocto version.

I have the following questions:

  1. Is this a bug in Yocto?
  2. How can I work around it or fix it?

log.do_package_qa.526:

DEBUG: Executing python function sstate_task_prefunc
DEBUG: Python function sstate_task_prefunc finished
DEBUG: Executing python function do_package_qa
NOTE: DO PACKAGE QA
DEBUG: Executing python function read_subpackage_metadata
DEBUG: Python function read_subpackage_metadata finished
NOTE: Checking Package: r8168
NOTE: Checking Package: r8168-doc
NOTE: Checking Package: r8168-dbg
NOTE: Checking Package: r8168-staticdev
NOTE: Checking Package: r8168-locale
NOTE: Checking Package: r8168-dev
NOTE: Checking Package: kernel-module-r8168
NOTE: arm-fsl-linux-gnueabi-objdump -p /local/ctrommel/QorIQ-SDK-V2.0-20160527-yocto/build_ls1021atwr/tmp/work/ls1021at
wr-fsl-linux-gnueabi/r8168/8.041.01-r0/packages-split/kernel-module-r8168/lib/modules/4.1.8-rt8+gbd51baf/local/ctrommel
/QorIQ-SDK-V2.0-20160527-yocto/build_ls1021atwr/tmp/work/ls1021atwr-fsl-linux-gnueabi/r8168/8.041.01-r0/image/r8168.ko
ERROR: QA Issue: FILES in kernel-module-r8168 recipe should not contain the ${D} variable as it references the local bu
ild directory not the target filesystem, best solution is to remove the ${D} reference [expanded-d]
ERROR: QA run found fatal errors. Please consider fixing them.
DEBUG: Python function do_package_qa finished
ERROR: Function failed: do_package_qa

Upvotes: 1

Views: 4990

Answers (3)

Kees Trommel
Kees Trommel

Reputation: 53

It is not a Yocto bug. It was problem in the Makefile of the added module. This Makefile is a modified version of the Makefile of the driver provided by the vendor of the device. The original Makefile contained the make flag INSTALL_MOD_DIR and the value was modified to INSTALL_MOD_DIR=$(INSTALL_MOD_PATH). It was assumed that INSTALL_MOD_PATH was the target module install path however it is the host module install path that contains ${D}. So the error raised by Yocto was correct. Removing the make flag from the Makefile fixed the problem.

Upvotes: 1

Kees Trommel
Kees Trommel

Reputation: 53

Adding the following line to the module recipe will work around this issue:

INSANE_SKIP_kernel-module-${PN} = "expanded-d"

Because the build was successful (module was added to the image) after skipping the QA check I am more convinced that this is a bug.

Upvotes: 0

bluelightning
bluelightning

Reputation: 471

Somewhere you will find there is a reference to ${D} in the value of FILES for one of the packages - this is incorrect. FILES is meant to specify paths as they would appear on the target, so you wouldn't prefix them with the temporary install directory ${D}.

I can't say for sure where this would be - it's unlikely to be part of the Yocto Project provided metadata, but bitbake -e yourrecipe | less and then search (using '/') for \$\{D\} and you should be able to see exactly where the offending value is being set.

Upvotes: 0

Related Questions