linux/poky.git/meta/lib/oe/utils.py, branch warrior-21.0.3

meta/lib+scripts: Convert to SPDX license headers

2019-06-18T10:28:58+00:00

This adds SPDX license headers in place of the wide assortment of things currently in our script headers. We default to GPL-2.0-only except for the oeqa code where it was clearly submitted and marked as MIT on the most part or some scripts which had the "or later" GPL versioning. The patch also drops other obsolete bits of file headers where they were encoountered such as editor modelines, obsolete maintainer information or the phrase "All rights reserved" which is now obsolete and not required in copyright headers (in this case its actually confusing for licensing as all rights were not reserved). More work is needed for OE-Core but this takes care of the bulk of the scripts and meta/lib directories. The top level LICENSE files are tweaked to match the new structure and the SPDX naming. (From OE-Core rev: 3248a9e3c5a197321b1c4417509b9309cc3bae97) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

utils/multiprocess_launch: Improve failing subprocess output

2019-05-12T08:13:39+00:00

Output before this patch: ERROR: bash-4.4.18-r0 do_package_write_ipk: Fatal errors occurred in subprocesses: Command 'PATH="X" opkg-build -Z xz -a "--memlimit=50% --threads=88" Foobar /media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64' returned non-zero exit status 1.: Traceback (most recent call last): File "/media/build1/poky/meta/lib/oe/utils.py", line 272, in run ret = self._target(*self._args, **self._kwargs) File "/media/build1/poky/meta/classes/package_ipk.bbclass", line 230, in ipk_write_pkg shell=True) File "/usr/lib/python3.6/subprocess.py", line 336, in check_output **kwargs).stdout File "/usr/lib/python3.6/subprocess.py", line 418, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command 'PATH="X" opkg-build -Z xz -a "--memlimit=50% --threads=88" Foobar /media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64' returned non-zero exit status 1. Note how stdout/stderr from the failing command isn't shown. After this patch: ERROR: bash-4.4.18-r0 do_package_write_ipk: Fatal errors occurred in subprocesses: Command 'PATH="X" opkg-build -Z xz -a "--memlimit=50% --threads=88" Foobar /media/build1/poky/build/nodistro-glibc/work/core2-64-oe-linux/bash/4.4.18-r0/deploy-ipks/core2-64' returned non-zero exit status 1. Subprocess output:Foobar *** Error: Package name Foobar contains illegal characters, (other than [a-z0-9.+-]) opkg-build: Please fix the above errors and try again. We suddenly get a much more usable error message. The traceback is supressed as its distracting from the real problem in this case. Ideally python itself would handle this but it doesn't so we have to wrap the exception. We already do this in bitbake itself for the same reason. (From OE-Core rev: c27cc2355d331e063f170b45728671988a967deb) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

lib/oe/utils: Make prune_suffix prune a suffix

2019-04-09T12:44:39+00:00

... instead of replacing a substring that could happen more than once and not only when it ends with it. Do the same for the prefix. See related https://github.com/openembedded/bitbake/pull/24 . There it stops replacing sufixes once first one is matched but not here. (From OE-Core rev: 610ac84170f8a91cc3321edfc336a9e39f24ebe3) Signed-off-by: Andre Rosa Signed-off-by: Richard Purdie

utils.py: added sh_quote() function

2019-04-04T21:57:32+00:00

This function is a wrapper around "shlex.quote()" and can be used in "${@...}" context where shlex (or pipes, which provides similar functionality) is unavailable. (From OE-Core rev: 127141f5023a7e3fc3963dc7d76cfce9067a9e8a) Signed-off-by: Enrico Scholz Signed-off-by: Richard Purdie

lib/oe/utils: Fix hang in multiprocess_launch()

2019-02-17T10:19:59+00:00

If large results values are returned by the subprocesses, we can hit a deadlock where the subprocess is trying to write data back to the parent, the pipe is full and the parent is waiting for the child to exit. Avoid this by calling the update() method which would trigger reading a result from the child, avoiding the deadlock. The issue is described in https://bugs.python.org/issue8426 (From OE-Core rev: 0035e8066ecbbff94d6a1994a9f72b1368d660d2) Signed-off-by: Richard Purdie

utils: add -src to system package name blacklist

2019-02-15T08:17:49+00:00

oe.utils.packages_filter_out_system() returns PACKAGES after removing "system" packages but it doesn't handle ${PN}-src as generated by PACKAGE_DEBUG_SPLIT_STYLE=debug-with-srcpkg. (From OE-Core rev: 162632d3d1e40c83ed9c5d49a026edf3912860a0) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

meta: Fix Deprecated warnings from regexs

2019-01-16T15:35:07+00:00

Fix handling of escape characters in regexs and hence fix python Deprecation warnings which will be problematic in python 3.8. Note that some show up as: """ meta/classes/package.bbclass:1293: DeprecationWarning: invalid escape sequence \. """ where the problem isn't on 1293 in package.bbclass but in some _prepend to a package.bbclass function in a different file like mesa.inc, often from do_package_split() calls. (From OE-Core rev: 4b1c0c7d5525fc4cea9e0f02ec54e92a6fbc6199) Signed-off-by: Richard Purdie

ccache.bbclass: Refactor it to make it more reliable

2019-01-14T11:35:55+00:00

The previous ccache.bbclass has the following problems: - It uses host's ccache for native recipes, but this may not work on some hosts, for example, it nerver works on my Ubuntu 14.04.4, there are always build failures (m4-native failed at do_configure, and others will also be failed if I disable CCACHE for m4-native) - native/nativesdk/cross/crosssdk recipes use host's ccache, but target uses ccache-native, this may confuse user. - The target recipes may use both host's ccache and ccache-native, this may cause unexpected problems and be hard to debug. This is because ccache-native is in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS, so ccache-native may not be present when rebuild target recipes, and then it would use hosttools/ccache, but the previous ccache files were generated by ccache-native. - Target recipes can't use ccache when no ccache is installed on the host: CCACHE = "${@bb.utils.which(d.getVar('PATH'), 'ccache') and 'ccache '}" After refactored: All types recipes (native, target and others) will use ccache-native except ccache-native itself, host's cache won't be used any more. It is more reliable now, which will work everywhere when ccache-native can be built. And now we need use "CCACHE_DISABLE = '1'" to disable ccache for the recipe rather than "CCACHE = ''" since we set CCACHE in anonymous function, and d.getVar('CCACHE') works after "CCACHE ??=" which is set in bitbake.conf, so we can't check whether CCACHE is set or not in anonymous function since it is always set. Use CCACHE_DISABLE to disable it would be more clear. (From OE-Core rev: b25271b65262f70d849a4861da216c9be6c54d53) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

lib/oe/utils: Set stderr for host_gcc_version()

2018-12-14T17:10:59+00:00

Fixed: $ ln -s /usr/bin/ccache /folk/lyang1/bin/gcc $ rm -fr tmp/hosttools/ && bitbake -p [snip] ERROR: Error running gcc --version: It didn't print the error message, now it is: ERROR: Error running gcc --version: ccache: error: Could not find compiler "gcc" in PATH For the error itself, it is because ccache is not in my HOSTTOOLS, so this is an expected error. (From OE-Core rev: 91955caae584b4f75118e04411851b1a3d783fec) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

lib/oe/utils: Improve multiprocess_lauch exception handling

2018-12-05T12:37:02+00:00

We've seen a cryptic: "ERROR: Fatal errors occurred in subprocesses, tracebacks printed above" message from oe-selftest with no other traceback information. Improve the traceback logging to try and give a better indication of any errors that is ocurring. (From OE-Core rev: 521dd3d00979a27b6932e58d5497de68abac26e1) Signed-off-by: Richard Purdie