If, e.g., license-file-missing is added to ERROR_QA, then the build
should fail if any licenses are missing.
(From OE-Core rev: 72aa42425e456ab0210129df01d829465acadb6d)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit dd91c4bec8335cab2bbd0b33caf50d314ca72bdc)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This re-writes the INCOMPATIBLE_LICENSE checking code to replace
the WHITELIST_<lic> with
INCOMPATIBLE_LICENSE_EXCEPTIONS = '<pkg>:<lic> <pkg>:<lic> ...'
This initial change leaves most of the code structure in place,
but the code in base.bbclass needs to be re-written to make
the check more consistent around packages (PKGS) and not recipe
names (PN). This also is taking into account the changes for SPDX
licenses.
The aim is to provide a mode consistent variable where the variable
name is known and can easily be queried.
(From OE-Core rev: 0d19c45ba6cf43518f380ca5afe9753a2eda0691)
Signed-off-by: Saul Wold <saul.wold@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use the same WARN_WA and ERROR_QA variables as insane.bbclass to allow
individual recipes, the distro or other configuration to determine
whether the various detected license errors should be treated as a
warning (as now) or as an error.
oe.qa.handle_error isn't immediately fatal, so oe.qa.exit_if_errors must
be called at the end of do_populate_lic to fail the task.
(From OE-Core rev: bb164adca94b5a43751aabe6b6d702a3d60dfdc7)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This fixes pkgdata PKGSIZE info after the overrides change.
(From OE-Core rev: 6964f06e48c7002c9ad788aa04bd8873fb3ee024)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This is the result of automated script conversion:
scripts/contrib/convert-overrides.py <oe-core directory>
converting the metadata to use ":" as the override character instead of "_".
(From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Installing license packages is similar to installing -dev or -dbg
packages, so let's invent a "lic-pkgs" IMAGE_FEATURE that does so and
document it in core-image.bbclass.
This image feature only works if LICENSE_CREATE_PACKAGE is set, so
refuse to generate an image if the lic-pkgs feature is enabled without
LICENSE_CREATE_PACKAGE.
(From OE-Core rev: eee8179f5b920d3f8907db23cbc061ed6770a02a)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Link to the canonical filename of a license as only this one exists.
Fixes commit 670fe71dd18ea675f35581db4a61fda137f8bf00
[license_image.bbclass: use canonical name for license files].
(From OE-Core rev: 64b1ba978e079c345e1f7fbd1bf44052fc3dd857)
Signed-off-by: Reto Schneider <reto.schneider@husqvarnagroup.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The code internally correctly handles canonicalisation of these license
fields, we shouldn't call it manually. The issue is that the fields can
contain wildcards and GPLv3* means something quite different to GPLv3-only*.
(From OE-Core rev: 957f48ce78ad1865653e8b8f25909a65ba8fc535)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-glibc/deploy/licenses/my-image-tdkz15'
First check to see if this is the case before attempting to create
the link.
(From OE-Core rev: 50f83fb542065eaf7a20ac07b63ae06441ada180)
Signed-off-by: Mike Looijmans <mike.looijmans@topic.nl>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Resolve a build bug where image recipes with a do_deploy task will fail.
If the image recipe inheriting license_image.bbclass has a deploy task, then
the function get_deployed_dependencies will add itself to the list of recipes
to get license information for.
However, image recipes don't generally deploy license info so this results in
an error.
File: '/nvme/poky/meta/classes/license_image.bbclass', lineno: 192, function: license_deployed_manifest
...
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/nvme/poky/build/tmp/deploy/licenses/core-image-minimal/recipeinfo'
Add a corner case to exclude the originating image recipe from the list of
dependencies to check.
(From OE-Core rev: 13fb39e49e55a0bc7c78b0bfdc372163b3f9e70a)
Signed-off-by: Michael Ho <Michael.Ho@bmw.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When copying license files to the image rootfs, i.e to
/usr/share/common-licenses, a canonical name of a license should be
used, otherwise duplicated files end up in common-licenses directory.
For example, GPL-2.0 license according to conf/license.conf can be
referenced in recipes as GPL-2, GPLv2, and GPLv2.0. If a license name is
used directly, we end up with three files in the rootfs with the same
content. If a canonical name used instead, then each license gets copied
only once.
(From OE-Core rev: 670fe71dd18ea675f35581db4a61fda137f8bf00)
Signed-off-by: Vyacheslav Yurkov <Vyacheslav.Yurkov@bruker.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If IMAGE_LINK_NAME is empty don't try to create the symlink.
[YOCTO #14042]
(From OE-Core rev: b54d92235408abdf0ba75a4d46329ec992af6006)
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the LICENSE_DIRECTORY each time an image recipe is built a new directory
is created to hold the image license manifests.
By creating a symlink to the most recent created image license manifest
directory, we make things easier for users to collect and pack the data.
(From OE-Core rev: 9c6a114213a80bebc2988ae8d39b296bce7f6982)
Signed-off-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Instead of reporting ${LICENSE} when a package cannot be installed
into an image because it is using an incompatible license, report the
license(s) that are actually incompatible.
(From OE-Core rev: b1863e570d4b169cd2f0ea7b4fe7c2348943cb2c)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The use case is setting INCOMPATIBLE_LICENSE per image,
rather than as an awkward, and too strict global setting.
This for example would allow building development images with gplv3 tools,
but production images without them, and checking that nothing gpl3-licensed
gets into the latter.
Examples are provided via the selftest: four scenarios are tested:
- bash is added to the image, with a default gpl3 license; this is rejected
- bash is added to the image, with a "gpl3 & other" license; this is also rejected
- bash is added to the image, with a "gpl3 | other" license; this is accepted, but
only 'other' is added to the license manifest (this was already handled correctly
previously).
- bash is added to the image with a default gpl3 license, and is additionally
whitelisted for that image; this is accepted.
Eventually, this would allow deprecating the meta-gplv2 layer, while still
enforcing the no-gpl3 rule where possible and needed.
(From OE-Core rev: fd50395bc0783a3cce7b5b0d7398f22783ebbeca)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These comments are not valid any more, drop them.
(From OE-Core rev: 39f5a3030a97bdf567ee11091dd4e95ef04585d7)
Signed-off-by: Ming Liu <liu.ming50@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A non-SPDX license (which is not an alias to an SPDX license) cannot
currently be marked as incompatible in INCOMPATIBLE_LICENSE.
In the current state, we take all INCOMPATIBLE_LICENSE and pass them
through expand_wildcard_licenses which is only adding SPDX licenses that
match the glob regexp of what is in INCOMPATIBLE_LICENSE (be it a direct
match to an SPDX license or via an alias).
This does not work well with custom licenses.
E.g.:
foo.bb:
LICENSE = "FooLicense"
conf/local.conf:
INCOMPATIBLE_LICENSE = "FooLicense"
`bitbake foo`
Gives no warning, no error, builds and packages successfully, because
INCOMPATIBLE_LICENSE is basically empty since FooLicense is neither in
SPDXLICENSEMAP nor in SRC_DISTRIBUTE_LICENSES.
Let's add the original licenses to the list returned by
expand_wildcard_licenses to be able to handle the aforementioned case.
INCOMPATIBLE_LICENSE = "FooLicense GPLv2 GPLv3+" used to "resolve" to
"GPLv2 GPLv3". It now resolves to "FooLicense GPLv2 GPLv3 GPLv3+" which
fixes the issue with custom licenses not being in SPDXLICENSEMAP or
SRC_DISTRIBUTE_LICENSES and thus being left out of the blacklisted
licenses.
I needed to pass a list to expand_wildcard_licenses from the
license_image class instead of the current output of map() because the
operator [:] does not work on this kind of type, and list(map()) or
anything that iterates over map() actually moves the iterator and breaks
the forloop right after in expand_wildcard_licenses.
(From OE-Core rev: 2d976587d703462db2b7b78661b05ac22fb93787)
Signed-off-by: Quentin Schulz <quentin.schulz@streamunlimited.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This change allows us to support the placement of WORKDIR and DEPLOY_DIR
on different devices.
(From OE-Core rev: f064a581ba31764839459bd667130bccbbedefab)
Signed-off-by: Paul Barker <paul@betafive.co.uk>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes up the permissions on the license files when they are put on the
target file system so that they are readable by everyone. Previously,
they would have inherited whatever permissions the file had in the
recipe, which may not have been appropriate.
[YOCTO #13175]
(From OE-Core rev: 8190d192fceb9b0969385507d3d4bca7be75c810)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There are various escape characters in these stings which python warns
about so use the correct regex markup for them.
(From OE-Core rev: 252b69c9f2abe3258366c540f56b156ed63e5437)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to set ownership of the license files after copying into the rootfs.
We also need to ensure we don't overwrite the rootfs files outside rootfs
generation, hence only write there when the new rootfs function parameter
is True.
[YOCTO #12961]
(From OE-Core rev: 6aa0eeaa4d31a440700f7695174de2a1dcc54866)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current code pokes into do_deploy manifests from do_image_complete when the
do_image_complete task may or may not depend upon the do_deploy tasks in question.
Often it gets lucky, sometimes it results in build failures.
To fix this, split the functionality to its own task which can have the correct
task dependencies. This means the data in BB_TASKDEPDATA is definitive, the other
code can be dropped, as can the IMAGE_EXTRATYPES do_populate_lic dependencies
from image.bbclass.
This fixes bugs which show up as:
NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Started
ERROR: core-image-minimal-1.0-r0 do_image_complete: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:write_deploy_manifest(d)
0003:
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 33, function: write_deploy_manifest
0029: 'w+').write(output)
0030:}
0031:
0032:python write_deploy_manifest() {
*** 0033: license_deployed_manifest(d)
0034:}
0035:
0036:python license_create_manifest() {
0037: import oe.packagedata
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 191, function: license_deployed_manifest
0187: # It is necessary to mark this will be used for image manifest
0188: man_dic[dep]["IMAGE_MANIFEST"] = True
0189: man_dic[dep]["PN"] = dep
0190: man_dic[dep]["FILES"] = \
*** 0191: " ".join(get_deployed_files(dep_dic[dep]))
0192: with open(os.path.join(lic_dir, dep, "recipeinfo"), "r") as f:
0193: for line in f.readlines():
0194: key,val = line.split(": ", 1)
0195: man_dic[dep][key] = val[:-1]
File: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/classes/license.bbclass', lineno: 289, function: get_deployed_files
0285: """
0286:
0287: dep_files = []
0288: excluded_files = []
*** 0289: with open(man_file, "r") as manifest:
0290: all_files = manifest.read()
0291: for f in all_files.splitlines():
0292: if ((not (os.path.islink(f) or os.path.isdir(f))) and
0293: not os.path.basename(f) in excluded_files):
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/sstate-control/manifest-qemux86_64-linux-yocto.deploy'
ERROR: core-image-minimal-1.0-r0 do_image_complete: Function failed: write_deploy_manifest
ERROR: Logfile of failure stored in: /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/build-st-730/tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0-r0/temp/log.do_image_complete.50537
NOTE: recipe core-image-minimal-1.0-r0: task do_image_complete: Failed
ERROR: Task (/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/images/core-image-minimal.bb:do_image_complete) failed with exit code '1'
NOTE: recipe linux-yocto-4.14.48+gitAUTOINC+d64aec9793_97c8063d2d-r0: task do_deploy: Succeeded
(From OE-Core rev: b54cdaea7844ee3bf0c39eb97cc7c4c17ed5818c)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This means the image code is only included in image recipes through
the IMAGE_CLASSES variable.
This sets things up to allow us to fix image deploy dependency problems.
(From OE-Core rev: fd44b8b4b2484f2d35c7a0e749e7dc316d601989)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
