linux/poky.git/meta/classes/license_image.bbclass, branch hardknott

license_image.bbclass: Fix symlink to generic license files

2021-05-11T11:02:29+00:00

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: e24510fbb1439d56a278e2b5fc036d11a24e23df) Signed-off-by: Reto Schneider Signed-off-by: Richard Purdie (cherry picked from commit 64b1ba978e079c345e1f7fbd1bf44052fc3dd857) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

license_image.bbclass: Detect broken symlinks

2021-05-11T11:02:28+00:00

Find and report symlinks which point to a non-existing file. (From OE-Core rev: afeefde357e468ba79570208bd67d097b9cb9ee1) Signed-off-by: Reto Schneider Signed-off-by: Richard Purdie (cherry picked from commit 81809a1ffe67aade1b2ed66fe95044ffbf7d3df8) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

license_image: Don't canonicalise INCOMPATIBLE_LICENSE

2021-02-21T22:01:28+00:00

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

license_image.bbclass: Don't attempt to symlink to the same file

2021-02-06T09:03:00+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: fix missing recipeinfo on self

2021-01-13T23:13:46+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: use canonical name for license files

2020-11-24T10:27:44+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: Fix symlink to the image license manifest dir creation

2020-09-12T13:49:00+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: Create symlink to the image license manifest dir

2020-09-02T15:00:46+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: Report only the licenses that are incompatible

2019-12-16T23:25:50+00:00

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 Signed-off-by: Richard Purdie

license_image.bbclass: check and reject packages which have incompatible licenses

2019-10-15T13:16:10+00:00

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 Signed-off-by: Richard Purdie