linux/poky.git/meta/classes, branch 3.3_M1

metadata_scm: Fix signature handling of METADATA_REVISION and METADATA_BRANCH

2020-12-09T17:32:51+00:00

We're not interested in the dependencies of these functions and what those functions look like, we're interested in the value the variable has. Force the hashed value to be the actual value from the function. This means using METADATA_REVISION in DISTRO_VERSION for example now correctly rebuilds when it changes value. (From OE-Core rev: 005651dc782859c01f170fb974811b2a13cb2cef) Signed-off-by: Richard Purdie

kernel-module-split.bbclass: fix kernel modules getting marked as CONFFILES

2020-12-09T12:20:33+00:00

Yi pointed out that commit 1a70a92d1f10 ("kernel-module-split.bbclass: identify kernel modconf files as configuration files") is unintentionally adding the actual kernel /lib/modules .ko files to the CONFFILES variable. The root cause is the re-use of the 'files' variable in that commit. Fix it by using a separate variable to keep track of the generated module .conf files that need to be marked as configuration files. Fixes: 1a70a92d1f10 ("kernel-module-split.bbclass: identify kernel modconf files as configuration files") Reported-by: Yi Zhao (From OE-Core rev: db5f2ca532db4f0d2e05b7cb5f9d146e1dd76ab3) Signed-off-by: Gratian Crisan Signed-off-by: Richard Purdie

populate_sdk_ext: use SDK_CUSTOM_TEPLATECONF variable to enable custom templateconf.cfg

2020-12-09T12:20:33+00:00

The current implementation will always pick an existing templateconf.cfg if present else it will use the one from OE. A user might not always want to pick an existing tempalteconf.cfg even if its present. Introduce SDK_CUSTOM_TEMPLATECONF variable to provide an option for the user to specify if he wants to use an existing custom templateconf.cfg or not If SDK_CUSTOM_TEMPLATECONF=='1' then enable custom templateconf.cfg. By default SDK_CUSTOM_TEMPLATECONF is set to '0' (From OE-Core rev: d0f863a24d05bddeb21e181fb01fa0051c79d7d8) Signed-off-by: Sai Hari Chandana Kalluri Signed-off-by: Richard Purdie

systemd.bbclass: update command to check systemctl available

2020-12-06T23:17:28+00:00

When use a core image with systemd as docker image, it fails to install/remove package which calls systemctl in post scripts. It fails to run systemctl in a container: bash-5.0# systemctl System has not been booted with systemd as init system (PID 1). Can't operate. Failed to connect to bus: Host is down So replace the criterion command 'type systemctl' with 'systemctl' in package post scripts to check whether systemctl available. (From OE-Core rev: a52e66762c0c51918b1ba3d4622759637b6e920a) Signed-off-by: Kai Kang Signed-off-by: Richard Purdie

image_types: sort tarball file listings

2020-12-03T22:53:09+00:00

Help rootfs tarballs be reproducible by sorting the file listing. (From OE-Core rev: 4fa68626bbcfd9795577e1426c27d00f4d9d1c17) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

image_types: remove obsolete tar comment

2020-12-03T22:53:09+00:00

We now depend on tar 1.28, so talking about older tar versions is just confusing. (From OE-Core rev: f19e43dec63a86c200e04ba14393583588550380) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/buildhistory: record LICENSE

2020-11-29T20:24:32+00:00

Buildhistory stores various bits of information at both recipe and package level, while there is an associated license manifest directory tree it would require additional scripting to extract that information. (From OE-Core rev: 909bafef282f00dd4a83fab0569885e9788a4ed9) Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

uninative: Don't use single sstate for pseudo-native

2020-11-24T15:53:07+00:00

pseudo-native is a bit special. It conditionally compiles in support for xattr, statx and statvfs amongst other options. If a pseudo-native binary is used on a system where these functions are present but it wasn't compiled in we see hard to debug permissions problems. An example is the devtool.DevtoolExtractTests.test_devtool_deploy_target oe-selftest which shows a cryptic error: File "/home/pokybuild/yocto-worker/oe-selftest-fedora/build/meta/lib/oeqa/selftest/cases/devtool.py", line 1388, in test_devtool_deploy_target self.assertEqual(filelist1, filelist2) File "/usr/lib64/python3.9/unittest/case.py", line 831, in assertEqual assertion_func(first, second, msg=msg) File "/usr/lib64/python3.9/unittest/case.py", line 1037, in assertListEqual self.assertSequenceEqual(list1, list2, msg, seq_type=list) File "/usr/lib64/python3.9/unittest/case.py", line 1019, in assertSequenceEqual self.fail(msg) File "/usr/lib64/python3.9/unittest/case.py", line 670, in fail raise self.failureException(msg) AssertionError: Lists differ: ['-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8'] != ['-rwxr-xr-x root root /etc/init.d/mdmonitor', '-rw-r-[10124 chars]n.8'] First differing element 0: '-rwxr-xr-x 6000 6000 /etc/init.d/mdmonitor' '-rwxr-xr-x root root /etc/init.d/mdmonitor' This is due to a version of pseudo without statx being used on a system where ls uses statx, hence the files are displayed as 6000.6000 instead of root.root. Avoid this by always building pseudo-native for the specific distro in question rather than using a universal sstate feed. This hopefully fixes one of the mysterious AB-INT issues. (From OE-Core rev: 6e3785a3f1f3cf68f5fe101cd6bebe91db165973) Signed-off-by: Richard Purdie

fs-perms: Ensure /usr/src/debug/ file modes are correct

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

If files are copied into /usr/src/debug directly from WORKDIR (e.g. makedevs) we'd get the permissions from the checkout which would depend on the host umask. Avoid this and be deterministic by setting the file modes consistently. Core code copies the files in so we're responsible for the permissions. Unfortunately to force this change to apply we need to invalidate both the package tasks and the hash equivalance mappings since file mode 'corruption' already made it into the output hashes (both input options were mapped to the output hashes). (From OE-Core rev: 1f958bcd6c9cd12ec76d80586cba15f4d6ed17a7) Signed-off-by: Richard Purdie

kernel-uboot: allow compression option to be configurable

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

While some platforms might choose to compress the kernel by default especially when boot medium is slow, others want uncompressed kernel. The choice of decompression speed vs. load speed is very platform dependent. Allow platform to choose the option here. (From OE-Core rev: 5c72105e2973e613b5c0f0e6310ffdea6e56c6c7) Signed-off-by: Sinan Kaya Signed-off-by: Richard Purdie