linux/poky.git/meta/lib/oe/utils.py, branch 5.0_M1

sstate: Ensure sstate searches update file mtime

2023-11-08T10:56:35+00:00

Commands like "bitbake XXX -S printdiff" search for sstate files but don't download them. This means that local files aren't touched as the download code would do, meaning the sstate cleanup scripts can delete them. This can then lead to obtuse build failures. Have the search code touch local files in the same way as the main code paths would to avoid these files disappearing. Move the function to a common touch() function in lib/oe instead of duplicating code. (From OE-Core rev: a27fc0bd5706ab5b9c68a0271fcf57377a678cdf) Signed-off-by: Richard Purdie

lib/oe/utils: Refactor to make multiprocess_launch callable without d

2023-09-12T11:44:47+00:00

This is a preparation for making the strip_execs function callable from devtool without going via tinfoil and a bitbake server process. (From OE-Core rev: af8ee73cdef90b83556a7ac5e139a08108706486) Signed-off-by: Adrian Freihofer Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

classes: Drop ';' delimiter from ROOTFS/IMAGE*COMMAND variables

2023-09-09T21:14:41+00:00

Originally these were shell functions but they have long since been processed by bb.build.exec_func(). Since we no longer need shell syntax, we can drop the ';' delimiters and just use a space separated string. This cleans up the variable and quietly removes any stray ';' that do happen to still make it in. (From OE-Core rev: c3365dfd9ddd7fbe70b62e0f11166e57a8ca6f73) Signed-off-by: Richard Purdie

lib: Add copyright statements to files without one

2022-08-12T11:00:43+00:00

Where there isn't a copyright statement, add one to make it explicit. Also add license identifiers as MIT if there isn't one. (From OE-Core rev: bb731d1f3d2a1d50ec0aed864dbca54cf795b040) Signed-off-by: Richard Purdie

oe/utils: remove the ThreadedPool

2022-07-15T16:51:34+00:00

The ThreadedPool in OE-core is mainly because python2 doesn't have threaded pools but python2 is dead for some time now and python3 have a ThreadPoolExecutor. The only local in OE-core where this ThreadedPool is in use is on the sstate.bbclass that is ported to the python3 ThreadPoolExecutor. (From OE-Core rev: aa8fd5e7c2a1125895accfd55ce9320819a10959) Signed-off-by: Jose Quaresma Signed-off-by: Richard Purdie

meta/scripts: Improve internal variable naming

2022-03-10T08:00:28+00:00

Update internal variable names to improve the terms used. (From OE-Core rev: f408068e5d7998ae165f3002e51bc54b380b8099) Signed-off-by: Saul Wold Signed-off-by: Richard Purdie

prelink: Drop support for it

2022-02-05T12:26:36+00:00

Prelink is being dropped by glibc in 2.36. It already causes issues with binary corruption, has a number of open bugs and is of questionable benefit without disabling load address randomization and PIE executables. We disabled it by default a while back but left people able to use it. We would be unable to maintain it alone without glibc support so remove the remaining pieces. (From OE-Core rev: 23c0be78106f1d1e2bb9c724174a1bb8c56c2469) Signed-off-by: Richard Purdie

oe/utils: by default cap cpu_count() to 64 cores

2021-11-25T21:55:10+00:00

Larger systems may have large numbers of cores, but beyond a certain point they can't all be used for compiling: whilst purely compute-intensive jobs can be parallelised to hundreds of cores, operations such as compressing (needs lots of RAM) or compiling (lots of I/O) don't scale linearly. For example, the Marvel ThunderX2 has 32 cores, each capable of executing four threads, and can be configured with two sockets, making 256 CPUs according to Linux. Zstd using 256 threads has been seen to fail to allocate memory during even small recipes such as iso-codes. Add a default cap of 64 CPUs to the cpu_count() method so that extreme parallisation is limited. 64 is high enough that meaningful gains beyond it are unlikely, but high enough that most systems won't be effected. (From OE-Core rev: 765d0f25ce48636b1838a5968e2dc15de2127428) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe/utils: allow naming threads in ThreadedPool

2021-11-25T21:55:10+00:00

When looking at logs involving thread pools it is useful if the threads can be named. (From OE-Core rev: 18342945b021608794d83ecf567afd43f4379b24) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

oe/utils: log exceptions in ThreadedWorker functions

2021-10-18T12:48:16+00:00

If the function a ThreadedWorker is executing raises an exception, don't use print() as that mostly disappears. Instead, output it to the logger. This is done using bb.mainlogger.debug directly instead of bb.debug() as this allows us to pass the exception instance directly, which is then incorporated into the log stream. (From OE-Core rev: 2f1ea25c222b344dd8b784b2bc73a6540ab30274) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie