[YOCTO #14917]
Attempting to use a dictionary in a python code snippet for variable
assignment results in an error. For example attempting something such
as
IDX = "green"
VAL = "${@{ 'green': 1, 'blue': 2 }[d.getVar('IDX')]}"
produces the error
expansion of VAL threw ExpansionError: Failure expanding variable
VAL, expression was ${@{ 'green': 1, 'blue': 2 }[d.getVar('IDX')]}
which triggered exception SyntaxError: '{' was never closed (Var
<VAL>, line 1)
The existing __expand_python_regexp__, "\${@.+?}", will match the
first close curly bracket encountered, resulting in incomplete and
un-parsable code, and thus produce the error. We can correct this by
allowing a single depth of nested curly brackets in
__expand_python_regexp__ by using "\${@(?:{.*?}|.)+?}", which will
match up to and including the matching close curly bracket to the
open, '${@', curly bracket, even if there are one or more singly
nested curly brackets present. This change allows the usecase
described above to function.
This change can't be made on its own though. The old regex would, in
an obscure way, handle the case where a python snippet contained an
unexpandable variable. Since the unexpandable variable is in curly
brackets it would cause incomplete/un-parsable python code and thus
remain unparsed. So something like
VAL = "${@d.getVar('foo') + ${unsetvar}}"
would remain unparsed as the close curly bracket in "${unsetvar}"
would match and terminate the snippet prematurely. This quirk resulted
in the proper handling of python snippets with unexpanded
variables. With the change to __expand_python_regexp__ the full
snippet will match and be parsed, but to match the old/correct
behavior we would not want to parse it until ${unsetvar} can be
expanded. To ensure the old/correct behavior for python snippets with
unexpanded variables remains in place we add a check for unexpanded
variables in the python snippets before running them.
This handling of unparsed variables brings two benefits. The first we
now have an explicit check visible to all for unexpanded variables
instead of a somewhat hidden behavior. The second is that if there are
multiple python snippets the old behavior would run the code for each
but a single snippet with unexpanded variables would mean all snippets
would remain unparsed, meaning more and repeated processing at a later
time.
For example:
"${@2*2},${@d.getVar('foo') ${unsetvar}}"
old behavior would give:
"${@2*2},${@d.getVar('foo') ${unsetvar}}"
new behavior will give:
"4,${@d.getVar('foo') ${unsetvar}}"
The old behavior would calculate '2*2' but toss the result when the
second snippet would fail to parse resulting in future recalculations
(or fetching from cache), while the new behavior avoids this.
(Bitbake rev: 94e49b9b9e409c29eb04603b1305d96ebe661a4b)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
First, commit 81efd77987f6decf256967fa16521a40c14d3518 created a copy
of __expand_var_regexp__ and __expand_python_regexp__ when creating
the initial version of data_smart.py. A while later commit
db1c998b31da06d7f3eb09fc6f59a1915b7b549e dropped all references to
these variables from data.py.
This leaves us today with two versions of these variables in the
global scope. However, only those defined in data_smart.py are being
used, in data_smart.py.
Unfortunately there was no indication in the commit log for commit
db1c998b31da indicating why the variables were left in place despite
the functions referencing them were being removed. Additionally
data.py imports data_smart, thus the versions of __expand_var_regexp__
and __expand_python_regexp__ defined in data_smart.py would be used by
all bitbake code, beyond, potentially, some code in data.py which we
know has no references to these variables.
To remove any potential confusion around these variables drop the old
definitions from data.py.
(Bitbake rev: 60f43d0428d43c981b44b6c8d125f77440f6c8f9)
Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This avoids the following error:
ERROR: pango-1.50.11-r0 do_package: QA Issue: pango: Files/directories
were installed but not shipped in any package:
/usr/libexec
/usr/libexec/installed-tests
/usr/libexec/installed-tests/pango
/usr/libexec/installed-tests/pango/nofonts
/usr/libexec/installed-tests/pango/nofonts/fonts.conf
Also use tabs for indentation of shell code.
(From OE-Core rev: d4bcd4050a6a9b6b1cb8e68b2053523cc0501814)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This was replacing /usr/include regardless of whether it
was at the beginning of the full path (correct, when building target
python3), or in the middle of it (not correct, when building
native or nativesdk python).
Through various reasons we haven't been bitten by this until now,
but latest setuptools does expose the problem with for example
nativesdk-python3-cffi and nativesdk-python3-cryptography which both
fail without this fix.
I am not aware of anything using INCLDIRSTOMAKE, and it is harder
to adjust correctly due to the value being a list; if something
is using it, we can look at it specifically.
(From OE-Core rev: 4055dd6cc89af16b3723e38b63d4d81efb0e2286)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There's no need to have linux-firmware in the sysroot. The sysroot won't
ever be used anyway as nothing needs the firmware at build-time, but this
saves us building a ~900MB sysroot (~300MB sstate tarball).
(From OE-Core rev: 26ed998c4f201c5cacf330f52e51e416afbd300c)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Config written to the emptytest include file is invalid after the test
has cleaned up its temporary directories resulting in the emptytest
recipe potentially having invalid content when parsed by successive
bitbake runs.
This presents the following error in tests after lic_checksum execution,
e.g. 'oe-selftest -r lic_checksum recipetool'
ERROR: .../emptytest.bb: Unable to get checksum for emptytest SRC_URI entry tmpn_nyosnq: file could not be found
Remove the recipe include content once the bitbake runs are completed in
each lic_checksum test case.
(From OE-Core rev: 087df767a64b271b503d714df3df6d8b3caad1c0)
Signed-off-by: Nathan Rossi <nathan.rossi@digi.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Set VERBOSE=1 so the compile logs are useful, perform the configure in
do_configure, and set bindir correctly.
(From OE-Core rev: 51fd68954dde1af9cfd5c8b38f5e8f5e852deaaf)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
SafeConfigParser was renamed to ConfigParser in 3.2, and the
SafeConfigParser alias will be removed in 3.12.
(From OE-Core rev: 71b3e7f71727137b4b996cc4160c9cc1581824b8)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The latest version update eliminated all custom patches, and the selftest
expects them.
(From OE-Core rev: 95298a7f1ad29c0fc0d02772d646116709ac355f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Update 0001-generate-glslang-pkg-config.patch to
omit libraries that are no longer present
(their functionality has been folded into glslang library
itself).
(From OE-Core rev: 354f1c4013f3b7ee78d6f4ed6209d6b549184057)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
