From 3dd477c469af888cb222c160a5fda0f335c97acd Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Fri, 23 May 2014 18:35:56 +0300 Subject: ref-manual: Applied review edits to QA messages and insane.bbclass. Fixes [YOCTO #6159] Edits from Paul Eggleton included some reformatting, some minor wording tweaks, and edits to a couple tests as described in the insane.bbclass. (From yocto-docs rev: b42ef1bd51cb20f6bbb6bf812999e3a35b332339) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/ref-qa-checks.xml | 1370 +++++++++++++++++----------- 1 file changed, 860 insertions(+), 510 deletions(-) (limited to 'documentation/ref-manual/ref-qa-checks.xml') diff --git a/documentation/ref-manual/ref-qa-checks.xml b/documentation/ref-manual/ref-qa-checks.xml index 16203e6dbf..c31f9c792f 100644 --- a/documentation/ref-manual/ref-qa-checks.xml +++ b/documentation/ref-manual/ref-qa-checks.xml @@ -9,10 +9,19 @@ Introduction - Fixing QA issues in your recipes can take significant time and effort - when writing new recipes. - Sometimes you might be tempted to ignore a QA message or even to - disable these QA checks. + When building a recipe, the OpenEmbedded build system performs + various QA checks on the output to ensure that common issues are + detected and reported. + Some software builds that use new recipes complete with no problems. + However, some do not. + When issues are reported, it could take a little time + to resolve them. + + + + While it is tempting to ignore a QA message or even to + disable QA checks, it is best to try and resolve any + reported QA issues. This chapter provides a list of the QA messages and brief explanations of the issues you could encounter so that you can properly resolve problems. @@ -21,10 +30,17 @@ The next section provides a list of all QA error and warning messages based on a default configuration. - Each entry provides the message or error form along with an explanation. + Each entry provides the message or error form along with an + explanation. Notes + + At the end of each message, the name of the offending + QA test (as listed in the + "insane.bbclass" + section) appears within square brackets. + As mentioned, this list of error and warning messages is for QA checks only. @@ -45,700 +61,1013 @@ - - + + + <packagename>: <path> is using libexec please relocate to <libexecdir> [libexec] - - The specified package contains files in - /usr/libexec. - By default, libexecdir is set to - "${libdir}/${BPN}" rather than to "/usr/libexec". - Thus, installing to /usr/libexec - is likely not desirable. - + + + + + The specified package contains files in + /usr/libexec. + By default, libexecdir is set to + "${libdir}/${BPN}" rather than to "/usr/libexec". + Thus, installing to /usr/libexec + is likely not desirable. + + + +   + + - - + + + package <packagename> contains bad RPATH <rpath> in file <file> [rpaths] - - The specified binary produced by the recipe contains dynamic - library load paths (rpaths) that contain build system paths - such as - TMPDIR, - which could potentially be a security issue. - Check for bad -rpath options being passed - to the linker in your - do_compile - log. - Depending on the build system used by the software being built, - there might be a configure option to disable rpath usage - completely within the build of the software. - + + + + + The specified binary produced by the recipe contains dynamic + library load paths (rpaths) that contain build system paths + such as + TMPDIR, + which are incorrect for the target and could potentially + be a security issue. + Check for bad -rpath options being + passed to the linker in your + do_compile + log. + Depending on the build system used by the software being + built, there might be a configure option to disable rpath + usage completely within the build of the software. + + + +   + + - - + + + <packagename>: <file> contains probably-redundant RPATH <rpath> [useless-rpaths] - - The specified binary produced by the recipe contains dynamic - library load paths (rpaths) that on a standard system are - searched by default by the linker (e.g. - /lib and /usr/lib). - While these paths will not cause any breakage, they do waste - space and are unnecessary. - Depending on the build system used by the software being built, - there might be a configure option to disable rpath usage - completely within the build of the software. - + + + + + The specified binary produced by the recipe contains dynamic + library load paths (rpaths) that on a standard system are + searched by default by the linker (e.g. + /lib and /usr/lib). + While these paths will not cause any breakage, they do waste + space and are unnecessary. + Depending on the build system used by the software being + built, there might be a configure option to disable rpath + usage completely within the build of the software. + + + +   + + - - + + + non -dev/-dbg/-nativesdk package contains symlink .so: <packagename> path '<path>' [dev-so] - - Symlink .so files are for development - only, and should therefore go into the - -dev package. - This situation might occur if you add - *.so* rather than - *.so.* to a non-dev package. - Change - FILES - (and possibly - PACKAGES) - such that the specified .so file goes - into an appropriate -dev package. - + + + + + Symlink .so files are for development + only, and should therefore go into the + -dev package. + This situation might occur if you add + *.so* rather than + *.so.* to a non-dev package. + Change + FILES + (and possibly + PACKAGES) + such that the specified .so file goes + into an appropriate -dev package. + + + +   + + - - + + + non -staticdev package contains static .a library: <packagename> path '<path>' [staticdev] - - Static .a library files should go into - a -staticdev package. - Change - FILES - (and possibly - PACKAGES) - such that the specified .a file goes into - an appropriate -staticdev package. - + + + + + Static .a library files should go into + a -staticdev package. + Change + FILES + (and possibly + PACKAGES) + such that the specified .a file goes + into an appropriate -staticdev package. + + + +   + + - - + + + <packagename>: found library in wrong location [libdir] - - The specified file may have been installed into an incorrect - (possibly hardcoded) installation path. - For example, this test will catch recipes that install - /lib/bar.so when - ${base_libdir} is "lib32". - Another example is when recipes install - /usr/lib64/foo.so when - ${libdir} is "/usr/lib". - False positives occasionally exist. - For these cases add "libdir" to - INSANE_SKIP - for the package. - + + + + + The specified file may have been installed into an incorrect + (possibly hardcoded) installation path. + For example, this test will catch recipes that install + /lib/bar.so when + ${base_libdir} is "lib32". + Another example is when recipes install + /usr/lib64/foo.so when + ${libdir} is "/usr/lib". + False positives occasionally exist. + For these cases add "libdir" to + INSANE_SKIP + for the package. + + + +   + + - - + + + non debug package contains .debug directory: <packagename> path <path> [debug-files] - - The specified package contains a - .debug directory, which should not appear - in anything but the -dbg package. - This situation might occur if you add a path which contains - a .debug directory and do not explicitly - add the .debug directory to the - -dbg package. - If this is the case, add the .debug - directory explicitly to FILES_${PN}-dbg. - See - FILES - for additional information on FILES. - + + + + + The specified package contains a + .debug directory, which should not + appear in anything but the -dbg + package. + This situation might occur if you add a path which contains + a .debug directory and do not + explicitly add the .debug directory + to the -dbg package. + If this is the case, add the .debug + directory explicitly to + FILES_${PN}-dbg. + See + FILES + for additional information on FILES. + + + +   + + - - + + + Architecture did not match (<machine_arch> to <file_arch>) on <file> - - By default, the OpenEmbedded build system checks the Executable - and Linkable Format (ELF) type, bit size, and endianness of - any binaries to ensure they match the target architecture. - This test fails if any binaries do not match the type since - there would be an incompatibility. - The test could indicate that the wrong compiler or compiler - options have been used. - Sometimes software, like bootloaders, might need to bypass this - check. - If the file you receive the error for is firmware that is not - intended to be executed within the target operating system - or is intended to run on a separate processor within the - device, you can add "arch" to - INSANE_SKIP - for the package. - Another option is to check the - do_compile - log and verify that the - compiler options being used are correct. - + + + + + By default, the OpenEmbedded build system checks the + Executable and Linkable Format (ELF) type, bit size, and + endianness of any binaries to ensure they match the + target architecture. + This test fails if any binaries do not match the type since + there would be an incompatibility. + The test could indicate that the wrong compiler or compiler + options have been used. + Sometimes software, like bootloaders, might need to + bypass this check. + If the file you receive the error for is firmware + that is not intended to be executed within the target + operating system or is intended to run on a separate + processor within the device, you can add "arch" to + INSANE_SKIP + for the package. + Another option is to check the + do_compile + log and verify that the compiler options being used + are correct. + + + +   + + - - + + + Bit size did not match (<machine_bits> to <file_bits>) <recipe> on <file> - - By default, the OpenEmbedded build system checks the Executable - and Linkable Format (ELF) type, bit size, and endianness of - any binaries to ensure they match the target architecture. - This test fails if any binaries do not match the type since - there would be an incompatibility. - The test could indicate that the wrong compiler or compiler - options have been used. - Sometimes software, like bootloaders, might need to bypass this - check. - If the file you receive the error for is firmware that is not - intended to be executed within the target operating system - or is intended to run on a separate processor within the - device, you can add "arch" to - INSANE_SKIP - for the package. - Another option is to check the - do_compile - log and verify that the - compiler options being used are correct. - + + + + + By default, the OpenEmbedded build system checks + the Executable and Linkable Format (ELF) type, + bit size, and endianness of any binaries to ensure + they match the target architecture. + This test fails if any binaries do not match the type since + there would be an incompatibility. + The test could indicate that the wrong compiler or compiler + options have been used. + Sometimes software, like bootloaders, might need to + bypass this check. + If the file you receive the error for is firmware that + is not intended to be executed within the target + operating system or is intended to run on a separate + processor within the device, you can add "arch" to + INSANE_SKIP + for the package. + Another option is to check the + do_compile + log and verify that the compiler options being used are + correct. + + + +   + + - - + + + Endianness did not match (<machine_endianness> to <file_endianness>) on <file> [arch] - - By default, the OpenEmbedded build system checks the Executable - and Linkable Format (ELF) type, bit size, and endianness of - any binaries to ensure they match the target architecture. - This test fails if any binaries do not match the type since - there would be an incompatibility. - The test could indicate that the wrong compiler or compiler - options have been used. - Sometimes software, like bootloaders, might need to bypass this - check. - If the file you receive the error for is firmware that is not - intended to be executed within the target operating system - or is intended to run on a separate processor within the - device, you can add "arch" to - INSANE_SKIP - for the package. - Another option is to check the - do_compile - log and verify that the - compiler options being used are correct. - + + + + + By default, the OpenEmbedded build system checks + the Executable and Linkable Format (ELF) type, bit + size, and endianness of any binaries to ensure they + match the target architecture. + This test fails if any binaries do not match the type since + there would be an incompatibility. + The test could indicate that the wrong compiler or compiler + options have been used. + Sometimes software, like bootloaders, might need to + bypass this check. + If the file you receive the error for is firmware + that is not intended to be executed within the target + operating system or is intended to run on a separate + processor within the device, you can add "arch" to + INSANE_SKIP + for the package. + Another option is to check the + do_compile + log and verify that the compiler options being used + are correct. + + + +   + + - - + + + ELF binary '<file>' has relocations in .text [textrel] - - The specified ELF binary contains relocations in its - .text sections. - This situation can result in a performance impact at runtime. - - A bug currently exists that causes this warning to appear - erroneously. - See - - for more information. - - + + + + + The specified ELF binary contains relocations in its + .text sections. + This situation can result in a performance impact + at runtime. + + A bug currently exists that causes this + warning to appear erroneously. + See + + for more information. + + + + +   + + - - + + + No GNU_HASH in the elf binary: '<file>' [ldflags] - - This indicates that binaries produced when building the - recipe have not been linked with the - LDFLAGS - options provided by the build system. - Check to be sure that the LDFLAGS variable - is being passed to the linker command. - A common workaround for this situation is to pass in - LDFLAGS using - TARGET_CC_ARCH - within the recipe as follows: - + + + + + This indicates that binaries produced when building the + recipe have not been linked with the + LDFLAGS + options provided by the build system. + Check to be sure that the LDFLAGS + variable is being passed to the linker command. + A common workaround for this situation is to pass in + LDFLAGS using + TARGET_CC_ARCH + within the recipe as follows: + TARGET_CC_ARCH += "${LDFLAGS}" - - + + + + +   + + - - + + + Package <packagename> contains Xorg driver (<driver>) but no xorg-abi- dependencies [xorg-driver-abi] - - The specified package contains an Xorg driver, but does not - have a corresponding ABI package dependency. - The xserver-xorg recipe provides driver ABI names. - All drivers should depend on the ABI versions that they have - been built against. - Driver recipes that include - xorg-driver-input.inc or - xorg-driver-video.inc will automatically - get these versions. - Consequently, you should only need to explicitly add - dependencies to binary driver recipes. - + + + + + The specified package contains an Xorg driver, but does not + have a corresponding ABI package dependency. + The xserver-xorg recipe provides driver ABI names. + All drivers should depend on the ABI versions that they have + been built against. + Driver recipes that include + xorg-driver-input.inc or + xorg-driver-video.inc will + automatically get these versions. + Consequently, you should only need to explicitly add + dependencies to binary driver recipes. + + + +   + + - - + + + The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir] - - The /usr/share/info/dir should not be - packaged. - Add the following line to your - do_install - task or to your do_install_append within - the recipe as follows: - + + + + + The /usr/share/info/dir should not be + packaged. + Add the following line to your + do_install + task or to your do_install_append + within the recipe as follows: + rm ${D}${infodir}/dir - - + + + + +   + + - - + + + Symlink <path> in <packagename> points to TMPDIR [symlink-to-sysroot] - - The specified symlink points into - TMPDIR - on the host. - Such symlinks will work on the host. - However, they are clearly invalid when running on the target. - You should either correct the symlink to use a relative path - or remove the symlink. - + + + + + The specified symlink points into + TMPDIR + on the host. + Such symlinks will work on the host. + However, they are clearly invalid when running on + the target. + You should either correct the symlink to use a relative + path or remove the symlink. + + + +   + + - - + + + <file> failed sanity test (workdir) in path <path> [la] - - The specified .la file contains - TMPDIR - paths. - Any .la file containing these paths - is incorrect since libtool adds the - correct sysroot prefix when using the files automatically - itself. - + + + + + The specified .la file contains + TMPDIR + paths. + Any .la file containing these paths + is incorrect since libtool adds the + correct sysroot prefix when using the files automatically + itself. + + + +   + + - - + + + <file> failed sanity test (tmpdir) in path <path> [pkgconfig] - - The specified .pc file contains - TMPDIR/WORKDIR - paths. - Any .pc file containing these paths is - incorrect since pkg-config itself adds - the correct sysroot prefix when the files are accessed. - + + + + + The specified .pc file contains + TMPDIR/WORKDIR + paths. + Any .pc file containing these paths is + incorrect since pkg-config itself adds + the correct sysroot prefix when the files are accessed. + + + +   + + - - + + + <packagename> rdepends on <debug_packagename> [debug-deps] - - A dependency exists between the specified non-dbg package - (a package whose name does not end in - -dbg) and a package that is a - dbg package. - The dbg packages contain debug symbols - and are usually brought in using the dbg-pkgs - IMAGE_FEATURES - value or explicitly brought into the image using - IMAGE_INSTALL - (or as a dependency of another dbg - package brought in using either method). - The dependency might have been automatically added - (because the dbg package erroneously - contains files that it should not contain (e.g. a non-symlink - .so file) or it might have been added - manually (e.g. by adding to - RDEPENDS. - + + + + + A dependency exists between the specified non-dbg package + (i.e. a package whose name does not end in + -dbg) and a package that is a + dbg package. + The dbg packages contain debug symbols + that are brought in a number of ways: + + + Using the dbg-pkgs + IMAGE_FEATURES + value. + + + Using + IMAGE_INSTALL. + + + Using either of the previous methods + as a dependency of another + dbg package. + + + The dependency might have been automatically added + because the dbg package erroneously + contains files that it should not contain (e.g. a + non-symlink .so file) or it might + have been added manually (e.g. by adding to + RDEPENDS). + + + +   + + - - + + + <packagename> rdepends on <dev_packagename> [dev-deps] - - A dependency exists between the specified non-dev package - (a package whose name does not end in - -dev) and a package that is a - dev package. - The dev packages contain development - headers and are usually brought in using the dev-pkgs - IMAGE_FEATURES - value or explicitly brought into the image using - IMAGE_INSTALL - (or as a dependency of another dev - package brought in using either method). - The dependency might have been automatically added (because - the dev package erroneously contains - files that it should not have (e.g. a non-symlink - .so file) or it might have been added - manually (e.g. by adding to - RDEPENDS. - + + + + + A dependency exists between the specified non-dev package + (a package whose name does not end in + -dev) and a package that is a + dev package. + The dev packages contain development + headers and are usually brought in using the + dev-pkgs + IMAGE_FEATURES + value or explicitly brought into the image using + IMAGE_INSTALL + (or as a dependency of another dev + package brought in using either method). + The dependency might have been automatically added (because + the dev package erroneously contains + files that it should not have (e.g. a non-symlink + .so file) or it might have been added + manually (e.g. by adding to + RDEPENDS. + + + +   + + - - + + + <var>_<packagename> is invalid: <comparison> (<value>) only comparisons <, =, >, <=, and >= are allowed [dep-cmp] - - If you are adding a versioned dependency relationship to one - of the dependency variables - (RDEPENDS, - RRECOMMENDS, - RSUGGESTS, - RPROVIDES, - RREPLACES, - or - RCONFLICTS), - you must only use the named comparison operators. - Change the versioned dependency values you are adding to match - those listed in the message. - + + + + + If you are adding a versioned dependency relationship to one + of the dependency variables + (RDEPENDS, + RRECOMMENDS, + RSUGGESTS, + RPROVIDES, + RREPLACES, + or + RCONFLICTS), + you must only use the named comparison operators. + Change the versioned dependency values you are adding + to match those listed in the message. + + + +   + + - - + + + <recipename>: The compile log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [compile-host-path] - - The log for the - do_compile - task indicates that paths on the host were searched for files, - which is not appropriate when cross-compiling. - Look for "is unsafe for cross-compilation" or "CROSS COMPILE - Badness" in the specified log file. - + + + + + The log for the + do_compile + task indicates that paths on the host were searched + for files, which is not appropriate when cross-compiling. + Look for "is unsafe for cross-compilation" or "CROSS COMPILE + Badness" in the specified log file. + + + +   + + - - + + + <recipename>: The install log indicates that host include and/or library paths were used. Please check the log '<logfile>' for more information. [install-host-path] - - The log for the - do_install - task indicates that paths on the host were searched for files, - which is not appropriate when cross-compiling. - Look for "is unsafe for cross-compilation" or "CROSS COMPILE - Badness" in the specified log file. - + + + + + The log for the + do_install + task indicates that paths on the host were searched + for files, which is not appropriate when cross-compiling. + Look for "is unsafe for cross-compilation" + or "CROSS COMPILE Badness" in the specified log file. + + + +   + + - - + + + This autoconf log indicates errors, it looked at host include and/or library paths while determining system capabilities. Rerun configure task after fixing this. The path was '<path>' - - The log for the - do_configure - task indicates that paths on the host were searched for files, - which is not appropriate when cross-compiling. - Look for "is unsafe for cross-compilation" or "CROSS COMPILE - Badness" in the specified log file. - + + + + + The log for the + do_configure + task indicates that paths on the host were searched + for files, which is not appropriate when cross-compiling. + Look for "is unsafe for cross-compilation" or + "CROSS COMPILE Badness" in the specified log file. + + + +   + + - - + + + <packagename> doesn't match the [a-z0-9.+-]+ regex [pkgname] - - The convention within the OpenEmbedded build system is for - package names (sometimes enforced by the package manager itself) - to require that package names are all lower case and to - allow a restricted set of characters. - If your recipe name does not match this, or you add packages - to - PACKAGES - that do not conform to the convention, then you will receive - this error. - Rename your recipe. - Or, if you have added a non-conforming package name to - PACKAGES, change the package name - appropriately. - + + + + + The convention within the OpenEmbedded build system + (sometimes enforced by the package manager itself) is to + require that package names are all lower case + and to allow a restricted set of characters. + If your recipe name does not match this, or you add + packages to + PACKAGES + that do not conform to the convention, then you + will receive this error. + Rename your recipe. + Or, if you have added a non-conforming package name to + PACKAGES, change the package name + appropriately. + + + +   + + - - + + + <recipe>: configure was passed unrecognized options: <options> [unknown-configure-option] - - The configure script is reporting that the specified options - are unrecognized. - This situation could be because the options were previously - valid but have been removed. - Or, there was a mistake when the options were added and there - is another option that should be used instead. - If you are unsure, consult the upstream build documentation, - the ./configure ‐‐help output, - and the upstream change log or release notes. - Once you have worked out what the appropriate change is, you - can update - EXTRA_OECONF - or the individual - PACKAGECONFIG - option values accordingly. - + + + + + The configure script is reporting that the specified + options are unrecognized. + This situation could be because the options + were previously valid but have been removed from the + configure script. + Or, there was a mistake when the options were added + and there is another option that should be used instead. + If you are unsure, consult the upstream build + documentation, the + ./configure ‐‐help output, + and the upstream change log or release notes. + Once you have worked out what the appropriate + change is, you can update + EXTRA_OECONF + or the individual + PACKAGECONFIG + option values accordingly. + + + +   + + - - + + + Recipe <recipefile> has PN of "<recipename>" which is in OVERRIDES, this can result in unexpected behavior. [pn-overrides] - - The specified recipe has a name - (PN) - value that appears in - OVERRIDES. - If a recipe is named such that its PN - value matches something already in - OVERRIDES (e.g. PN - happens to be the same as - MACHINE - or - DISTRO), - it can have unexpected consequences. - For example, assignments such as - FILES_${PN} = "xyz" effectively turn into - FILES = "xyz". - Rename your recipe (or if PN is being - set explicitly, change the PN value) so - that the conflict does not occur. - See - FILES - for additional information. - + + + + + The specified recipe has a name + (PN) + value that appears in + OVERRIDES. + If a recipe is named such that its PN + value matches something already in + OVERRIDES (e.g. PN + happens to be the same as + MACHINE + or + DISTRO), + it can have unexpected consequences. + For example, assignments such as + FILES_${PN} = "xyz" effectively + turn into FILES = "xyz". + Rename your recipe (or if PN is being + set explicitly, change the PN value) so + that the conflict does not occur. + See + FILES + for additional information. + + + +   + + - - + + + <recipefile>: Variable <variable> is set as not being package specific, please fix this. [pkgvarcheck] - - Certain variables - (RDEPENDS, - RRECOMMENDS, - RSUGGESTS, - RCONFLICTS, - RPROVIDES, - RREPLACES, - FILES, - pkg_preinst, - pkg_postinst, - pkg_prerm, - pkg_postrm, and - ALLOW_EMPTY) - should always be set specific to a package (i.e. they should - be set with a package name override such as - RDEPENDS_${PN} = "value" rather than - RDEPENDS = "value"). - If you receive this error, correct any assignments to these - variables within your recipe. - + + + + + Certain variables + (RDEPENDS, + RRECOMMENDS, + RSUGGESTS, + RCONFLICTS, + RPROVIDES, + RREPLACES, + FILES, + pkg_preinst, + pkg_postinst, + pkg_prerm, + pkg_postrm, and + ALLOW_EMPTY) + should always be set specific to a package (i.e. they + should be set with a package name override such as + RDEPENDS_${PN} = "value" rather than + RDEPENDS = "value"). + If you receive this error, correct any assignments to these + variables within your recipe. + + + +   + + - - + + + File '<file>' from <recipename> was already stripped, this will prevent future debugging! [already-stripped] - - Produced binaries have already been stripped prior to the - build system extracting debug symbols. - It is common for upstream software projects to default to - stripping debug symbols for output binaries. - In order for debugging to work on the target using - -dbg packages, this stripping must be - disabled. - Depending on the build system used by the software being built, - disabling this stripping could be as easy as specifying an - additional configure option. - If not, disabling stripping might involve patching the build - scripts. - + + + + + Produced binaries have already been stripped prior to the + build system extracting debug symbols. + It is common for upstream software projects to default to + stripping debug symbols for output binaries. + In order for debugging to work on the target using + -dbg packages, this stripping must be + disabled. + Depending on the build system used by the software being + built, disabling this stripping could be as easy as + specifying an additional configure option. + If not, disabling stripping might involve patching + the build scripts. + + Disabling stripping here does not mean that the final + packaged binaries will be unstripped. + Once the OpenEmbedded build system splits out debug + symbols to the -dbg package, + it will then strip the symbols from the binaries. + + + + +   + + - - + + + <packagename> is listed in PACKAGES multiple times, this leads to packaging errors. [packages-list] - - Package names must appear only once in the - PACKAGES - variable. - You might receive this error if you are attempting to add a - package to PACKAGES that is - already in the variable's value. - + + + + + Package names must appear only once in the + PACKAGES + variable. + You might receive this error if you are attempting to add a + package to PACKAGES that is + already in the variable's value. + + + +   + + - - + + + FILES variable for package <packagename> contains '//' which is invalid. Attempting to fix this but you should correct the metadata. [files-invalid] - - The string "//" is invalid in a Unix path. - Correct all occurrences where this string appears in a - FILES - variable so that there is only a single "/". - + + + + + The string "//" is invalid in a Unix path. + Correct all occurrences where this string appears in a + FILES + variable so that there is only a single "/". + + + +   + + - - + + + <recipename>: Files/directories were installed but not shipped [installed-vs-shipped] - - Files have been installed within the - do_install - task but have not been included in any package by way of the - FILES - variable. - Files that do not appear in any package cannot be present in - an image later on in the build process. - You need to one of the following: - - - Add the files to FILES for the - package you want them to appear in (e.g. - FILES_${PN} for the main - package). - - - Delete the files at the end of the - do_install task if the files - are not needed in any package - - - + + + + + Files have been installed within the + do_install + task but have not been included in any package by way of the + FILES + variable. + Files that do not appear in any package cannot be present in + an image later on in the build process. + You need to one of the following: + + + Add the files to FILES for the + package you want them to appear in (e.g. + FILES_${PN} for the main + package). + + + Delete the files at the end of the + do_install task if the files + are not needed in any package. + + + + + +   + + - - + + + <oldpackage>-<oldpkgversion> was registered as shlib provider for <library>, changing it to <newpackage>-<newpkgversion> because it was built later - - This message means that both - <oldpackage> and - <newpackage> provide the specified - shared library. - You can expect this message when a recipe has been renamed. - However, if that is not the case, the message might indicate - that a private version of a library is being erroneously - picked up as the provider for a common library. - If that is the case, you should add the library's - .so file name to - PRIVATE_LIBS - in the recipe that provides - the private version of the library. - + + + + + This message means that both + <oldpackage> and + <newpackage> provide the specified + shared library. + You can expect this message when a recipe has been renamed. + However, if that is not the case, the message might indicate + that a private version of a library is being erroneously + picked up as the provider for a common library. + If that is the case, you should add the library's + .so file name to + PRIVATE_LIBS + in the recipe that provides + the private version of the library. + + @@ -782,6 +1111,27 @@ enabled by default: --> +
+ Configuring and Disabling QA Checks + + + You can configure the sanity checks so that specific test failures + either raise a warning or an error message. + You can also use the + WARN_QA and + ERROR_QA + variables to configure warning and error reporting. + For information on how to work with the QA checks, see the + "insane.bbclass" + section. + Tip + Please keep in mind that the QA checks exist in order to + detect real or potential problems in the packaged output. + So exercise caution when disabling these checks. + + +
+