linux/poky.git/meta/classes, branch yocto-3.1.10

sstate: Drop pseudo exclusion

2021-07-20T18:05:39+00:00

Now that pseudo-native always includes statx support and we have sanity checks on pseudo-native to ensure it always contains a minimum feature set, we no longer need to mark pseudo-native as distro specific. This fixes eSDK build problems. [YOCTO #14428] (From OE-Core rev: d7e87a5851d717da047f552be394d5712efa0402) Signed-off-by: Richard Purdie (cherry picked from commit 3279e43fcb469edb63c7c4eb60fdc565d5751f9d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

report-error: Drop pointless inherit

2021-07-15T14:27:49+00:00

The base class is always inherited, drop the unneeded inherit. (From OE-Core rev: cfd74f2bae51413d9c327e0f08ecf751325c2d74) Signed-off-by: Richard Purdie (cherry picked from commit 837d62c066589e5a12a0bf894ae7b24e8b048665) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

sstate/staging: Handle directory creation race issue

2021-07-10T21:46:19+00:00

The sstate code tries to be careful about racing around directory creation. In particular, the copyhardlinktree code creates the directory tree first allowing for "already exists" errors and ignoring them, then hardlinks the files in. Unfortunately the sstate removal code can race against this since it will try and remove empty directories. If there is some bad timing, a newly created directory can be removed before it was populated, leading to build failures. We could try and add locking but this would damage performance, we've been there before. It is also unclear where to actually place locks just based on the contents of a manifest file which may cover multiple sstate install locations for a given task. Instead, lets disable directory removal in the problematic "shared" core path. This could result in a few more empty directories being left on disk but those should be harmless and better than locking hurting performance or rare build races. [YOCTO #13999] [YOCTO #14379] (From OE-Core rev: fa49622521b6386d8031b1e7519f087aa9d99b19) Signed-off-by: Richard Purdie (cherry picked from commit 4f94d9296394bc7ce241439f00df86eb5912875f) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

sstate.bbclass: fix errors about read-only sstate mirrors

2021-07-10T21:46:19+00:00

If a read-only sstate mirror is used in conjunction with hash equiv, then OSError will be raised when an sstate-cache hit is achieved. This is because sstate_task_postfunc will try to "touch" the symlinks that point to the read-only sstate mirror when sstate_report_unihash has changed SSTATE_PKG. This commit adds an additional exception handler to silently mask read only rootfs errors thrown during the touch. The fix is also duplicated to sstate_eventhandler as the code is very similar but it may not be needed there. Example of the error: File: 'exec_python_func() autogenerated', lineno: 2, function: 0001: *** 0002:sstate_task_postfunc(d) 0003: File: '/poky/meta/classes/sstate.bbclass', lineno: 774, function: sstate_task_postfunc 0770: 0771: omask = os.umask(0o002) 0772: if omask != 0o002: 0773: bb.note("Using umask 0o002 (not %0o) for sstate packaging" % omask) *** 0774: sstate_package(shared_state, d) 0775: os.umask(omask) 0776: 0777: sstateinst = d.getVar("SSTATE_INSTDIR") 0778: d.setVar('SSTATE_FIXMEDIR', shared_state['fixmedir']) File: '/poky/meta/classes/sstate.bbclass', lineno: 703, function: sstate_package 0699: if not os.path.exists(siginfo): 0700: bb.siggen.dump_this_task(siginfo, d) 0701: else: 0702: try: *** 0703: os.utime(siginfo, None) 0704: except PermissionError: 0705: pass 0706: 0707: return Exception: OSError: [Errno 30] Read-only file system (From OE-Core rev: f2360f796016cce93610a080ff07c8047bda6ee8) Signed-off-by: Michael Ho Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie (cherry picked from commit 244b3be0358a66e0cca4016fe26144e3d7323390) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

package_pkgdata: Avoid task hash mismatches for generic task changes

2021-07-10T21:46:19+00:00

Add SSTATETASKS to package_prepare_pkgdata[vardepsexclude] since otherwise the task hashes vary depending upon which packaging backends are enabled and likely other changes which add/remove unrelated sstate tasks. (From OE-Core rev: fd94aa40e68189c41ef650d7fc9f4d4da686a4ad) Signed-off-by: Richard Purdie (cherry picked from commit 4011d31d4372639fd72ee0eefae210bf59c90d13) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel-devicetree: Fix interaction when packaging disabled

2021-07-10T21:46:19+00:00

When packaging is disabled using the nopackages class, ensure we don't add to PACKAGES. This fixes builds where we have an unpackaged kernel alongside a packaged kernel. (From OE-Core rev: 44756b6d92d922873fe1781e2cc1be3031cc5a86) Signed-off-by: Richard Purdie (cherry picked from commit d6b114cf5a9b22688c0b59a3afc46a07450d87b5) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel: Fix interaction when packaging disabled

2021-07-10T21:46:19+00:00

When packaging is disabled using the nopackages class, ensure we don't add to PACKAGES. This fixes builds where we have an unpackaged kernel alongside a packaged kernel. (From OE-Core rev: 6683b784d3258672c8d56c945db02ba37379cbf6) Signed-off-by: Richard Purdie (cherry picked from commit 2522daf22e2c27dd9c7926feda0345978217c6c3) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel.bbclass: fix do_sizecheck() comparison

2021-06-19T15:59:29+00:00

The routine do_sizecheck() was historically needed by legacy devices with limited flash memory. The lowest extreme is probably with Zaurus collie having exactly 1024*1024 = 1048576 bytes for the kernel partition. In the years the KERNEL_IMAGE_MAXSIZE has been converted to kilobytes thus rounded so we have now KERNEL_IMAGE_MAXSIZE_collie = "1024". The effect is that now the check fails because we hit curiously this | WARNING: This kernel zImage (size=1024(K) > 1024(K)) is too big for... even though zImage is 1047288 bytes (kernel + kexecboot-klibc-initramfs). Fix this case using test -gt (greater) instead of -ge (greater or equal). (From OE-Core rev: f5fc716d744745d5c2ea83f0b1d63907cfe04c06) Signed-off-by: Andrea Adami Signed-off-by: Richard Purdie (cherry picked from commit 254ca956d63b4ce6aa294213b60bb943f9f3a9e6) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags

2021-06-11T21:45:27+00:00

Currently DTC_FLAGS kernel makefile parameter can be specified directly on the command line by adding it to KERNEL_EXTRA_ARGS. However, this prevents scripts/Makefile.lib logic from appending flags that silence dtc warnings (all assignments done from within a makefile, to a variable specified on the command line, are ignored). Because of this, the do_compile log is cluttered with dtc warnings that should only be printed when compiling with W="123": ... /soc: node has a reg or ranges property, but no unit name /soc/gpu: missing or empty reg/ranges property /soc/firmware/gpio: missing or empty reg/ranges property ... To fix this, introduce the dedicated KERNEL_DTC_FLAGS variable to hold dtc flags and export DTC_FLAGS in the environment before generating the dtbs (make allows "+=" operations on variables that come from the environment, so the warnings are silenced properly). (From OE-Core rev: 2246b0d7a71c69eb2e89c55991d1387069895466) Signed-off-by: Ovidiu Panait Signed-off-by: Richard Purdie (cherry picked from commit 063b5de86624a42b0aa784db6dddc7552a6dee7f) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

kernel-fitimage: Don't use unit addresses on FIT

2021-06-11T21:45:27+00:00

Das U-Boot 2021.4-rc1 has the following commit: commit 3f04db891a353f4b127ed57279279f851c6b4917 Author: Simon Glass Date: Mon Feb 15 17:08:12 2021 -0700 image: Check for unit addresses in FITs Using unit addresses in a FIT is a security risk. Add a check for this and disallow it. CVE-2021-27138 Adjust the kernel-fitimage.bbclass accordingly to not use unit addresses. This changte is required before we can bump U-Boot to 2021.4. (From OE-Core rev: 14eec2f7c3bbb36de8198989bf772135aa117963) Signed-off-by: Klaus Heinrich Kiwi Signed-off-by: Richard Purdie [Backport for Dunfell] Signed-off-by: Frieder Schrempf Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie