Also use assetIn instead of assertTrue which aids debugging failures.
(Bitbake rev: 19dee675bb9ad012d28e1e57a888931355a831cb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This code checks to see if shallow is either disabled or the tarball is
missing, but the else block tries to print the tarball filename, and
this attribute doesn't exist at all when shallow is disabled. Handle the
two cases separately to give sane errors for both cases without the
exception:
Exception: AttributeError: 'FetchData' object has no attribute 'fullshallow'
(Bitbake rev: bdbb558342ebb4e64384c9838d2485d9299d91a6)
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When multiconfig is enabled the cooker adds providers
for all the targets to be built on all the multiconfig
variables that were set, regardless if there is a dependency
to it or not.
This causes an issue when a certain target is incompatible
with one or more of the multiconfigs, e.g. the target is not
in COMPATIBLE_MACHINE for one of the MACHINEs being built,
causing the cooker to error out since no providers can be
found for that certain target on that multiconfig.
This patch modifies the behavior to only look for PROVIDERS
for a target on the multiconfig that was selected to be built,
PROVIDERS are then looked for in other multiconfigs only when
there is a defined dependency to them.
[YOCTO #12985]
(Bitbake rev: f2106a3a767542359fdde238abcf5fe35ab3a144)
Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
shrinkwrap resolved relative URL can start with http. For example,
"resolved: http-proxy/-/http-proxy-${PV}.tgz" is still relative URL
to npm registry, but starts with http.
Current if statement compares the startswith 'resolved' to 'http',
which makes impossible to use npm download. Condtional comparison
now strictly checks for "http://" and "https://"
(Bitbake rev: f76075aa1a5159fd4d62949cb588346888b9fe60)
Signed-off-by: Parthiban Nallathambi <pn@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- Add a comment in base.bbclass:
def oe_import(d):
import sys
# Comment
bbpath = d.getVar("BBPATH").split(":")
[snip]
Note, '# Comment' is started with '#', it is legal in python's syntax
(though maybe not a good style), but bitbake reported errors:
$ bitbake -p
ERROR: ParseError at /path/to/base.bbclass:20: unparsed line: ' bbpath = d.getVar("BBPATH").split(":")'
This error report would mislead people, the real problem is that '# Comment'
is not supported, but it reports the next line, this may make it hard to debug
the code are complicated.
We can make __python_func_regexp__ handle '^#' to fix the problem, since it
already can handle blank line "^$" in a python function, so it would be pretty
safe to handle "^#" as well.
(Bitbake rev: 79e62eef1c93f742bf71e9f25db57fdd2ffedd02)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[YOCTO #12898]
There might be no bitbake-cookerdaemon.log, print a message for debugging.
(Bitbake rev: 4adc582d2df7fdb9e51c4ebb5e66bbd21165b4dc)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
Add the following two lines to conf/local.conf:
FOO = "${@foo = 5}"
HOSTTOOLS += "${FOO}"
* Before the patch
$ bitbake -p
Check the first lines of bitbake bitbake-cookerdaemon.log
[snip]
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 125, in python_sub
codeobj = compile(code.strip(), self.varname or "<expansion>", "eval")
File "FOO", line 1
[snip]
There isn't a file named 'FOO', but a variable name.
* After the patch
$ bitbake -p
[snip]
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 129, in python_sub
codeobj = compile(code.strip(), varname, "eval")
File "Var <FOO>", line 1
foo = 5
(Bitbake rev: 540b546be55e0f5f5d91695956da3a7732b2f90a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This can make it print clearer errors, for exmaple:
Add Runtime_error to 'def oe_import(d)"
16 def oe_import(d):
17 import sys
18 Runtime_error
[snip]
* Before the patch:
$ bitbake -p
ERROR: Unable to parse /buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py
Traceback (most recent call last):
File "/buildarea1/lyang1/poky/bitbake/lib/bb/data_smart.py", line 430, in DataSmart.expandWithRefs(s='${@oe_import(d)}', varname='OE_IMPORTED[:=]'):
except Exception as exc:
> raise ExpansionError(varname, s, exc) from exc
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception NameError: name 'Runtime_error' is not defined
This error message has two problems:
- "Unable to parse data_smart.py": This isn't the real cause.
- It pionts to "raise ExpansionError(varname, s, exc) from exc" which isn't clear enough.
* After the patch:
$ bitbake -p
ERROR: Unable to parse OE_IMPORTED[:=]
Traceback (most recent call last):
File "OE_IMPORTED[:=]", line 1, in <module>
File "/buildarea1/lyang1/poky/meta/classes/base.bbclass", line 18, in oe_import(d=<bb.data_smart.DataSmart object at 0x7f9257e7a0b8>):
import sys
> Runtime_error
bb.data_smart.ExpansionError: Failure expanding variable OE_IMPORTED[:=], expression was ${@oe_import(d)} which triggered exception NameError: name 'Runtime_error' is not defined
This one is more clearer than before.
(Bitbake rev: c0fe524c1aeccb24ddd2e1f7bf235c00fdbf79a7)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- Define an error anonymous function in base.bbclass:
15
16 python() {
17 Compile error
18 }
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 18:
The code lines resulting in this error were:
0001:def __anon_18__buildarea1_lyang1_poky_meta_classes_base_bbclass(d):
*** 0002: Compile error
0003:
SyntaxError: invalid syntax (base.bbclass, line 18)
The lineno should be 17, but it reported 18, this would mislead people a lot
when there more lines.
- Now fix it to:
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 17:
The code lines resulting in this error were:
0001:def __anon_18__buildarea1_lyang1_poky_meta_classes_base_bbclass(d):
*** 0002: Compile error
0003:
SyntaxError: invalid syntax (base.bbclass, line 17)
This is because the anonymous function is constructed by:
text = "def %s(d):\n" % (funcname) + text
The len(self.body) doesn't include the "def " line, the length of the function
should be "len(self.body) + 1", so we need pass "self.lineno - (len(self.body) + 1)"
which is the same as 'self.lineno - len(self.body) - 1' to
bb.methodpool.insert_method() as we already had done to named function. Otherwise, the
lineno is wrong, and would cause other problems such as report which line is
wrong, but the line is not what we want since it reports incorrect line.
(Bitbake rev: 7466c8765fcc792e5ea3daefda3c5895e782d6c4)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed:
- Add an error line in base.bbclass, e.g.:
15
16 def oe_import(d):
17 import sys
18 Compile error
19 bbpath = d.getVar("BBPATH").split(":")
[snip]
Note the "Compile error" line, I added it for reporting errors.
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 15:
The code lines resulting in this error were:
0014: import oe.data
0015: for toimport in oe.data.typed_value("OE_IMPORTS", d):
0016: imported = __import__(toimport)
0017: inject(toimport.split(".", 1)[0], imported)
*** 0018:
0019: return ""
0020:
SyntaxError: invalid syntax (base.bbclass, line 18)
There are 2 problems:
- The "line 15" is incorrect, it is a blank line, not the error line.
- The "*** 0018" points to incorrect position.
These two problems would mislead people a lot sometimes.
- Now fix it to:
$ bitbake -p
ERROR: Error in compiling python function in /buildarea1/lyang1/poky/meta/classes/base.bbclass, line 18:
The code lines resulting in this error were:
0001:def oe_import(d):
0002: import sys
*** 0003: Compile error
0004: bbpath = d.getVar("BBPATH").split(":")
[snip]
SyntaxError: invalid syntax (base.bbclass, line 18)
Please see comments in the code for more details on how it is fixed.
(Bitbake rev: bbb3d87d171da38fd8e9bce011d109fba28a75c0)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The colors specified for use with bitbake-diffsigs were adapted for a
dark theme, e.g., by setting the background color to black, which made
it look very bad when used with a light theme.
To make it look good both with a dark or a light theme, it is better
to drop the background color. It is also better to leave out the color
altogether for the title and just use bold. Finally, dropping bold for
the red and green texts indicating removed/added values better matches
other colorized diff implementations as, e.g., git diff.
(Bitbake rev: f1a2c23520832ee91e85338c1ad8af1fec0d0b19)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The imp module is deprecated, port the code over to use importlib.
bitbake/lib/bb/utils.py:30: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
import imp
(Bitbake rev: 3c2cb35588e91fbd7b136e5e2c78eeb77e126c84)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Traceback (most recent call last):
File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/main.py", line 464, in setup_bitbake
server_connection = bb.server.process.connectProcessServer(sockname, featureset)
File "/home/pokybuild/yocto-worker/nightly-oe-selftest/build/bitbake/lib/bb/server/process.py", line 490, in connectProcessServer
if command_chan_recv:
UnboundLocalError: local variable 'command_chan_recv' referenced before assignment
(Bitbake rev: ad79fadd855f5c10242ed17e9e0f3eb0274f26d2)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Use % operator to ensure that the dependency is substituted into the error
message correctly.
(Bitbake rev: 8e587386b0b3a0ed11edf71dfbe9fb508f60d0b3)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Support users who want to specify a custom ssh to Git using an environment
variable. (This lets build systems work without requiring users to
configure Git explicitly.)
(Bitbake rev: db46fb2755a4b1033ab60051ce511cc9dd7e34fb)
Signed-off-by: Mike Crowe <mac@mcrowe.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Updates for YOCTO #12891 allowed a user to have a directory
structure different to that of yocto (bitbake isn't inside
oe-core) whereas the definition of OE_ROOT in the main toaster
binary still assumes the same while checking for .templateconf
and hence we see an error on the cmdline in such cases:
bash: <repo-path>/bitbake/bin/../../.templateconf: No such file or directory
The change here now allows the user to provide OE_ROOT through
the environment in such cases and otherwise defaults to the older
mechanism to fix this issue.
(Bitbake rev: 9cc6fe4be797e106899d2448797a4b3af8eace4e)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Git does not require the module and target path to be the same in the
.gitmodules file. This incorrect assumption was being made previously
causing various unpack failures.
An example .gitmodule showing this issue:
[submodule "plugins/WaveShaper/Libs/inih"]
path = plugins/wolf-shaper/Libs/inih
url = https://github.com/pdesaulniers/inih.git
The unpack function also needed to work in a loop on the overall
submodules_queue. Before it could have missed items that were not in the
primary repository.
(Bitbake rev: 5a7009c204f4d2254e3b2d83ad9319ac23f1cf4d)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Submodules by definition refer to a specific commit, not branch. If we don't
ignore the branch, then any commits on a submodule on a branch different then
the original module will trigger a failure that the commit is not on the
branch.
(Bitbake rev: fdc1dbf96f153b496de52acd8263366a1ff303ad)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Rendering the manual to its HTML form was collapsing the two
leading and four trailing whitespace characters into single
whitespace characters. I inserted multiple " " strings
to force the spacing to come through.
(Bitbake rev: 701f76f773a6e77258f307a4f8e2ec1a8552f6f3)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12390]
Applied some fixes to the variable wildcard support documentation
in the BitBake manual. Wording changes and changes to make links
referencing Python syntax go to version 3 rather than version 2.
(Bitbake rev: 0cfc71d1a342b82781b0ba547421e41f6340902a)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixes [YOCTO #12390]
Added specific descriptions for how wildcarding works for a variety
of variables and files (e.g. append files).
(Bitbake rev: 0a4377cb1837ede213d9640344f4908de3689d91)
Signed-off-by: Scott Rifenbark <srifenbark@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If a variable has a _remove applied to it but that variable is in turn
'renamed' through OVERRIDES, the removal gets lost with the current code.
TEST = "foo"
TEST_someval = "bar"
TEST_someval_remove = "bar"
OVERRIDES = "someval"
currently gives "bar" for TEST but should give "".
This fixes the code to track the removal and adds a test case to ensure this
doesn't regress again.
(Bitbake rev: 8f55010c18057be040f073d8bcb4c5c2c311d809)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This adds some basic tests for task checksums to ensure that the
checksums:
* change when variables change
* change when active _remove operators are present
* don't change when the _remove operators are not active
* change when an active contains() expression is present
* dont' change a contains() expression isn't active
There is a lot of other functionality which should be added to this
test but its a start.
(Bitbake rev: 5463c16e3619d324aed137f47f93f0997a227d29)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
By creating a standalone function, we can add better functional testing
of this code.
(Bitbake rev: 796a20d24dc18479de1975a37b9e52a5ac75c73f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently remove operations are not being accounted for in the task
checksums. This is a fairly serious oversight and needs to be fixed.
To do so, we need internal data from getVarFlag combined with the
expanded variable data so that only "active" remove operators are
accounted for in the task checksum. We can get this from the new
optional removes attribute in the returned parser object.
The code can then use the data on active remove operators to account
for the removals in task checksum but only when the removal is active.
We have to be careful here not to reference any expanded data since this
may for example contain build paths. This means we can only map back
and reference the unsplit (and hence unexpanded) remove string which may
expand to multiple removal values.
[YOCTO #12913]
(Bitbake rev: 57d2ee17ae83a139a37081eb082e6184fa883581)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The contents of the expand_cache is meant to match the return value of
getVarFlag() but the implementation was mostly in expandWithRefs(). If
an incorrect key was passed to expandWithRefs(), or a variable was only
partially expanded with no remove processing, the cache could become
corrupted.
Move the code to getVarFlag making the data lifecycle very clear, meaning
other calls to expandWithRefs() cannot corrupt the cache.
The expand_cache reset code needs to be moved ahead of any remote data
connectors too, since the expand_cache is now on the local side of the
connection.
(Bitbake rev: a039052f9b680eae53f3f12b7381b945f1d69253)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This brings _remove handling into line with _append/_prepend with regard
to the parsing flag to getVarFlag.
This is an internal flag and the only times this is used is through getVar
during renameVar operations and when processing ?= operations to see if
a variable is set. In either case we don't need to process remove operations.
Therefore take the minor speedup and skip processing for parsing=True.
[YOCTO #10945]
(Bitbake rev: 6d19eb3226b59922c0f888e33b28443635151501)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Calling getVarFlag with flag=None makes no sense, don't do it. Bitbake
used to silently ignore this, it now warns so avoid the warning.
(Bitbake rev: a68de8ace62eaba23856bfb301efbbe1824322aa)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Contrary to what the manual said, BB_RUNTASK does include the do_
prefix, unlike BB_CURRENTTASK.
(Bitbake rev: 3f4968c77129252e8d0833fbd683372fca243a90)
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Provide more information in the case the sources are not found in the
unpack step.
(Bitbake rev: 27a2214bf6f2e7c61bfc422a20959a55f7e0d25d)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A user friendly error is throw when neither the clonedir nor
fullshallow exist. Without the check, a difficult to interpret error
is throw from within the fetch command.
(Bitbake rev: 30cf2506007d25162f0805051212f54c39034ff3)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
For better readability and future use, we extract the function which
ensures that a given symlink exists.
(Bitbake rev: 5e69ca56533666a097bb23d09ab673e5c862051c)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mapping of the URLs to the local shallow tarballs is not obvious. For
easier understanding, we add this tests to explicitly showing the mapping.
(Bitbake rev: 05f2ac8e19a027d103921b5ae0070db609a83042)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mapping of the URLs to the local tarballs is not obvious. For easier
understanding, we add this tests to explicitly showing the mapping.
(Bitbake rev: c604d9402b4c9ad7eb5c794ab24f2f348d9719a9)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The mapping of the URLs to the local directory is not obvious. For easier
understanding, we add this tests to explicitly showing the mapping.
(Bitbake rev: 5f92682389fee437d6df2ff7718c571b7444e179)
Signed-off-by: Urs Fässler <urs.fassler@bbv.ch>
Signed-off-by: Pascal Bach <pascal.bach@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Some recent changes broke SRCPV and workaround was introduced
to avoid circular dependency if SRCPV is in PV.
However there is still the same error if SRCPV is in PR.
(Bitbake rev: 05ee4845f925b8528a7ce9cffb4bae425b8fa1e9)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Searching in the task explorer requires one to focus the task list. A
readily visible and focused search bar makes searching intuitive.
(Bitbake rev: 43f8a23d56995f552f98a666e86b6cc124e235a4)
Signed-off-by: Tobias Olausson <tol@hms.se>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In the list_obj function, we can't check if the requested object is 'in',
the index data -- as it's actually an attribute of the object. Move to hasattr.
The remaining items were incorrect usages of 'type' for class type comparison.
Instead move to 'isinstance'. Remaing 'type' comparisons are still valid. The
code was also reordered slightly to avoid a lot of:
if not isinstance(x, y):
...
else:
...
reordering it removes the not and makes the code slightly easier to read.
(Bitbake rev: cddea4282820ef10ad4863d87327891ea9383916)
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The "buildimport.py" script is missing the "import shutil" line,
which causes a project import page failure.
[YOCTO #12959]
(Bitbake rev: 0bfbcc786fd67bd40153160db7fcd41cd9295234)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The version of django in the 2.6 release got bumped to 1.11.14.
The toaster requirements file needs to be updated to accept it.
[YOCTO #12958]
(Bitbake rev: b081b78a330fee30b172c2c8bdc9c196a65be9af)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The distro source path link is missing "conf/distro/", and the
display is using the machine link instead of the distro link.
[YOCTO #12957]
(Bitbake rev: e43ff061b03878057e49c44aa3ee2e4c7a5d5503)
Signed-off-by: David Reyna <David.Reyna@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have some slightly odd behaviours with the current implementation of
_remove operations. For example:
TEST = " A B"
TEST_remove = "C"
would trigger TEST to become "A B" even thought it doesn't contain "C".
In particular, this means that an inactive remove operator added in a
bbappend could change the task checksum which is not desireable.
Fix the operation to preserve whitespace, adding new tests to make this
explict and test further corner cases. Also update the manual to match.
(Bitbake rev: c0a23dd9155c50a6b7df796980bc7b612cac7994)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
